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

  • Artikel

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

CLIENT1 ist jetzt für DirectAccess-Tests bereit.

  • Testen Sie DirectAccess-Konnektivität aus dem Internet. Verbinden Sie CLIENT1 mit dem simulierten Internet. Beim Herstellen der Verbindung mit dem simulierten Internet wird dem Client eine öffentliche IPv4-Adresse 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 Funktionalität des Clusters. 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-Cache-Timeouts und Änderungen im Zusammenhang mit NLB. Beim Validieren einer NLB-Konfiguration in einem Testlab müssen Sie etwas Geduld haben, da Änderungen der Konfiguration sich erst nach einem bestimmten Zeitraum in der Konnektivität widerspiegeln. Behalten Sie dies beim Ausführen der folgenden Aufgaben im Hinterkopf.

    Tipp

    Es wird empfohlen, den Internet Explorer-Cache vor dem Ausführen dieses Verfahrens und bei jedem Testen der Verbindung über einen anderen Remotezugriffsserver zu leeren – so stellen Sie sicher, dass Sie tatsächlich die Verbindung testen und nicht die Webseiten aus dem Cache abrufen.

Testen der DirectAccess-Konnektivität aus dem Internet

  1. Trennen Sie CLIENT1 vom Corpnet-Switch, und verbinden Sie ihn mit dem Internet-Switch. Warten Sie 30 Sekunden.

  2. Geben Sie in einem Windows PowerShell-Fenster mit erhöhten Rechten 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.

  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 Remotezugriffs-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 Remotezugriffs-DNS-Servers (pingen, um die Konnektivität mit dem Server zu bestätigen. In diesem Beispiel wäre das „2001:db8:1::2“.

  4. Geben Sie im Windows PowerShell-Fenster ping app1 ein, und drücken Sie die EINGABETASTE. Sie sollten Antworten von der IPv6-Adresse für APP1 sehen, 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 Fähigkeit, APP2 anzupingen, ist wichtig, denn der Erfolg zeigt an, dass Sie eine Verbindung über NAT64/DNS64 herstellen konnten, da APP2 eine reine IPv4-Ressource ist.

  6. Lassen Sie das Windows PowerShell-Fenster für den nächste Vorgang geöffnet.

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

  8. Geben Sie in der Internet Explorer-Adressleiste https://app2/ ein, 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 eine Verbindung zu einem reinen IPv4-Server über SMB herstellen konnten, um eine Ressource in der Ressourcendomäne zu erhalten.

  10. Geben Sie auf dem Startbildschirm zuerst wf.msc ein und drücken Sie dann die EINGABETASTE.

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

  12. Erweitern Sie im linken Bereich der Konsole den Knoten Überwachung, und klicken Sie auf den Knoten Verbindungssicherheitsregeln. Es sollten die aktiven Verbindungssicherheitsregeln 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 für den Aufbau des Intranet-Tunnels verwendet und die dritte Regel (ClientToInfra) NTLMv2 für den Aufbau des Infrastruktur-Tunnels.

  13. Erweitern Sie im linken Bereich der Konsole den Knoten Sicherheitszuordnungen und klicken Sie auf den Knoten Hauptmodus. Beachten Sie die Infrastruktur-Tunnel-Sicherheitszuordnung mit NTLMv2 und die Intranet-Tunnel-Sicherheitszuordnung mit Kerberos V5. Klicken Sie mit der rechten Maustaste auf den Eintrag Benutzer (Kerberos V5) als 2. Authentifizierungsmethode und klicken Sie auf Eigenschaften. Auf der Registerkarte Allgemein sehen Sie, dass die Zweite Authentifizierungs-Local-IDCORP\User1 lautet, was bedeutet, dass User1 sich erfolgreich über Kerberos bei der Domäne des Unternehmensnetzwerkes authentifizieren konnte.

Testen der DirectAccess-Clientkonnektivität über den Cluster

  1. Fahren Sie EDGE2 ordnungsgemäß herunter.

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

  2. Geben Sie auf CLIENT1 im Windows PowerShell-Fenster ipconfig /flushdns ein, und drücken Sie die EINGABETASTE. Dadurch werden alle Namenauflösungseinträge gelöscht, die möglicherweise noch im DNS-Cache des Clients vorhanden sind.

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

  4. Geben Sie im Bildschirm Start\\app2\files ein. Der freigegebene Ordner sollte auf dem APP2-Computer angezeigt werden. Die Tatsache, dass die Dateifreigabe auf dem APP2-Computer geöffnet werden kann, weist darauf hin, dass der zweite Tunnel, der eine Kerberos-Authentifizierung für den Benutzer erfordert, ordnungsgemäß funktioniert.

  5. Öffnen Sie Internet Explorer, und öffnen Sie dann die Websites https://app1/ und https://app2/.. Die Tatsache, dass beide Websites geöffnet werden können, bestätigt, dass sowohl der erste als auch der zweite Tunnel funktioniert. Schließen Sie Internet Explorer.

  6. Starten Sie den EDGE2-Computer.

  7. Fahren Sie EDGE1 ordnungsgemäß herunter.

  8. Warten Sie 5 Minuten, und kehren Sie dann zu CLIENT1 zurück. Führen Sie die Schritte 2–5 aus. Dadurch wird bestätigt, dass CLIENT1 in der Lage war, ein transparentes Failover auf EDGE2 auszuführen, als EDGE1 nicht mehr verfügbar war.