Distribuire Accesso remoto in un cluster
Windows Server 2016 e Windows Server 2012 combina DirectAccess e servizio di accesso remoto (RAS) VPN in un unico ruolo Accesso remoto. È possibile distribuire Accesso remoto in diversi scenari aziendali. Questa panoramica fornisce un'introduzione allo scenario aziendale per la distribuzione di più server di Accesso remoto in un carico di cluster bilanciato con Bilanciamento carico di rete di Windows (NLB, Network Load Balancing) oppure con un servizio di bilanciamento del carico esterno (ELB, External Load Balancer), ad esempio F5 Big-IP.
Descrizione dello scenario
Una distribuzione di cluster raccoglie più server di Accesso remoto in una singola unità, quindi agisce come un singolo punto di contatto per i computer client remoti che si connettono via DirectAccess o VPN alla rete aziendale interna usando l'indirizzo IP virtuale esterno (VIP) del cluster di Accesso remoto. Il carico del traffico al cluster viene bilanciato con Bilanciamento carico di rete di Windows o con un servizio di bilanciamento del carico esterno (ad esempio F5 Big-IP).
Prerequisiti
Prima di affrontare la distribuzione di questo scenario, esaminare l'elenco dei requisiti importanti:
Bilanciamento del carico predefinito con Bilanciamento carico di rete di Windows.
Sono supportati i servizi di bilanciamento del carico esterni.
La modalità predefinita e consigliata per Bilanciamento carico di rete di Windows è Unicast.
La modifica dei criteri all'esterno della console di gestione DirectAccess o con cmdlet di PowerShell non è supportata.
Quando si usa Bilanciamento carico di rete di Windows o un servizio di bilanciamento del carico esterno, è possibile modificare il prefisso IPHTTPS solo in /59.
I nodi con carico bilanciato devono trovarsi nella stessa subnet IPv4.
Nelle distribuzioni ELB, se è necessaria la gestione in remoto, i client DirectAccess non possono usare Teredo. Per le comunicazioni end-to-end, è possibile usare solo IPHTTPS.
Assicurarsi che siano installati tutti gli hotfix NLB/ELB noti.
La tecnologia ISATAP non è supportata nella rete aziendale. Se si usa la tecnologia ISATAP, rimuoverla e usare la connettività IPv6 nativa.
In questo scenario
Lo scenario di distribuzione di cluster include alcuni passaggi:
Distribuire un server VPN Always On con opzioni avanzate. Prima di configurare una distribuzione di cluster è necessario distribuire un singolo server di Accesso remoto con impostazioni avanzate.
Pianificare la distribuzione di un cluster di accesso remoto. Per creare un cluster da una distribuzione a server singolo sono necessari alcuni altri passaggi, compresa la preparazione dei certificati per la distribuzione di cluster.
Configurare un cluster di accesso remoto. Si tratta di una serie di passaggi di configurazione, comprese la preparazione del server singolo per il Bilanciamento carico di rete di Windows o il servizio di bilanciamento del carico esterno, la preparazione di altri server da aggiungere al cluster e l'abilitazione del bilanciamento del carico.
Applicazioni pratiche
La raccolta di più server in un cluster di server fornisce quanto segue:
Scalabilità. Un singolo server di Accesso remoto offre un livello limitato di scalabilità delle prestazioni e affidabilità del server. Raggruppando le risorse di due o più server in un unico cluster, si aumenta la capacità per numero di utenti e velocità effettiva.
Disponibilità elevata. Un cluster garantisce un'elevata disponibilità per l'accesso continuo. Se un server nel cluster non riesce, gli utenti remoti possono continuare ad accedere alla rete aziendale usando un altro server nel cluster. Tutti i server del cluster hanno lo stesso set di indirizzi IP virtuali (VIP) del cluster, pur mantenendo un indirizzo IP dedicato e univoco per ciascun server.
Facilità di gestione. Un cluster consente di gestire più server come singola entità. Le impostazioni condivise possono essere impostate facilmente in tutti i server cluster. Le impostazioni di Accesso remoto possono essere gestite da qualsiasi server nel cluster oppure in remoto usando gli Strumenti di amministrazione remota del server. L'intero cluster può anche essere monitorato da una sola Console di gestione Accesso remoto.
Ruoli e funzionalità inclusi nello scenario
Nella tabella seguente sono elencati i ruoli e le funzionalità richiesti per lo scenario.
| Ruolo/funzionalità | Modalità di supporto dello scenario |
|---|---|
| Ruolo Accesso remoto | Il ruolo viene installato e disinstallato tramite la console di Server Manager. Comprende DirectAccess, una funzionalità precedentemente inclusa in Windows Server 2008 R2, e il servizio Routing e Accesso remoto (RRAS) che in precedenza era un servizio ruolo nel ruolo del server Servizi di accesso e criteri di rete (NPAS). Il ruolo Accesso remoto è costituito da due componenti: -VPN Always On e accesso remoto (RRAS) VPN DirectAccess e VPN vengono gestiti insieme nella console di gestione accesso remoto. Le dipendenze sono le seguenti: -Internet Information Services (IIS) Web Server - questa funzionalità è necessaria configurare il server dei percorsi di rete e probe web predefinito. |
| Funzionalità Strumenti di Gestione Accesso remoto | Questa funzionalità viene installata come segue: -Viene installato per impostazione predefinita in un server di accesso remoto quando è installato il ruolo Accesso remoto e supporta l'interfaccia utente della console di gestione remota. La funzionalità Strumenti di Gestione Accesso remoto è costituita dai seguenti elementi: -Accesso remoto GUI e strumenti da riga di comando Le dipendenze includono: -Console Gestione criteri di gruppo |
| Bilanciamento del carico di rete | Questa funzionalità fornisce il bilanciamento del carico in un cluster usando il Bilanciamento carico di rete di Windows. |
Requisiti hardware
I requisiti hardware per questo scenario includono i seguenti.
Almeno due computer che soddisfino i requisiti hardware per Windows Server 2012.
Per lo scenario di Bilanciamento del carico esterno, è richiesto un hardware dedicato (ad esempio F5 BigIP).
Per testare lo scenario, è necessario avere almeno un computer che esegue Windows 10 come client VPN Always On.
Requisiti software
Per questo scenario sono presenti numerosi requisiti.
Requisiti software per una distribuzione a server singolo. Per altre informazioni, vedere Distribuire un server DirectAccess singolo con impostazioni avanzate. Un singolo accesso remoto).
Oltre ai requisiti software per un server singolo, esistono alcuni requisiti specifici per i cluster:
In ogni server cluster il nome soggetto del certificato IP-HTTPS deve corrispondere all'indirizzo ConnectTo. Una distribuzione cluster supporta una combinazione di certificati con o senza caratteri jolly nei server cluster.
Se il server dei percorsi di rete è installato sul server di Accesso remoto, su ogni server cluster dovrà avere lo stesso nome soggetto. Inoltre, il nome del certificato del server dei percorsi di rete non deve essere lo stesso di qualsiasi altro server nella distribuzione di DirectAccess.
I certificati IP-HTTPS e del server dei percorsi di rete devono essere rilasciati con lo stesso metodo impiegato per il certificato del singolo server. Ad esempio, se il singolo server usa un'autorità di certificazione pubblica (CA), tutti i server nel cluster dovranno avere un certificato rilasciato da un'autorità di certificazione pubblica. In alternativa, se il singolo server usa un certificato autofirmato per IP-HTTPS, tutti i server nel cluster dovranno fare altrettanto.
Il prefisso IPv6 assegnato ai computer client DirectAccess nei cluster di server deve essere di 59 bit. Se VPN è abilitato, anche il prefisso VPN deve essere di 59 bit.
Problemi noti
Di seguito sono riportati alcuni problemi noti durante la configurazione di uno scenario cluster:
Dopo aver configurato DirectAccess in una distribuzione solo IPv4 con un'unica scheda di rete e dopo che l'impostazione predefinita DNS64 (l'indirizzo IPv6 che contiene ":3333::") viene automaticamente configurata nella scheda di rete, il tentativo di abilitare il bilanciamento del carico usando la Console di gestione Accesso remoto comporta la visualizzazione di una richiesta all'utente di fornire un DIP IPv6. Se si specifica un DIP IPv6, la configurazione non riesce dopo aver fatto clic su Commit e viene visualizzato l'errore Parametro non corretto.
Per risolvere il problema:
Scaricare gli script di backup e ripristino da Backup e ripristino della configurazione di Accesso remoto.
Eseguire il backup degli oggetti Criteri di gruppo di Accesso remoto usando lo script Backup RemoteAccess.ps1 scaricato
Provare ad abilitare il bilanciamento del carico fino al passaggio in cui si verifica un errore. Nella finestra di dialogo Abilita bilanciamento del carico, espandere l'area dei dettagli, farvi clic con il pulsante destro del mouse e quindi scegliere Copia script.
Aprire Blocco note e incollare il contenuto degli Appunti. Ad esempio:
Set-RemoteAccessLoadBalancer -InternetDedicatedIPAddress @('10.244.4.19 /255.255.255.0','fdc4:29bd:abde:3333::2/128') -InternetVirtualIPAddress @('fdc4:29bd:abde:3333::1/128', '10.244.4.21 /255.255.255.0') -ComputerName 'DA1.domain1.corp.contoso.com' -VerboseChiudere eventuali finestre di dialogo di Accesso remoto aperte e chiudere la Console di gestione Accesso remoto.
Modificare il testo incollato e rimuovere gli indirizzi IPv6. Ad esempio:
Set-RemoteAccessLoadBalancer -InternetDedicatedIPAddress @('10.244.4.19 /255.255.255.0') -InternetVirtualIPAddress @('10.244.4.21 /255.255.255.0') -ComputerName 'DA1.domain1.corp.contoso.com' -VerboseIn una finestra di PowerShell con privilegi elevati, eseguire il comando del passaggio precedente.
Se il cmdlet non riesce in fase di esecuzione (non a causa di valori di input non corretti), eseguire il comando Restore RemoteAccess.ps1 e seguire le istruzioni per assicurarsi che l'integrità della configurazione originale venga mantenuta.
È ora possibile riaprire la Console di gestione Accesso remoto.