SCHRITT 5: Testen der DirectAccess-Konnektivität über das Internet und über den Cluster

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

CLIENT1 ist jetzt für DirectAccess-Tests bereit.

  • Testen Sie die DirectAccess-Konnektivität über das Internet. Verbinden CLIENT1 in das simulierte Internet. Wenn eine Verbindung mit dem simulierten Internet besteht, wird dem Client öffentliche IPv4-Adressen zugewiesen. Wenn einem DirectAccess-Client eine öffentliche IPv4-Adresse zugewiesen wird, versucht er, mithilfe einer IPv6-Übergangstechnologie eine Verbindung mit dem Remotezugriffsserver herzustellen.

  • Testen Sie die DirectAccess-Clientkonnektivität über den Cluster. Testen sie die Clusterfunktionalität. Bevor Sie mit dem Testen beginnen, empfiehlt es sich, EDGE1 und EDGE2 mindestens fünf Minuten lang herunterzufahren. Dafür gibt es eine Reihe von Gründen, z. B. ARP-Cachetimeouts und Änderungen im Zusammenhang mit NLB. Wenn Sie die NLB-Konfiguration in einer Testumgebung überprüfen, müssen Sie mit Vorsicht rechnen, da Änderungen in der Konfiguration erst nach Ablauf einer Bestimmten Zeit in der Konnektivität berücksichtigt werden. Dies ist wichtig, wenn Sie die folgenden Aufgaben ausführen.

    Tipp

    Es wird empfohlen, den Internet Explorer Cache zu löschen, bevor Sie dieses Verfahren ausführen, und jedes Mal, wenn Sie die Verbindung über einen anderen RAS-Server testen, um sicherzustellen, dass Sie die Verbindung testen und die Webseiten nicht aus dem Cache abrufen.

Testen der DirectAccess-Konnektivität über das Internet

  1. Trennen Sie CLIENT1 vom CorpNET-Switch, und stellen Sie eine Verbindung mit dem Internetschalter her. Warten Sie 30 Sekunden.

  2. Geben Sie in einem Fenster mit erhöhten Windows PowerShell ipconfig /flushdns ein, und drücken Sie die EINGABETASTE. Dadurch werden Einträge zur Namensauflösung geleert, die möglicherweise noch im DNS-Cache des Clients vorhanden sind, als der Clientcomputer mit dem Corpnet verbunden war.

  3. Geben Sie im Windows PowerShell Fenster Get-DnsClientNrptPolicy ein, und drücken Sie die EINGABETASTE.

    In der Ausgabe werden die aktuellen Einstellungen der Richtlinientabelle für die Namensauflösung (Name Resolution Policy Table, NRPT) angezeigt. Diese Einstellungen geben an, dass alle Verbindungen mit .corp.contoso.com vom REMOTEZUGRIFF-DNS-Server mit der IPv6-Adresse 2001:db8:1::2 aufgelöst werden sollen. Beachten Sie außerdem den NRPT-Eintrag, dass eine Ausnahme für den Namen "nls.corp.contoso.com" vorhanden ist; Namen in der Ausnahmeliste werden vom Remote-Access-DNS-Server nicht beantwortet. Sie können die IP-Adresse des REMOTEZUGRIFF-DNS-Servers pingen, um die Konnektivität mit dem RAS-Server zu bestätigen. Sie können beispielsweise 2001:db8:1::2 pingen.

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

  5. Geben Sie im Windows PowerShell Fenster ping app2 ein, und drücken Sie die EINGABETASTE. Sie sollten Antworten von der NAT64-Adresse erhalten, die von EDGE1 zu APP2 zugeordnet wurde (in diesem Fall "fdc9:9f4e:eb1b:7777::a00:4").

    Die Möglichkeit, APP2 zu pingen, ist wichtig, da der Erfolg darauf hindeutet, dass Sie eine Verbindung über NAT64/DNS64 herstellen konnten, da APP2 nur eine IPv4-Ressource ist.

  6. Lassen Sie das fenster Windows PowerShell für die nächste Prozedur geöffnet.

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

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

  9. Geben Sie auf dem Startbildschirm\\App2\Files ein, und drücken Sie dann die EINGABETASTE. Doppelklicken Sie auf die neue Textdokumentdatei.

    Dies zeigt, dass Sie mithilfe von SMB eine Verbindung mit einem reinen IPv4-Server herstellen konnten, um eine Ressource in der Ressourcendomäne abzurufen.

  10. Geben Sie auf dem Startbildschirmwf.msc ein, und drücken Sie dann die EINGABETASTE.

  11. Beachten Sie in der Windows-Konsole Firewall mit erweiterter Sicherheit, dass nur das private oder öffentliche Profil aktiv ist. Die Windows Firewall muss aktiviert sein, damit DirectAccess ordnungsgemäß funktioniert. Wenn die Windows Firewall deaktiviert ist, funktioniert die DirectAccess-Konnektivität nicht.

  12. Erweitern Sie im linken Bereich der Konsole den Knoten Überwachung , und klicken Sie auf den Knoten Verbindungssicherheitsregeln . Es sollten die aktiven Sicherheitsregeln für Verbindungen angezeigt werden: DirectAccess Policy-ClientToCorp, DirectAccess Policy-ClientToDNS64NAT64PrefixExemption, DirectAccess Policy-ClientToInfra und DirectAccess Policy-ClientToNlaExempt. Scrollen Sie im mittleren Bereich nach rechts, um die Spalten 1. Authentifizierungsmethoden und 2. Authentifizierungsmethoden anzuzeigen. Beachten Sie, dass die erste Regel (ClientToCorp) Kerberos V5 verwendet, um den Intranettunnel einzurichten, und die dritte Regel (ClientToInfra) verwendet NTLMv2, um den Infrastrukturtunnel einzurichten.

  13. Erweitern Sie im linken Bereich der Konsole den Knoten Sicherheitszuordnungen , und klicken Sie auf den Knoten Hauptmodus . Beachten Sie die Infrastrukturtunnel-Sicherheitszuordnungen mit NTLMv2 und die Tunnelsicherheitszuordnung im Intranet mit Kerberos V5. Klicken Sie mit der rechten Maustaste auf den Eintrag , der Benutzer (Kerberos V5) als zweite Authentifizierungsmethode anzeigt, und klicken Sie auf Eigenschaften. Beachten Sie auf der Registerkarte Allgemein die zweite lokale Authentifizierungs-IDCORP\User1, die angibt, dass User1 sich mit Kerberos erfolgreich bei der CORP-Domäne authentifizieren konnte.

Testen der DirectAccess-Clientkonnektivität über den Cluster

  1. Führen Sie ein ordnungsgemäßes Herunterfahren auf EDGE2 durch.

    Sie können den Netzwerklastenausgleichs-Manager verwenden, um den Status der Server anzuzeigen, wenn Sie diese Tests ausführen.

  2. Geben Sie auf CLIENT1 im fenster Windows PowerShell ipconfig /flushdns ein, und drücken Sie die EINGABETASTE. Dadurch werden Einträge zur Namensauflösung geleert, die möglicherweise noch im DNS-Cache des Clients vorhanden sind.

  3. Pingen Sie im fenster Windows PowerShell APP1 und APP2. Sie sollten Antworten von beiden Ressourcen erhalten.

  4. Geben Sie auf dem Startbildschirm\\app2\files ein. Der freigegebene Ordner sollte auf dem COMPUTER APP2 angezeigt werden. Die Möglichkeit, die Dateifreigabe in APP2 zu öffnen, gibt an, dass der zweite Tunnel, für den die Kerberos-Authentifizierung für den Benutzer erforderlich ist, ordnungsgemäß funktioniert.

  5. Öffnen Sie Internet Explorer, und öffnen Sie dann die Websites https://app1/ und . https://app2/. Die Möglichkeit, beide Websites zu öffnen, bestätigt, dass sowohl der erste als auch der zweite Tunnel betriebsfähig sind und funktionieren. Schließen Sie Internet Explorer.

  6. Starten Sie den EDGE2-Computer.

  7. Führen Sie auf EDGE1 ein ordnungsgemäßes Herunterfahren aus.

  8. Warten Sie fünf Minuten, und kehren Sie dann zu CLIENT1 zurück. Führen Sie die Schritte 2 bis 5 aus. Dadurch wird bestätigt, dass CLIENT1 ein transparentes Failover auf EDGE2 durchführen konnte, nachdem EDGE1 nicht mehr verfügbar war.