PASSAGGIO 5: Testare la connettività di DirectAccess da Internet e tramite il cluster

  • Articolo

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

CLIENT1 è ora pronto per i test di DirectAccess.

  • Testare la connettività di DirectAccess da Internet. Connettersi CLIENT1 a Internet simulato. Quando si è connessi a Internet simulato, al client vengono assegnati indirizzi IPv4 pubblici. Quando a un client DirectAccess viene assegnato un indirizzo IPv4 pubblico, tenta di stabilire una connessione al server di Accesso remoto usando una tecnologia di transizione IPv6.

  • Testare la connettività del client DirectAccess tramite il cluster. Testare la funzionalità del cluster. Prima di iniziare il test, è consigliabile arrestare EDGE1 e EDGE2 per almeno cinque minuti. Esistono diversi motivi per cui ciò accade, tra cui timeout della cache ARP e modifiche correlate al bilanciamento carico di rete. Quando si convalida la configurazione di NLB in un laboratorio di test, è necessario avere pazienza, poiché le modifiche alla configurazione non si rifletteranno immediatamente sulla connettività se non dopo un certo periodo di tempo. Questo aspetto è importante da tenere presente quando si eseguono le attività seguenti.

    Suggerimento

    È consigliabile cancellare la cache di Internet Explorer prima di eseguire questa procedura e ogni volta che si testa la connessione tramite un server di Accesso remoto diverso per assicurarsi di testare la connessione e di non recuperare le pagine Web dalla cache.

Testare la connettività di DirectAccess da Internet

  1. Scollegare CLIENT1 dal commutatore corpnet e connetterlo al commutatore Internet. Attendere 30 secondi.

  2. In una finestra di Windows PowerShell con privilegi elevati digitare ipconfig /flushdns e premere INVIO. Le eventuali voci di risoluzione dei nomi ancora esistenti nella cache DNS del client, create quando il computer client era connesso alla rete aziendale, vengono cancellate.

  3. Nella finestra di Windows PowerShell digitare Get-DnsClientNrptPolicy e premere INVIO.

    L'output visualizza le impostazioni correnti per la tabella dei criteri di risoluzione dei nomi (NRPT). Queste impostazioni indicano che tutte le connessioni a .corp.contoso.com devono essere risolte dal server DNS di Accesso remoto, con l'indirizzo IPv6 2001:db8:1::2. Inoltre, annotare la voce NRPT che indica un'esenzione per il nome nls.corp.contoso.com; i nomi nell'elenco delle esenzioni non ricevono risposta dal server DNS di Accesso remoto. È possibile eseguire il ping dell'indirizzo IP del server DNS di Accesso remoto per confermare la connettività al server di Accesso remoto; ad esempio, è possibile eseguire il ping di 2001:db8:1::2.

  4. Nella finestra di Windows PowerShell, digitare ping app1 e premere INVIO. Verranno visualizzate risposte dall'indirizzo IPv6 per APP1, che in questo caso è 2001:db8:1::3.

  5. Nella finestra di Windows PowerShell, digitare ping app2 e premere INVIO. Vengono visualizzate le risposte dall'indirizzo NAT64 assegnato da EDGE1 ad APP2 che, in questo caso, corrisponde a fdc9:9f4e:eb1b:7777::a00:4.

    La possibilità di effettuare il ping di APP2 è importante, perché l'esito positivo indica che è stato possibile stabilire una connessione usando NAT64/DNS64, poiché APP2 è una risorsa solo IPv4.

  6. Lasciare aperta la finestra di Windows PowerShell per la procedura successiva.

  7. Aprire Internet Explorer, quindi nella barra degli indirizzi immettere https://app1/ e premere INVIO. Viene visualizzato il sito Web IIS predefinito in APP1.

  8. Nella barra degli indirizzi di Internet Explorer immettere https://app2/ e premere INVIO. Viene visualizzato il sito Web predefinito in APP2.

  9. Nella schermata Start, digitare \\App2\Files e premere INVIO. Fare doppio clic sul file Nuovo documento di testo.

    Ciò dimostra che è stato possibile connettersi a un server solo IPv4 con SMB per ottenere una risorsa nel dominio della risorsa.

  10. Nella schermata Start, digitare wf.msc, quindi premere INVIO.

  11. Nella console di Windows Firewall con sicurezza avanzata si noti che è attivo solo il profilo privato o pubblico. Windows Firewall deve essere abilitato affinché DirectAccess funzioni correttamente. Se Windows Firewall è disabilitato, la connettività DirectAccess non funziona.

  12. Nel riquadro sinistro della console, espandere il nodo Monitoraggio e fare clic sul nodo Regole di sicurezza della connessione. Verranno visualizzate le regole di sicurezza delle connessioni attive: DirectAccess Policy-ClientToCorp, DirectAccess Policy-ClientToDNS64NAT64PrefixExemption, DirectAccess Policy-ClientToInfra e DirectAccess Policy-ClientToNlaExempt. Scorrere il riquadro centrale a destra per visualizzare le colonne 1st Authentication Methods (primi Metodi di autenticazione) e 2nd Authentication Methods (secondi Metodi di autenticazione). Si noti che la prima regola (ClientToCorp) usa Kerberos V5 per stabilire il tunnel Intranet e la terza regola (ClientToInfra) usa NTLMv2 per stabilire il tunnel dell'infrastruttura.

  13. Nel riquadro sinistro della console espandere il nodo Associazioni di sicurezza e fare clic sul nodo Modalità principale. Si notino le associazioni di sicurezza del tunnel dell'infrastruttura usando NTLMv2 e l'associazione di sicurezza del tunnel Intranet tramite Kerberos V5. Fare clic con il pulsante destro del mouse sulla voce che mostra User (Kerberos V5) come2nd Authentication Method (secondo Metodo di autenticazione) e fare clic su Proprietà. Nella scheda Generale si noti che il secondo ID locale di autenticazione è CORP\User1, a indicare che User1 è stato in grado di eseguire correttamente l'autenticazione nel dominio CORP usando Kerberos.

Testare la connettività client DirectAccess tramite il cluster

  1. Eseguire un arresto normale in EDGE2.

    È possibile usare Gestione bilanciamento carico di rete per visualizzare lo stato dei server durante l'esecuzione di questi test.

  2. Nella finestra di Windows PowerShell in CLIENT1, digitare ipconfig /flushdns e premere INVIO. In questo modo vengono scaricate le voci di risoluzione dei nomi che potrebbero essere ancora presenti nella cache DNS del client.

  3. Nella finestra di Windows PowerShell eseguire il ping di APP1 e APP2. È necessario ricevere risposte da entrambe queste risorse.

  4. Nella schermata Start digitare \\app2\files. Verrà visualizzata la cartella condivisa nel computer APP2. La possibilità di aprire la condivisione file in APP2 indica che il secondo tunnel, che richiede l'autenticazione Kerberos per l'utente, funziona correttamente.

  5. Aprire Internet Explorer, poi aprire i siti Web https://app1/ e https://app2/. La possibilità di aprire entrambi i siti Web conferma che sia il primo che il secondo tunnel sono attivi e funzionanti. Chiudere Internet Explorer.

  6. Avviare il computer EDGE2.

  7. In EDGE1 eseguire un arresto normale.

  8. Attendere 5 minuti e tornare a CLIENT1. Eseguire i passaggi da 2 a 5. Ciò conferma che CLIENT1 è stato in grado di eseguire in modo trasparente il failover a EDGE2 dopo che EDGE1 non è più disponibile.