PASSAGGIO 6: Testare la connettività del client DirectAccess da dietro un dispositivo NAT

  • Articolo

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

Quando un client DirectAccess è connesso a Internet da dietro un dispositivo NAT o un server proxy Web, il client DirectAccess usa Teredo o IP-HTTPS per il collegamento al server di Accesso remoto.

Se il dispositivo NAT abilita la porta UDP in uscita 3544 nell'indirizzo IP pubblico del server di Accesso remoto, viene usato Teredo. Se l'accesso a Teredo non è disponibile, il client DirectAccess esegue il fallback a IP-HTTPS sulla porta TCP in uscita 443, che abilita l'accesso attraverso i firewall o i server proxy Web sulla porta SSL tradizionale.

Se un proxy Web richiede l'autenticazione, la connessione IP-HTTPS non riesce. Le connessioni IP-HTTPS non riescono anche quando il proxy Web esegue un'ispezione SSL in uscita perché la sessione HTTPS viene terminata nel proxy Web invece che nel server di Accesso remoto. In questa sezione vengono eseguiti gli stessi test usati per la connessione 6to4 descritta nella precedente sezione.

Le seguenti procedure vengono eseguite in entrambi i computer client:

  1. Testare la connettività Teredo. Il primo set di test viene eseguito quando il client DirectAccess è configurato per l'uso di Teredo. Si tratta dell'impostazione automatica quando il dispositivo NAT consente l'accesso in uscita sulla porta UDP 3544.

  2. Testare la connettività IP-HTTPS. Il secondo set di test viene eseguito quando il client DirectAccess è configurato per l'uso di IP-HTTPS. Per verificare la connettività IP-HTTPS, Teredo viene disabilitato nei computer client.

Suggerimento

Si consiglia di cancellare la cache di Internet Explorer prima di eseguire queste procedure per essere certi di eseguire il test sulla connessione e non sulle pagine dei siti Web recuperate dalla cache.

Prerequisiti

Prima di eseguire i test, scollegare CLIENT1 dal commutatore Internet e collegarlo al commutatore Homenet. Se viene chiesto di definire il tipo di rete corrente, selezionare Rete domestica.

Avviare EDGE1 ed EDGE2 se non sono già in esecuzione.

Testare la connettività Teredo

  1. In CLIENT1 aprire una finestra di Windows PowerShell con privilegi elevati, digitare ipconfig /all e premere INVIO.

  2. Esaminare l'output del comando ipconfig.

    Viene stabilita una connessione Internet da dietro un dispositivo NAT per CLIENT1, a cui viene assegnato un indirizzo IPv4 privato. Quando il client DirectAccess è si trova dietro un dispositivo NAT e viene assegnato un indirizzo IPv4 privato, la tecnologia di transizione IPv6 preferita è Teredo. Se si osserva l'output del comando ipconfig, si vede una sezione per Tunnel adapter Teredo Tunneling Pseudo-Interface e una descrizione Microsoft Teredo Tunneling Adapter, con un indirizzo IP che inizia con 2001:, conforme alla struttura degli indirizzi Teredo. Se la sezione Teredo non è visualizzata, abilitare Teredo con il comando netsh interface Teredo set state enterpriseclient e quindi eseguire nuovamente il comando ipconfig. Per la scheda tunnel Teredo non viene visualizzato un gateway predefinito.

  3. Nella finestra di Windows PowerShell, 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 a Internet, vengono cancellate.

  4. 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; in questo esempio, viene eseguito il ping di 2001:db8:1::2.

  5. Nella finestra di Windows PowerShell, digitare ping app1 e premere INVIO. Vengono visualizzate le risposte dall'indirizzo IPv6 di APP1, 2001:db8:1::3.

  6. 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.

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

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

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

  10. 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 disponibile in un host solo IPv4.

Testare la connettività IP-HTTPS

  1. Aprire una finestra di Windows PowerShell con privilegi elevati, digitare netsh interface teredo set state disabled e premere INVIO. Teredo viene disabilitato nel computer client, che può quindi eseguire la configurazione per l'uso di IP-HTTPS. Quando il comando viene completato, viene visualizzata la risposta Ok .

  2. Nella finestra di Windows PowerShel, digitare ipconfig /all e premere INVIO.

  3. Esaminare l'output del comando ipconfig. Viene stabilita una connessione Internet da dietro un dispositivo NAT per il computer, a cui viene assegnato un indirizzo IPv4 privato. Teredo viene disabilitato e il client DirectAccess esegue il fallback a IP-HTTPS. Se si osserva l'output del comando ipconfig, si vede una sezione per Tunnel adapter iphttpsinterface con un indirizzo IP che inizia con 2001:db8:1:100, conforme alla struttura degli indirizzi IP-HTTPS, che si basano sul prefisso configurato durante la configurazione di DirectAccess. Per la scheda tunnel IP-HTTPS non viene visualizzato un gateway predefinito.

  4. Nella finestra di Windows PowerShell, 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.

  5. Nella finestra di Windows PowerShell, digitare ping app1 e premere INVIO. Vengono visualizzate le risposte dall'indirizzo IPv6 di APP1, 2001:db8:1::3.

  6. 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.

  7. Aprire Internet Explorer, quindi nella barra degli indirizzi immettere https://app1/ e premere INVIO. Viene visualizzato il sito 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 disponibile in un host solo IPv4.