Mit diesen Tests prüfen Sie, ob zwei Netzwerkbereiche richtig konfiguriert sind: ob das DNS interne und externe Adressen auflösen kann und ob die erforderlichen ausgehenden Ports offen sind. Diese Tests führen Sie mit Ihrer Test-VM durch.

Der Pod nutzt das DNS, um sowohl interne als auch externe Adressen aufzulösen. Mit den beiden ersten Tests wird geprüft, ob das in Ihrer Netzwerkumgebung konfigurierte DNS bekannte FQDNs für interne und externe Adressen auflösen kann.

Wichtig: Wenn Sie den gesamten Datenverkehr durch Ihr lokales Netzwerk leiten und nur authentifizierten Datenverkehr passieren lassen, aber keine Werte für die Verwendung eines Proxys im Pod-Bereitstellungsassistenten angegeben haben, schlägt trotz erfolgreicher manueller Tests der Datenverkehr, der von einer nicht authentifizierten Quelle (der Jumpbox) gesendet wird, fehl. Das Symptom dieser Situation ist, dass die Pod-Bereitstellung im ausstehenden Zustand verharrt. Wenn Sie sich in dieser Situation befinden, müssen Sie den Pod von der Seite „Erste Schritte“ löschen, den Pod-Bereitstellungsassistenten erneut ausführen und die erforderlichen Proxy-Informationen angeben.

Voraussetzungen

Stellen Sie vor dem Ausführen der Tests sicher, dass Sie in Ihrem Microsoft Azure-Abonnement eine Test-VM erstellt haben und damit eine SSH-Verbindung herstellen können. Weitere Informationen finden Sie unter Erstellen der Test-VM in Ihrem Microsoft Azure-Abonnement und Verwendung von SSH für Verbindungen mit der Test-VM.

Sie benötigen die IP-Adressen und die vollständig qualifizierten Domänennamen (FQDNs) für Server, die sich intern in Ihrem Netzwerk befinden und vom VNet erreichbar sein sollen, wie Ihr Active Directory-Domänencontroller. Diese Informationen benötigen Sie bei der DNS-Überprüfung.

Prozedur

  1. Prüfen Sie, ob das DNS in Ihrer Umgebung funktioniert und interne FQDNs auflöst, indem Sie den Befehl dlg ausführen, um einen bekannten Domänenname abzufragen, der intern in Ihrem VNet in Microsoft Azure vorhanden ist.
    Geben Sie im Fenster für die SSH-Verbindung den Befehl dig ein, um den Domänennamen eines Servers abzufragen, von dem Sie wissen, dass er sich intern in Ihrem Netzwerk befindet, z. B. Ihr Active Directory-Domänencontroller.
    dig internal-domain-name
    Wobei internal-domain-name der vollqualifizierte Domänenname eines Servers ist, von dem Sie wissen, dass er sich intern in Ihrem Netzwerk befindet.

    dig (Domain Informationen Groper) ist ein Befehlszeilentool für die Behandlung von Netzwerkproblemen. Wenn Sie diesen Befehl mit einem internen Hostnamen ausführen, wird geprüft, ob Ihre DNS-Konfiguration interne Adressen ordnungsgemäß auflösen kann. Wenn Ihre DNS-Konfiguration den im Befehl verwendeten internal-domain-name auflösen kann, wird die korrekte IP-Adresse zurückgegeben, die dem Domänenname zugeordnet ist.

    Angenommen, das VNet ist mit einem internen Active Directory-Server konfiguriert, der einen Active Directory-Domänencontroller mit dem DNS-Eintrag skylo.local und der IP-Adresse 192.168.0.15 besitzt. Wenn Sie dig skylo.local ausführen, wird geprüft, ob die VNet-DNS-Konfiguration diesen internen Servernamen skylo.local auflösen kann:
    testvmadmin@HCS-testingVM:~$ dig skylo.local
    
    ; <<>> DiG 9.10.3-P4-Ubuntu <<>> skylo.local
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64899
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4000
    ;; QUESTION SECTION:
    ;skylo.local.                   IN      A
    
    ;; ANSWER SECTION: skylo.local. 600 IN A 192.168.0.15
    
    ;; Query time: 1 msec
    ;; SERVER: 192.168.0.15#53(192.168.0.15)
    ;; WHEN: Mon Mar 26 20:58:01 UTC 2018
    ;; MSG SIZE  rcvd: 56
    
    testvmadmin@HCS-testingVM:~$
    Der Test ist erfolgreich, wenn unter ANSWER SECTION angegeben wird, dass der angegebene Hostname mit der IP-Adresse aufgelöst wurde, die Sie für diesen Hostnamen erwarten.
    Hinweis: Das DNS ist manchmal nicht 100 % zuverlässig und manche Anforderungen verlaufen fehlerfrei, während andere fehlschlagen. Wenn der Befehl beim ersten Mal fehlschlägt, führen Sie den Befehl zehn bis zwanzig mal aus und prüfen Sie, ob Sie jedes Mal eine zuverlässige Antwort erhalten.
  2. Prüfen Sie, ob das DNS in Ihrer Umgebung externe FQDNs auflösen kann, indem Sie mit dem Befehl dlg einen bekannten externen Domänennamen abfragen.
    Geben Sie im Fenster für die SSH-Verbindung den Befehl dig ein, um einen externen Domänenname, der dem Industriestandard entspricht, abzufragen, z. B. vmware.com oder microsoft.com.
    dig external-domain-name
    Dabei ist external-domain-name ein vollqualifizierter Domänenname, der sich außerhalb Ihres VNet befindet. Der Befehl dig vmware.com prüft z. B., ob die VNet-DNS-Konfiguration diesen externen Namen auflösen kann:
    testvmadmin@HCS-testingVM:~$ dig vmware.com
    
    ; <<>> DiG 9.10.3-P4-Ubuntu <<>> vmware.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38655
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4000
    ;; QUESTION SECTION:
    ;vmware.com.                    IN      A
    
    ;; ANSWER SECTION: vmware.com. 150 IN A 107.154.105.19 vmware.com. 150 IN A 107.154.106.19
    
    ;; Query time: 28 msec
    ;; SERVER: 192.168.0.15#53(192.168.0.15)
    ;; WHEN: Mon Mar 26 21:14:29 UTC 2018
    ;; MSG SIZE  rcvd: 71
    
    testvmadmin@HCS-testingVM:~
    Im obigen Beispiel wird unter ANSWER SECTION angezeigt, dass der externe Domänenname vmware.com korrekt in zwei IP-Adressen aufgelöst wurde.
    Hinweis: Sie können diesen Test mit verschiedenen externen Domänennamen wiederholen, z. B. mit azure.com oder microsoft.com, um sicherzustellen, dass Ihr DNS verschiedene externe Namen auflösen kann.
    Wenn die DNS-Tests fehlschlagen, prüfen Sie Ihre Netzwerkkonfigurationen und Ihren DNS-Server. Prüfen Sie, ob Sie Ihren DNS-Server zu Ihrem VNet hinzugefügt haben.
    Wichtig: Wenn Sie feststellen, dass Sie Ihren DNS-Server zu Ihrem VNet hinzufügen oder die DNS-Server-Konfiguration des VNet ändern müssen, müssen Sie alle VMs neu starten, die mit dem VNet verbunden sind, damit die Änderungen übernommen werden. Wenn Sie die DNS-Serverkonfiguration des VNet ändern und keinen Neustart aller mit dem VNet verbundenen VMs durchführen, werden die Änderungen nicht korrekt in das VNet übertragen.
  3. Prüfen Sie, ob die erforderlichen ausgehenden Ports verfügbar sind, indem Sie den Befehl netcat ausführen.
    Für Horizon Cloud müssen einige ausgehende Ports geöffnet sein, damit die Pod-Software sicher in Ihre Microsoft Azure-Umgebung heruntergeladen werden kann und der Pod wieder eine Verbindung zurück in die Horizon Cloud-Steuerungsebene herstellen kann. Wie unter Anforderungen an DNS für einen Horizon Cloud-Pod in Microsoft Azure beschrieben, müssen die folgenden ausgehenden TCP-Ports vom Management-Subnetz des Pods geöffnet sein: Port 80, 443 und 11371. Indem Sie den Befehl netcat wie unten angegeben ausführen, können Sie prüfen, ob die ausgehenden Ports offen sind.
    Führen Sie im Fenster für die SSH-Verbindung die folgenden Befehle aus (ein Befehl pro Port).
    Hinweis: Für den folgenden Befehl für den Test von Port 11371 wird packages.microsoft.com angegeben, um diese Verbindung zu testen, während die beiden anderen Zeilen die ausgehende Verbindung mit der Horizon Cloud-Steuerungsebene testen.
    testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 80
    Connection to cloud.horizon.vmware.com 80 port [tcp/http] succeeded!
    testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 443
    Connection to cloud.horizon.vmware.com 443 port [tcp/https] succeeded!
    testvmadmin@HCS-testingVM:~$ netcat -v -w 3 packages.microsoft.com 11371
    Connection to packages.microsoft.com 11371 port [tcp/hkp] succeeded!
    Wenn ein Port ordnungsgemäß geöffnet ist, gibt der Befehl netcat für den Test die Zeile succeeded! zurück.
    Wenn die netcat-Befehle Fehler zurückgeben, prüfen Sie Ihre Microsoft Azure-Netzwerkverbindungen, die Netzwerksicherheitsgruppen in Ihrem Abonnement und alle möglicherweise vorhandenen Firewalls. Stellen Sie sicher, dass Ihre Netzwerkkonfiguration die DNS-, Port- und Protokollanforderungen erfüllt, die der Pod für die Bereitstellung benötigt, wie in Anforderungen an DNS für einen Horizon Cloud-Pod in Microsoft Azure beschrieben.

Ergebnisse

Wenn die obigen Tests erfolgreich ausgeführt wurden, können Sie Ihren Pod erfolgreich bereitstellen.

Hinweis: Falls Sie für Pods optionale Funktionen konfigurieren, z. B. die RADIUS-Zwei-Faktor-Authentifizierung oder True SSO, werden eventuell zusätzliche Ports benötigt. Sie können die oben genannten Testverfahren für ausgehende Ports verwenden, um sicherzustellen, dass diese Ports ordnungsgemäß geöffnet sind.

Nächste Maßnahme

Wenn Sie den Test abgeschlossen haben, sollten Sie die Test-VM und alle zugehörigen Artefakte wie VM-Festplatte, IP-Adresse und NIC aus Ihrer Microsoft Azure-Umgebung löschen. Im Idealfall hätten Sie eine Ressourcengruppe für die Test-VM angelegt und können diese einfach löschen, um alle Artefakte der VM zu beseitigen. Folgen Sie den unter Löschen der Test-VM nach Abschluss der Tests beschriebenen Schritten.

Wichtig: Wenn Sie nicht alle Artefakte der Test-VM aus Ihrer Microsoft Azure-Umgebung löschen und die VM mit einem der Subnetze des Pods verbunden haben und Sie später versuchen, den Pod mithilfe der Aktion Löschen aus Ihrer Horizon Cloud-Umgebung zu löschen, kann das System den Pod aufgrund dieser verbleibenden verbundenen Artefakte möglicherweise nicht vollständig löschen. Wenn Sie einen Pod mit der Aktion Löschen löschen, werden von Horizon Cloud standardmäßig die Ressourcengruppen und Subnetze gelöscht, die für den Pod angelegt wurden. Microsoft Azure verhindert das Löschen von Subnetzen, die noch verwendet werden. Wenn die Artefakte Ihrer Test-VM mit den Subnetzen des Pods verbunden sind, können diese Subnetze nicht gelöscht werden, und das Löschen des Pods ist unvollständig. Um dies zu verhindern, stellen Sie sicher, dass alle Artefakte der Test-VM gelöscht werden, nachdem Sie Ihren Pod erfolgreich bereitgestellt haben.