SCHRITT 13: Testen der DirectAccess-Konnektivität hinter einem NAT-Gerät

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016

Wenn ein DirectAccess-Client hinter einem NAT-Gerät oder einem Webproxyserver mit dem Internet verbunden wird, verwendet der DirectAccess-Client entweder Teredo oder IP-HTTPS zur Verbindungsherstellung mit dem RAS-Server. Wenn das NAT-Gerät ausgehenden UDP-Port 3544 für die öffentliche IP-Adresse des RAS-Servers aktiviert, wird Teredo verwendet. Wenn kein Teredo-Zugriff verfügbar ist, fällt der DirectAccess-Client auf IP-HTTPS über den ausgehenden TCP-Port 443 zurück, wodurch der Zugriff durch Firewalls oder Webproxyserver über den herkömmlichen SSL-Port ermöglicht wird. Falls eine Authentifizierung für den Webproxy erforderlich ist, wird die IP-HTTPS-Verbindung fehlschlagen. IP-HTTPS-Verbindungen schlagen auch fehl, wenn vom Webproxy eine ausgehende SSL-Prüfung durchgeführt wird, da die HTTPS-Sitzung am Webproxy anstatt am RAS-Server beendet wird.

Die folgenden Verfahren werden auf beiden Clientcomputern ausgeführt:

  1. Testen Sie die Teredo-Konnektivität. Die ersten Tests werden ausgeführt, wenn der DirectAccess-Client für die Verwendung von Teredo konfiguriert ist. Das ist die automatische Einstellung, wenn das NAT-Gerät ausgehenden Zugriff auf den UDP-Port 3544 ermöglicht. Führen Sie zuerst die Tests auf CLIENT1 und dann die Tests auf CLIENT2 aus.

  2. Testen Sie die IP-HTTPS-Konnektivität. Die zweite Gruppe von Tests wird ausgeführt, wenn der DirectAccess-Client für die Verwendung von IP-HTTPS konfiguriert ist. Um IP-HTTPS-Konnektivität vorzuführen, wird Teredo auf den Clientcomputern deaktiviert. Führen Sie zuerst die Tests auf CLIENT1 und dann die Tests auf CLIENT2 aus.

Voraussetzungen

Starten Sie EDGE1 und 2-EDGE1, wenn sie noch nicht ausgeführt werden, und stellen Sie sicher, dass sie mit dem Internetsubnetz verbunden sind.

Bevor Sie diese Tests durchführen, trennen Sie CLIENT1 und CLIENT2 vom Internetschalter, und verbinden Sie sie mit dem Homenet-Switch. Wenn Sie gefragt werden, welcher Netzwerktyp Sie das aktuelle Netzwerk definieren möchten, wählen Sie Startnetzwerk aus.

Testen der Teredo-Konnektivität

  1. Öffnen Sie auf CLIENT1 ein Fenster mit erhöhten Windows PowerShell.

  2. Aktivieren Sie den Teredo-Adapter, geben Sie netsh interface teredo set state enterpriseclient ein, und drücken Sie dann die EINGABETASTE.

  3. Geben Sie im fenster Windows PowerShell ipconfig /all ein, und drücken Sie die EINGABETASTE.

  4. Prüfen Sie die Ausgabe des Befehls "ipconfig".

    Dieser Computer ist jetzt hinter einem NAT-Gerät mit dem Internet verbunden und hat eine private IPv4-Adresse erhalten. Wenn sich der DirectAccess-Client hinter einem NAT-Gerät befindet und eine private IPv4-Adresse zugeordnet wurde, wird Teredo als IPv6-Übergangstechnologie bevorzugt. Wenn Sie sich die Ausgabe des Befehls ipconfig ansehen, sollten Sie einen Abschnitt für Tunnel Adapter Teredo Tunneling Pseudo-Interface und dann eine Beschreibung des Microsoft Teredo Tunneling-Adapters mit einer IP-Adresse sehen, die mit 2001:0 beginnt und mit einer Teredo-Adresse übereinstimmt. Das Standardgateway sollte für den Teredo-Tunneladapter als "::" aufgeführt werden.

  5. Geben Sie im fenster Windows PowerShell ipconfig /flushdns ein, und drücken Sie die EINGABETASTE.

    Dadurch werden Namensauflösungseinträge geleert, die eventuell noch im Client-DNS-Cache vorhanden sind, seitdem der Clientcomputer mit dem Internet verbunden wurde.

  6. Geben Sie im Windows PowerShell Fenster ping app1 ein, und drücken Sie die EINGABETASTE. Es sollten Antworten von der IPv6-Adresse von APP1 "2001:db8:1::3" angezeigt werden.

  7. Geben Sie im Windows PowerShell Fenster ping app2 ein, und drücken Sie die EINGABETASTE. Es sollten Antworten von der NAT64-Adresse angezeigt werden, die von EDGE1 an APP2 zugewiesen wurde. In diesem Fall ist dies fdc9:9f4e:eb1b:7777::a00:4. Beachten Sie, dass die fett formatierten Werte aufgrund der Art und Weise, wie die Adresse generiert wird, variieren.

  8. Geben Sie im Windows PowerShell Fenster ping 2-app1 ein, und drücken Sie die EINGABETASTE. Es sollten Antworten von der IPv6-Adresse 2-APP1, 2001:db8:2::3 angezeigt werden.

  9. Öffnen Sie Internet Explorer, geben https://2-app1/ Sie in der Internet Explorer Adressleiste ein, und drücken Sie die EINGABETASTE. Die IIS-Standardwebsite wird auf 2-APP1 angezeigt.

  10. Geben Sie in der Internet Explorer Adressleiste ein https://app2/ , und drücken Sie die EINGABETASTE. Die Standardwebsite auf APP2 wird angezeigt.

  11. Geben Sie auf dem Startbildschirm\\App2\Files ein, und drücken Sie dann die EINGABETASTE. Doppelklicken Sie auf die neue Textdokumentdatei. Dadurch wird bewiesen, dass Sie eine Verbindung zu einem reinen IPv4-Server herstellen konnten, indem Sie mit SMB eine Ressource auf einem reinen IPv4-Host abgerufen haben.

  12. Wiederholen Sie dieses Verfahren auf CLIENT2.

IP-HTTPS-Konnektivität testen

  1. Öffnen Sie auf CLIENT1 ein Fenster mit erhöhten Windows PowerShell, geben Sie netsh interface teredo set state disabled ein, und drücken Sie die EINGABETASTE. Dadurch wird Teredo auf dem Clientcomputer deaktiviert. Der Clientcomputer kann sich nun selbst für IP-HTTPS konfigurieren. Nach Ausführung des Befehls wird die Antwort OK angezeigt.

  2. Geben Sie im fenster Windows PowerShell ipconfig /all ein, und drücken Sie die EINGABETASTE.

  3. Prüfen Sie die Ausgabe des Befehls "ipconfig". Dieser Computer ist jetzt hinter einem NAT-Gerät mit dem Internet verbunden und hat eine private IPv4-Adresse erhalten. Teredo ist deaktiviert, und der DirectAccess-Client fällt auf IP-HTTPS zurück. Wenn Sie sich die Ausgabe des Befehls ipconfig ansehen, wird ein Abschnitt für Tunnel Adapter iphttpsinterface mit einer IP-Adresse angezeigt, die mit 2001:db8:1:1000 oder 2001:db8:2:2000 beginnt, wobei es sich dabei um eine IP-HTTPS-Adresse handelt, die auf den Präfixen basiert, die beim Einrichten von DirectAccess konfiguriert wurden. Für den IPHTTPSInterface-Tunneladapter wird kein Standardgateway aufgeführt.

  4. Geben Sie im fenster Windows PowerShell ipconfig /flushdns ein, und drücken Sie die EINGABETASTE. Dadurch werden Namensauflösungseinträge geleert, die eventuell noch im Client-DNS-Cache vorhanden sind, seitdem der Clientcomputer mit dem Unternehmensnetzwerk verbunden war.

  5. Geben Sie im Windows PowerShell Fenster ping app1 ein, und drücken Sie die EINGABETASTE. Es sollten Antworten von der IPv6-Adresse von APP1 "2001:db8:1::3" angezeigt werden.

  6. Geben Sie im Windows PowerShell Fenster ping app2 ein, und drücken Sie die EINGABETASTE. Es sollten Antworten von der NAT64-Adresse angezeigt werden, die von EDGE1 an APP2 zugewiesen wurde. In diesem Fall ist dies fdc9:9f4e:eb1b:7777::a00:4. Beachten Sie, dass die fett formatierten Werte aufgrund der Art und Weise, wie die Adresse generiert wird, variieren.

  7. Geben Sie im Windows PowerShell Fenster ping 2-app1 ein, und drücken Sie die EINGABETASTE. Es sollten Antworten von der IPv6-Adresse 2-APP1, 2001:db8:2::3 angezeigt werden.

  8. Öffnen Sie Internet Explorer, geben https://2-app1/ Sie in der Internet Explorer Adressleiste ein, und drücken Sie die EINGABETASTE. Die IIS-Standardwebsite wird auf 2-APP1 angezeigt.

  9. Geben Sie in der Internet Explorer Adressleiste ein https://app2/ , und drücken Sie die EINGABETASTE. Die Standardwebsite auf APP2 wird angezeigt.

  10. Geben Sie auf dem Startbildschirm\\App2\Files ein, und drücken Sie dann die EINGABETASTE. Doppelklicken Sie auf die neue Textdokumentdatei. Dadurch wird bewiesen, dass Sie eine Verbindung zu einem reinen IPv4-Server herstellen konnten, indem Sie mit SMB eine Ressource auf einem reinen IPv4-Host abgerufen haben.

  11. Wiederholen Sie dieses Verfahren auf CLIENT2.