Distribuire più server di accesso remoto in una distribuzione multisito

Si applica a: Windows Server 2012 R2, Windows Server 2012

Windows Server 2012Combina DirectAccess e Routing e accesso remoto (RRAS) VPN in un singolo ruolo Accesso remoto. Accesso remoto può essere distribuito in un numero di scenari aziendali. In questa panoramica fornisce un'introduzione allo scenario enterprise per la distribuzione di server di accesso remoto in una configurazione multisito.

Descrizione dello scenario

In una distribuzione multisito due o più server di accesso remoto o server cluster vengano distribuiti e configurati come punti di ingresso diversi in un'unica posizione o in posizioni geografiche diverse. Distribuzione di più punti di ingresso in un'unica posizione consente di ridondanza dei server o per l'allineamento del server di accesso remoto con l'architettura di rete esistente. Posizione geografica assicura un utilizzo efficiente delle risorse, come computer client remoti possono connettersi alle risorse di rete interna utilizzando un punto di ingresso più vicino. Il traffico attraverso una distribuzione multisito può essere distribuito e bilanciato con un servizio di bilanciamento del carico globale esterno.

Una distribuzione multisito supporta computer client che eseguonoWindows 8oWindows 7. Computer client che eseguonoWindows 8rileva automaticamente un punto di ingresso o l'utente può selezionare manualmente un punto di ingresso. L'assegnazione automatica si verifica nel seguente ordine di priorità:

1. Utilizzare un punto di ingresso selezionato manualmente dall'utente.

2. Utilizzare un punto di ingresso identificato da un servizio di bilanciamento del carico globale esterno se uno è distribuito.

3. Utilizzare il punto di ingresso più vicino identificato dal computer client utilizzando un meccanismo automatico probe.

Supporto per i client che eseguono Windows 7 deve essere abilitato manualmente in ogni punto di ingresso e selezione di un punto di ingresso da questi client non è supportata.

Prerequisiti

Prima di iniziare la distribuzione di questo scenario, esaminare l'elenco dei requisiti importanti:

• Distribuire un server DirectAccess singolo con impostazioni avanzatedevono essere distribuiti prima di una distribuzione multisita.

• I client Windows 7 si connettano sempre a un sito specifico. Non saranno in grado di connettersi al sito più vicino in base alla posizione del client (a differenza di Windows 8, i client windows 8.1).

• Modifica di criteri all'esterno di console Gestione DirectAccess o i cmdlet PowerShell non è supportata.

• È necessario distribuire un'infrastruttura a chiave pubblica.

  Per ulteriori informazioni, vedere: Test Lab Guide minima modulo: Base PKI per Windows Server 2012.

• Rete aziendale deve essere abilitata a IPv6. Se si usa la tecnologia ISATAP, rimuoverla e usare la connettività IPv6 nativa.

In questo scenario

Lo scenario di distribuzione multisito include una serie di passaggi:

1. **Distribuire un server DirectAccess singolo con impostazioni avanzate**Ovvero prima di configurare una distribuzione multisito, è necessario distribuire un singolo server di accesso remoto con impostazioni avanzate.

2. Pianificare una distribuzione Multisita: Per compilare un numero di ulteriori informazioni sulla pianificazione di una distribuzione multisito da un singolo server passaggi sono necessari, tra cui conformità con i prerequisiti multisiti e pianificazione di gruppi di protezione di Active Directory, oggetti Criteri di gruppo (GPO), DNS e le impostazioni del client.

3. Configurare una distribuzione Multisita: Si tratta di un numero di passaggi di configurazione, tra cui la preparazione dell'infrastruttura di Active Directory, configurazione del server di accesso remoto esistente e l'aggiunta di più server di accesso remoto come punti di ingresso alla distribuzione multisito.

4. Risoluzione dei problemi relativi a una distribuzione multisito: Questa sezione sulla risoluzione dei problemi descrive un numero di errori più comuni che possono verificarsi durante la distribuzione di accesso remoto in una distribuzione multisito.

Applicazioni pratiche

Una distribuzione multisito fornisce quanto segue:

• Prestazioni migliorate, una distribuzione multisito consente ai client computer l'accesso a risorse interne tramite accesso remoto per connettersi utilizzando il punto di ingresso più vicino e più adatto. Client di accedere alle risorse interne in modo efficiente e la velocità dei client che Internet richieste indirizzate tramite DirectAccess è stata migliorata. Utilizzo di un servizio di bilanciamento del carico globale esterno è possibile bilanciare il traffico tra i punti di ingresso.

• Facilità di gestione, distribuzione multisito consente agli amministratori di allineare la distribuzione di accesso remoto a una distribuzione di siti di Active Directory, fornendo un'architettura semplificata. Impostazioni condivise possono essere impostate facilmente tra server del punto di ingresso o cluster. Impostazioni di accesso remoto possono essere gestite da uno qualsiasi dei server di distribuzione o in modalità remota utilizzando strumenti di amministrazione remota Server (RSAT). Inoltre, l'intera distribuzione multisito può essere monitorata da un'unica console di gestione accesso remoto.

Ruoli e funzionalità inclusi nello scenario

Nella tabella seguente sono elencati i ruoli e le funzionalità utilizzate in questo scenario.

Requisiti hardware

I requisiti hardware per questo scenario includono i seguenti.

• Almeno due computer di accesso remoto per la raccolta in una distribuzione multisito. Requisiti hardware per questi computer sono descritti inDistribuire un server DirectAccess singolo con impostazioni avanzate.

• Per testare lo scenario, almeno un computer che esegueWindows 8e configurato come un client DirectAccess è obbligatorio. Per testare lo scenario per i client che eseguono Windows 7 è necessario almeno un computer che eseguono Windows 7.

• Per bilanciare il carico tra i server punto di ingresso, è necessario un bilanciamento del carico globale esterno di terze parti.

Requisiti software

I requisiti software per questo scenario includono i seguenti.

• Requisiti software per la distribuzione a server singolo. Per ulteriori informazioni, vedere Distribuire un server DirectAccess singolo con impostazioni avanzate.

• Oltre ai requisiti software per un singolo server sono disponibili una serie di requisiti multisite-specifici:

  • Requisiti di autenticazione IPsec, ovvero l'autenticazione del certificato del computer In una distribuzione multisito DirectAccess devono essere distribuiti tramite IPsec. L'opzione per eseguire l'autenticazione IPsec utilizzando il server di accesso remoto come proxy Kerberos non è supportata. Una CA interna è necessario per distribuire i certificati IPsec.

  • Requisiti del server di percorso di rete e IP-HTTPS, i certificati necessari per IP-HTTPS e il server dei percorsi di rete deve essere emesso da un'autorità di certificazione. L'opzione per utilizzare i certificati automaticamente emesso e firmati dal server di accesso remoto non è supportata. Possono essere emessi da una CA interna o da una CA esterna di terze parti.

  • Requisiti di Active Directory, è necessario almeno un sito di Active Directory. Server di accesso remoto deve trovarsi nel sito. Per i tempi di aggiornamento, è consigliabile che ogni sito dispone di un controller di dominio scrivibile, anche se ciò non è obbligatorio.

  • Requisiti dei gruppi di sicurezza, sono i seguenti requisiti:

    • Un gruppo di sicurezza è necessario per tutte leWindows 8computer client di tutti i domini. È consigliabile creare un gruppo di sicurezza di questi client per ogni dominio.

    • Un gruppo di sicurezza univoco contenente i computer Windows 7 è necessario per ogni punto di ingresso configurato per supportare i client Windows 7. È consigliabile disporre di un gruppo di sicurezza univoco per ogni punto di ingresso in ogni dominio.

    • Computer non devono essere incluse più di un gruppo di protezione che include i client DirectAccess. Se i client sono inclusi in più gruppi, la risoluzione dei nomi per le richieste client non funzionerà come previsto.

  • Requisiti di oggetto Criteri di gruppo, oggetti Criteri di gruppo può essere creato manualmente prima di configurare accesso remoto o creati automaticamente durante la distribuzione di accesso remoto. Sono i seguenti requisiti:

    • Un oggetto Criteri di gruppo client univoco è necessaria per ogni dominio.

    • Un oggetto Criteri di gruppo di server è necessario per ogni punto di ingresso nel dominio in cui si trova il punto di ingresso. Pertanto se più punti di ingresso si trovano nello stesso dominio, saranno presenti più server oggetti Criteri di gruppo (uno per ogni punto di ingresso) nel dominio.

    • Un GPO univoco per il client Windows 7 è necessario per ogni punto di ingresso abilitata per il supporto di client Windows 7, per ogni dominio.

Problemi noti

I seguenti problemi noti durante la configurazione di uno scenario multisito:

• Più punti di ingresso nella stessa subnet IPv4: aggiunta di più punti di ingresso nella stessa subnet IPv4 si otterrà un messaggio di conflitto di indirizzi IP e l'indirizzo DNS64 per il punto di ingresso non verrà configurato come previsto. Questo problema si verifica quando non è stato distribuito IPv6 sulle interfacce del server nella rete aziendale interne. Per evitare questo problema, eseguire il seguente comando di Windows PowerShell in tutti i server di accesso remoto correnti e futuri:

  Set-NetIPInterface –InterfaceAlias <InternalInterfaceName> –AddressFamily IPv6 –DadTransmits 0
  

• Se l'indirizzo pubblico specificato per i client DirectAccess per connettersi al server di accesso remoto dispone di un suffisso incluso nella risoluzione dei nomi, DirectAccess potrebbero non funzionare come previsto. Assicurarsi che la risoluzione dei nomi disponga di un'esenzione per il nome pubblico. In una distribuzione multisito, è necessario aggiungere le esenzioni per i nomi di tutti i punti di ingresso pubblici. Si noti che se il tunneling forzato è attivata vengono aggiunti automaticamente tali esenzioni. Vengono rimossi se tunneling forzato è disabilitato.

• Quando si utilizza il cmdlet Windows PowerShellDisable-DAMultiSitei parametri WhatIf and Confirm non hanno alcun effetto e verrà disabilitata multisito eWindows 7oggetti Criteri di gruppo verranno rimossi.

• QuandoWindows 7client mediante DCA in una distribuzione multisito vengono aggiornati aWindows 8Assistente connettività di rete non funzionerà. Questo problema può essere risolto prima che l'aggiornamento client modificando ilWindows 7oggetti Criteri di gruppo tramite i cmdlet Windows PowerShell seguenti:

  Set-GPRegistryValue -Name <Windows7GpoName> -Domain <DomainName> -Key "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant" -ValueName "TemporaryValue" -Type Dword -Value 1 Remove-GPRegistryValue -Name <Windows7GpoName> -Domain <DomainName> -Key "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant" 
  

  Nel caso in cui il client è già stato aggiornato, quindi spostare il computer client per ilWindows 8gruppo di sicurezza.

• Quando si modificano le impostazioni di controller di dominio utilizzando il cmdlet Windows PowerShellSet-DAEntryPointDCse il parametro ComputerName specificato è un server di accesso remoto in un punto di ingresso diverso dall'ultimo aggiunto alla distribuzione multisito, verrà visualizzato un avviso che indica che il server specificato non verrà aggiornato fino al successivo aggiornamento di criteri. I server effettivi che non è stati aggiornati possono essere visualizzati utilizzando illo stato di configurazionenelDASHBOARDdelConsole Gestione accesso remoto. Tale situazione non causerà problemi funzionali, tuttavia, è possibile eseguiregpupdate /forcenei server che non è stato aggiornato per ottenere lo stato della configurazione aggiornato immediatamente.

• Quando viene distribuita la funzionalità multisito in solo IPv4 di una rete aziendale interna di modifica indirizzo di rete prefisso IPv6 anche modifiche DNS64, ma non aggiorna l'indirizzo sulle regole firewall che consentono alle query DNS per il servizio DNS64. Per risolvere questo problema, eseguire i comandi di Windows PowerShell seguenti dopo la modifica del prefisso IPv6 della rete interna:

  $dns64Address = (Get-DAClientDnsConfiguration).NrptEntry | ?{ $_.DirectAccessDnsServers -match ':3333::1' } | Select-Object -First 1 -ExpandProperty DirectAccessDnsServers $serverGpoName = (Get-RemoteAccess).ServerGpoName $serverGpoDc = (Get-DAEntryPointDC).DomainControllerName $gpoSession = Open-NetGPO -PolicyStore $serverGpoName -DomainController $serverGpoDc Get-NetFirewallRule -GPOSession $gpoSession | ? {$_.Name -in @('0FDEEC95-1EA6-4042-8BA6-6EF5336DE91A', '24FD98AA-178E-4B01-9220-D0DADA9C8503')} |  Set-NetFirewallRule -LocalAddress $dns64Address Save-NetGPO -GPOSession $gpoSession
  

• Se DirectAccess è stato distribuito quando un'infrastruttura ISATAP esistente non è presente quando si rimuove un punto di ingresso è un host ISATAP, l'indirizzo IPv6 del servizio DNS64 verrà rimossa da indirizzi server DNS di tutti i suffissi DNS nella risoluzione dei nomi.

  Per risolvere questo problema, nelconfigurazione Server di infrastrutturaprocedura guidata diDNSpagina, rimuovere i suffissi DNS che sono stati modificati e aggiungerli nuovamente con gli indirizzi di server DNS corretti, facendo clic surilevasulindirizzi Server DNSnella finestra di dialogo.