In diesem Dokumentationsthema wird erläutert, was angezeigt wird, wenn Sie sich nach der Verwendung von Horizon Cloud zum Erstellen eines Pods bei Ihrem Microsoft Azure-Abonnement und anschließend beim Microsoft Azure-Portal anmelden, um zu sehen, was der Pod-Bereitsteller dort erstellt hat. Im Rahmen der Bereitstellung des Pods in Microsoft Azure erstellt der automatisierte Bereitstellungsprozess einen Satz mit Netzwerksicherheitsgruppen (NSGs) und ordnet diesen jeweils einzelne spezifische Netzwerkkarten (NICs) zu, die sich auf den von VMware kontrollierten, Pod-bezogenen virtuellen Maschinen (VMs) befinden. Diese Pod-VMs sind die Manager-VMs des Pods und die VMs, die beim Konfigurieren des Pods mit Unified Access Gateway bereitgestellt werden. Während der Ausführung von Workflows bezüglich der Pod-Bereitstellung, z. B. Bereitstellen eines Pods oder Hinzufügen einer Gateway-Konfiguration zu einem Pod, verfügt die temporäre Jumpbox auch über eine NSG in der temporären Jumpbox-Ressourcengruppe. Der Pod-Bereitsteller ordnet die vom Bereitsteller erstellte NSG der entsprechenden Netzwerkkarte zu, die vom VMware-Design und der Architektur für den Pod festgelegt wird. Diese NSGs werden auf der Ebene der Netzwerkkarte verwendet, um sicherzustellen, dass jede Netzwerkkarte auf einer bestimmten von VMware verwalteten Appliance den Datenverkehr empfangen kann, den die von VMware verwaltete Appliance für Standarddienst- und Pod-Vorgänge über das angeschlossene Subnetz der Netzwerkkarte erhalten soll, und um den gesamten Datenverkehr zu blockieren, der von der Appliance nicht empfangen werden soll. Jede NSG enthält einen Satz mit Sicherheitsregeln, die den zulässigen Datenverkehr zu und von den einzelnen Netzwerkkarten definieren.

Die hier beschriebenen NSGs sind getrennt von denen, die für die von Ihnen im Pod erstellten Farmen und VDI-Desktops verwendet werden und weisen unterschiedliche Nutzungsdaten auf. Informationen zu den NSGs, die für Farmen und Pools verwendet werden, finden Sie unter Informationen zu Netzwerksicherheitsgruppen und Farmen in einem Horizon Cloud-Pod und Informationen zu Netzwerksicherheitsgruppen und VDI-Desktops in einem Horizon Cloud-Pod.

Warnung: Die hier beschriebenen, vom Bereitsteller erstellten NSG-Regeln sind die Konfigurationsanforderungen des Diensts. Sie sollten nie Horizon Cloud-NSGs löschen oder bearbeiten, die automatisch erstellt und mit den Netzwerkkarten der Pod-VM verknüpft sind. Zu dieser Anweisung gehören beispielsweise folgende Aktionen:
  • Kopieren oder Verschieben dieser NSGs oder NSG-Regeln in ein von Horizon Cloud verwendetes Subnetz
  • Kopieren oder Verschieben dieser NSGs oder NSG-Regeln zwischen den Netzwerkkarten, die den Pod-VMs zugeordnet sind.

Die von Horizon Cloud erstellten NSGs und die darin enthaltenen Regeln sind spezifisch für die jeweiligen Netzwerkkarten und VMs, an die Sie angehängt sind. Zudem sind sie ausdrücklich für die Zwecke dieser Netzwerkkarten und VMs vorgesehen. Jede Änderung an diesen NSGs oder Regeln oder jeder Versuch, sie für andere Zwecke verwenden – selbst in denselben Subnetzen, an die diese Netzwerkkarten angehängt sind – führt höchstwahrscheinlich dazu, dass der erforderliche Netzwerkdatenverkehr zu und von den NICs, an die Sie angehängt sind, gestört wird. Diese Unterbrechung wiederum kann dazu führen, dass alle Pod-Vorgänge unterbrochen werden. Der Lebenszyklus dieser NSGs wird von Horizon Cloud verwaltet und es gibt bestimmte Gründe für jeden einzelnen. Zu diesen Gründen gehören:

  • Die Möglichkeit der Cloud-Steuerungsebene, mit dem Pod zu kommunizieren.
  • Management der Pod-Infrastruktur
  • Vorgänge bezüglich des Pod-Lebenszyklus
Da diese vom Bereitsteller erstellten NSGs die Konfigurationsanforderungen des Diensts sind, werden Versuche, sie zu ändern oder zu verschieben, als nicht unterstützte Nutzung von Horizon Cloud und als Missbrauch der Dienstangebote angesehen, wie in der Service-Level-Vereinbarung für den VMware Horizon Service beschrieben.

Sie können jedoch ihre eigenen NSGs mit den Regeln Ihrer eigenen Organisation in Ressourcengruppen außerhalb der Ressourcengruppen des Pods erstellen, die von Horizon Cloud für die VMs des Pods automatisch erstellt und verwaltet werden. Die Regeln in ihren eigenen NSGs dürfen nicht mit den Horizon Cloud-Anforderungen bezüglich des Managements und der Vorgänge der Pod-VMs in Konflikt stehen. Derartige NSGs sollten an die Management-, Mandanten- und DMZ-Subnetze angehängt werden, die vom Pod verwendet werden. Das Erstellen eigener NSGs innerhalb der von Horizon Cloud verwalteten Ressourcengruppen führt zu Fehlern beim Löschen von Aktionen für die von Horizon Cloud verwalteten Ressourcengruppen, wenn Ihre NSGs in diesen Ressourcengruppen mit einer Ressource verknüpft sind, die sich in einer anderen Ressourcengruppe befindet.

Gemäß der Beschreibung in der Microsoft Azure-Dokumentation besteht der Zweck einer Netzwerksicherheitsgruppe (NSG) darin, den Netzwerkdatenverkehr zu und von Ressourcen in Ihrer Microsoft Azure-Umgebung mithilfe von Sicherheitsregeln zu filtern. Jede Regel verfügt über einen Satz mit Eigenschaften, z. B. Quelle, Ziel, Port, Protokoll usw., zur Bestimmung des zulässigen Datenverkehrs für die Ressourcen, denen die NSG zugeordnet ist. Die von Horizon Cloud automatisch erstellten und mit den von VMware kontrollierten Netzwerkkarten der Pod-VM verknüpften NSGs enthalten bestimmte Regeln, die Horizon Cloud als erforderlich für das Service-Management des Pods, für die ordnungsgemäße Ausführung laufender Pod-Vorgänge und für die Verwaltung des Pod-Lebenszyklus einstuft. Generell ist jede Regel, die in diesen NSGs definiert ist, dazu vorgesehen, den Port-Datenverkehr des Pods anzugeben, der wesentlicher Bestandteil der Diensterfüllung und des Standardgeschäftszwecks eines Horizon Cloud-Abonnements ist, z. B. der VDI-Anwendungsfall zur Bereitstellung von virtuellen Desktops für Endbenutzer. Siehe auch Port- und Protokollanforderungen für einen Horizon Cloud-Pod.

In den nachfolgenden Abschnitten werden die NSG-Regeln aufgelistet, die Horizon Cloud in diesen NSGs definiert.

Allgemeine Informationen zu diesen NSGs

Diese Liste gilt für alle vom Bereitsteller erstellten NSGs, die der Bereitsteller mit bestimmten Netzwerkkarten in den Pod-bezogenen VMs verknüpft.

  • Diese von VMware erstellten NSGs sind für die Sicherheit der von VMware kontrollierten Software-Appliances vorgesehen. Wenn VMware Ihrem Abonnement neue Software hinzufügt und zusätzliche Regeln erforderlich sind, werden diese neuen Regeln diesen NSGs hinzugefügt.
  • Im Microsoft Azure-Portal verfügen die NSGs über Namen, die das Muster vmw-hcs-podUUID enthalten, wobei podUUID der Pod-Bezeichner ist. Dies gilt jedoch nicht für NSGs, die für eine externe Gateway-Konfiguration verwendet werden, welche im eigenen VNet bereitgestellt wird. In diesem Fall haben die betreffenden NSGs des Gateways Namen, die das Muster vmw-hcs-ID enthalten, wobei ID die Bereitstellungs-ID für das besagte externe Gateway ist.
    Hinweis: Für das Szenario, in dem die externe Gateway-Konfiguration mithilfe der Option zum Bereitstellen einer vorhandenen Ressourcengruppe, die Sie in diesem Abonnement vorab erstellt haben, in einem separaten Abonnement bereitgestellt wird, wird die NSG auf der Management-Netzwerkkarte der Connector-VM in einem Muster basierend auf dem Namen der Ressourcengruppe benannt (anstelle nach dem Muster vmw-hcs-podUUID). Beispiel: Wenn Sie dieser Ressourcengruppe den Namen hcsgateways zugewiesen haben, erstellt Horizon Cloud eine NSG mit dem Namen hcsgateways-mgmt-nsg und verknüpft diese NSG mit der Management-Netzwerkkarte der Gateway-Connector-VM.

    Sie können diese Bezeichner ermitteln, indem Sie auf der Seite „Kapazität“ der Verwaltungskonsole zu den Details des Pods navigieren.

    Hinweis: Wenn Sie festlegen, dass das externe Unified Access Gateway des Pods eine benutzerdefinierte Ressourcengruppe verwendet, enthält der Name der vom Bereitsteller erstellten NSG der Gateway-Connector-VM den Namen dieser benutzerdefinierten Ressourcengruppe statt des Musters vmw-hcs-ID. Wenn Sie beispielsweise die Verwendung einer benutzerdefinierten Ressourcengruppe mit dem Namen ourhcspodgateway für das externe Gateway des Pods angeben, dann erhält die NSG, die der Bereitsteller erstellt und mit der Netzwerkkarte der Gateway-VM verknüpft, den Namen ourhcspodgateway-mgmt-nsg.
  • Die NSGs befinden sich in derselben Ressourcengruppe wie die VMs und Netzwerkkarten, denen sie zugeordnet sind. Beispiel: Die NSGs, die den Netzwerkkarten (NICs) auf den externen Unified Access Gateway-VMs zugeordnet sind, befinden sich in der Ressourcengruppe mit dem Namen vmw-hcs-podUUID-uag, wenn das externe Gateway im VNet des Pods bereitgestellt und eine vom Bereitsteller erstellte Ressourcengruppe verwendet wird. Siehe auch Für einen in Microsoft Azure bereitgestellten Pod erstellte Ressourcengruppen.
  • Horizon Cloud kann neue Regeln hinzufügen oder diese Regeln entsprechend ändern, um die Wartbarkeit des Diensts sicherzustellen.
  • Während eines Pod-Updates werden die NSGs und Regeln beibehalten. Sie werden nicht gelöscht.
  • Abgesehen von den NSG-Regeln für die temporäre Jump Box und den Virtuelle Horizon Edge-Appliance-NSG-Regeln beginnen die Horizon Cloud-Regeln mit der Priorität 1000 und die Prioritäten steigen in der Regel in 100er-Schritten. Die Horizon Cloud-Regeln enden mit einer Regel mit der Priorität 3000. Für die NSG-Regeln der Jump Box und die Virtuelle Horizon Edge-Appliance-NSG-Regeln beginnen die Horizon Cloud-Regeln mit der Priorität 100, und die Prioritäten steigen in Schritten von jeweils 1.
  • Die AllowAzureInBound-Regeln für die Quell-IP-Adresse 168.63.129.16 stellen die NSGs bereit und lassen die eingehende Kommunikation von der Microsoft Azure-Plattform zu, wie im Microsoft Azure-Dokumentationsthema Was verbirgt sich hinter der IP-Adresse 168.63.129.16 beschrieben. Alle VMs im Zusammenhang mit dem Pod sind VMs in Microsoft Azure. Wie im Microsoft Azure-Dokumentationsthema beschrieben, vereinfacht die IP-Adresse 168.63.129.16 verschiedene VM-Verwaltungsaufgaben, die die Microsoft Azure Cloud-Plattform für alle VMs in der Cloud ausführt. Beispielsweise erleichtert diese IP-Adresse die Kommunikation des VM-Agenten innerhalb der VM mit der Microsoft Azure-Plattform, um zu signalisieren, dass sich die VM im Zustand „Bereit“ befindet.
  • In den NSGs für die Unified Access Gateway-Instanzen werden die AllowPcoipUdpInBound-Regeln für jeden Port festgelegt, da der PCoIP-Datenverkehr variable Portnummern im Bereich 4173+ verwendet, sodass der Datenverkehr nicht auf bestimmte Ports beschränkt werden kann.
  • Bei der Erstellung der einzelnen NSGs erstellt Microsoft Azure automatisch einige Standardregeln darin. In jeder erstellten NSG erstellt Microsoft Azure einige eingehende und ausgehende Regeln mit der Priorität 65000 und höher. Derartige Microsoft Azure-Standardregeln werden in diesem Dokumentationsthema nicht beschrieben, da Sie von Microsoft Azure automatisch erstellt werden. Einzelheiten zu diesen Standardregeln finden Sie im Microsoft Azure-Dokumentationsthema Standard-Sicherheitsregeln.
  • Während der Ausführung von Workflows bezüglich der Pod-Bereitstellung, z. B. Bereitstellen eines Pods oder Hinzufügen einer Gateway-Konfiguration zu einem Pod, verfügt die temporäre Jump Box über eine NSG in der temporären Jump Box-Ressourcengruppe. Diese NSG wird gelöscht, wenn die Ressourcengruppe der Jump Box nach Abschluss des Workflows gelöscht wird.
  • Jede in diesen NSGs definierte Regel ist dazu vorgesehen, den Port-Datenverkehr des Pods anzugeben, der wesentlicher Bestandteil der Diensterfüllung und des Standardgeschäftszwecks eines Horizon Cloud-Abonnements ist, z. B. der VDI-Anwendungsfall zur Bereitstellung von virtuellen Desktops für Endbenutzer. Siehe auch Port- und Protokollanforderungen für einen Horizon Cloud-Pod.
  • Wenn Sie Ihren Pod bearbeiten, um zusätzliche Mandantensubnetze für die Verwendung mit Farmen und VDI-Desktop-Zuweisungen anzugeben, werden die Regeln in den Mandantensubnetz-bezogenen Netzwerkkarten der Pod-Manager-VMs und in den Netzwerkkarten der Unified Access Gateway-VMs aktualisiert, damit sie diese zusätzlichen Mandantensubnetze beinhalten.

Vom Bereitsteller der Pod Manager-VM erstellte NSGs

Die Pod Manager-VM verfügt über zwei Netzwerkkarten, wobei eine mit dem Management-Subnetz und die andere mit dem Mandanten-Subnetz verbunden ist. Der Bereitsteller erstellt für jede dieser beiden Netzwerkkarten eine spezifische NSG und ordnet jede NSG der passenden Netzwerkkarte zu.

  • Die Management-Netzwerkkarte (NIC) verfügt über eine NSG, die nach dem Muster vmw-hcs-podUUID-mgmt-nsg benannt ist.
  • Die Mandanten-Netzwerkkarte (NIC) verfügt über eine NSG, die nach dem Muster vmw-hcs-podUUID-tenant-nsg benannt ist.

In Ihrer Microsoft Azure-Umgebung befinden sich diese NSGs in der Ressourcengruppe des Pods, die nach dem Muster vmw-hcs-podUUID benannt ist.

Wichtig: Wenn der Pod die Funktion für die Verwendung seines externen Gateways in einem separaten VNet verwendet (einschließlich wenn das Gateway ein anderes Abonnement verwendet als das Abonnement des Pods), enthält die NSG für die Mandanten-NIC der VM des Pod-Managers eine zusätzliche eingehende Regel mit dem Namen AllowGatewayBrokeringHttpsInBound für Port 8443 TCP mit VirtualNetwork als Quelle. Die vom Bereitsteller erstellten NSG-Regeln auf der Mandanten-NIC der VM des Pod-Managers, wenn sich das externe Gateway in einem separaten VNet befindet, sind in der dritten Tabelle unten aufgeführt.
Tabelle 1. Vom Bereitsteller erstellte NSG-Regeln auf der Management-Netzwerkkarte (NIC) der Pod Manager-VM
Richtung Priorität Name Ports Protokoll Quelle Ziel Aktion Zweck der Regel
Eingehend 1000 AllowSshInBound 22 Beliebig Management-Subnetz Beliebig Zulassen Wie im Thema DNS-Anforderungen für einen Horizon Cloud-Pod in Microsoft und zugehörige Dienstfunktionen beschrieben, kommuniziert die kurzlebige Jump-Box-VM bei der ersten Erstellung eines Pods und während darauf folgenden Softwareaktualisierungen auf dem Pod über SSH an Port 22 der VM mit einer Pod Manager-VM. Gemäß Beschreibung in diesem Thema ist für den täglichen Pod-Betrieb die Verfügbarkeit von Port 22 auf der Pod Manager-VM nicht erforderlich. Wenn Sie jedoch bei Vorgängen mit stabilem Zustand eine Support-Anfrage an VMware stellen und das Supportteam bestimmt, dass zur Fehlerbehebung dieser Anforderung eine Jump-Box-VM für die SSH-Kommunikation mit der Pod Manager-VM bereitgestellt wird, unterstützt diese NSG-Regel diesen Anwendungsfall. Die Berechtigung wird von Ihnen vor dem Notfallzugriff angefordert.
Eingehend 1100 AllowAzureInBound Beliebig Beliebig 168.63.129.16 Beliebig Zulassen Damit die VM die eingehende Kommunikation von der Microsoft Azure-Plattform akzeptieren kann, wie im vorangegangenen Abschnitt „Allgemeine Fakten“ und im Microsoft Azure-Dokumentationsthema Was bedeutet die IP-Adresse 168.63.129.16 beschrieben.
Eingehend 1200 AllowHttpsInBound 443 Beliebig Management-Subnetz Beliebig Zulassen Damit die Cloud-Steuerungsebene sicher mit dem REST API Endpoint des Pods Managers kommunizieren kann.
Eingehend 1300 AllowApacheGeodeInBound 10334 - 10336, 41000-41002, 41100-41102, 42000-42002 Beliebig Management-Subnetz Beliebig Zulassen Diese Portgruppen werden verwendet, um Benutzersitzungen auf die Pod Manager-VMs und Dateifreigabeinformationen zwischen den Pod-Manager-VMs zu replizieren.
Eingehend 1400 AllowTelegrafInBound 9172 Beliebig Management-Subnetz Beliebig Zulassen Wenn auf dem Pod Horizon-Infrastrukturüberwachung aktiviert ist, erfasst die Virtuelle Horizon Edge-Appliance die Überwachungsdaten, für deren Erfassung Sie vorgesehen ist.
Eingehend 1500 AllowAgentJmsInBound 4001, 4002 Beliebig Management-Subnetz Beliebig Zulassen Wenn auf dem Pod Horizon-Infrastrukturüberwachung aktiviert ist, erfasst die Virtuelle Horizon Edge-Appliance die Überwachungsdaten, für deren Erfassung Sie vorgesehen ist.
Eingehend 3000 DenyAllInBound Beliebig Beliebig Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den eingehenden Datenverkehrs dieser Netzwerkkarte auf die Elemente in den vorherigen Zeilen zu beschränken.
Tabelle 2. Vom Bereitsteller erstellte NSG-Regeln auf der Mandanten-Netzwerkkarte (NIC) der Pod Manager-VM
Richtung Priorität Name Ports Protokoll Quelle Ziel Aktion Zweck
Eingehend 1000 AllowHttpsInBound

80

443

TCP VirtualNetwork Beliebig Zulassen Diese Regel dient einem untypischen Szenario, in dem Sie Ihre internen Endbenutzer angewiesen haben (in Ihrem Unternehmensnetzwerk, z. B. über VPN), ihre Clientverbindungen mit einem FQDN herzustellen, den Sie dem Microsoft Azure-Lastausgleichsdienst des Pods zugeordnet haben. Dieses Szenario wird manchmal auch als Pod-Direktverbindung bezeichnet. Für die Anmeldeauthentifizierungsanforderung an den Pod-Manager verwenden die Horizon Clients und der Horizon-Webclient Port 443. Um die einfache Umleitung für einen Benutzer zu erleichtern, der möglicherweise in seinem Client HTTP anstelle von HTTPS eingibt, kommt der Datenverkehr an Port 80 an und wird automatisch an Port 443 umgeleitet.
Eingehend 1100 AllowAgentHttpsInBound

3443

8443

TCP Mandanten-Subnetz Beliebig Zulassen

Der Eingangsport 3443 zu dieser Netzwerkkarte wird von App Volumes Agent in den Basis-VMs, Desktop-VMs und Farm RDSH-VMs verwendet, um auf den App Volumes Manager-Dienst zuzugreifen, der in der Pod Manager-VM ausgeführt wird

Der Eingangsport 8443 zu dieser Netzwerkkarte (NIC) wird von den Unified Access Gateway-Instanzen für die Überprüfung mit dem Pod-Manager verwendet. Die Gateway-Instanzen verwenden diesen Endpoint, um das Senden neuer Client-Verbindungsanforderungen an den Pod-Manager zu bestätigen.

Eingehend 1120 AllowUagHttpsInBound 8443 TCP Management-Subnetz Beliebig Zulassen Diese Regel ist für die Verwendung in einer künftigen Dienstversion geplant.
Eingehend 1200 AllowAgentJmsInBound

4001

4002

TCP Mandanten-Subnetz Beliebig Zulassen

Diese Ports werden von den Horizon Agents in den Basis-VMs,-Desktop-VMs und den Farm RDSH-VMs verwendet.

Port 4001 ist für den Java Message Service (JMS, Nicht-SSL) vorgesehen, der vom Agenten in der VM zur Kommunikation mit dem Pod als Teil der Verifizierung des Zertifikatfingerabdrucks und zum Austausch verwendet wird, um eine SSL-Verbindung mit dem Pod zu sichern.

Nachdem die Schlüssel ausgehandelt und zwischen der VM und dem Pod-Manager ausgetauscht wurden, verwendet der Agent Port 4002, um eine gesicherte SSL-Verbindung zu erstellen.
Hinweis: Die beiden Ports 4001 und 4002 sind für Vorgänge mit einem stabilen Zustand erforderlich. Mitunter muss der Agent möglicherweise einen neuen Schlüssel für den Pod erstellen.
Eingehend 1210 AllowRouterJmsInBound 4101 TCP Mandanten-Subnetz Beliebig Zulassen Wenn ein Pod für Hochverfügbarkeit (HA) aktiviert ist, erfolgt für diesen Datenverkehr ein JMS- Routing zwischen den Pod Manager-VMs (Knoten 1 und Knoten 2).
Eingehend 1300 AllowAgentUdpInBound 5678 UDP Mandanten-Subnetz Beliebig Zulassen Veraltet für Pods mit dem Manifest 1600 und höher. In der Dienstversion vom September 2019 wurde der DaaS Agent in den Horizon Agent mit dem Pod-Manifest 1600 integriert. Zuvor wurden dieser Port 5678 und das UDP-Protokoll verwendet, um die Verwendung von DaaS Agent zu unterstützen.
Eingehend 1400 AllowAzureInBound Beliebig Beliebig 168.63.129.16 Beliebig Zulassen Damit die VM die eingehende Kommunikation von der Microsoft Azure-Plattform akzeptieren kann, wie im vorangegangenen Abschnitt „Allgemeine Fakten“ und im Microsoft Azure-Dokumentationsthema Was bedeutet die IP-Adresse 168.63.129.16 beschrieben.
Eingehend 3000 DenyAllInBound Beliebig Beliebig Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den eingehenden Datenverkehrs dieser Netzwerkkarte auf die Elemente in den vorherigen Zeilen zu beschränken.
Tabelle 3. Wenn sich das externe Gateway in einem separaten VNet befindet, werden vom Bereitsteller erstellte NSG-Regeln auf der Mandanten-NIC der VM des Pod-Managers erstellt
Richtung Priorität Name Ports Protokoll Quelle Ziel Aktion Zweck
Eingehend 1000 AllowHttpsInBound

80

443

TCP VirtualNetwork Beliebig Zulassen Diese Regel dient einem untypischen Szenario, in dem Sie Ihre internen Endbenutzer angewiesen haben (in Ihrem Unternehmensnetzwerk, z. B. über VPN), ihre Clientverbindungen mit einem FQDN herzustellen, den Sie dem Microsoft Azure-Lastausgleichsdienst des Pods zugeordnet haben. Dieses Szenario wird manchmal auch als Pod-Direktverbindung bezeichnet. Für die Anmeldeauthentifizierungsanforderung an den Pod-Manager verwenden die Horizon Clients und der Horizon-Webclient Port 443. Um die einfache Umleitung für einen Benutzer zu erleichtern, der möglicherweise in seinem Client HTTP anstelle von HTTPS eingibt, kommt der Datenverkehr an Port 80 an und wird automatisch an Port 443 umgeleitet.
Eingehend 1100 AllowAgentHttpsInBound

3443

8443

TCP Mandanten-Subnetz Beliebig Zulassen

Der Eingangsport 3443 zu dieser Netzwerkkarte (NIC) wird von App Volumes Agent in den Basis-VMs, Desktop-VMs und Farm-RDSH-VMs verwendet, um auf den im Pod-Manager ausgeführten App Volumes Manager-Dienst zuzugreifen.

Der Eingangsport 8443 zu dieser Netzwerkkarte (NIC) wird von den Unified Access Gateway-Instanzen für die Überprüfung mit dem Pod-Manager verwendet. Die Gateway-Instanzen verwenden diesen Endpoint, um das Senden neuer Client-Verbindungsanforderungen an den Pod-Manager zu bestätigen.

Eingehend 1110 AllowGatewayBrokeringHttpsInBound 8443 TCP VirtualNetwork Beliebig Zulassen Wenn das externe Gateway des Pods in einem eigenen, vom Pod getrennten VNet bereitgestellt wird, unterstützt diese Regel den eingehenden Datenverkehr aus den Unified Access Gateway-Instanzen des externen Gateways für die Überprüfung mit dem Pod-Manager. Die Gateway-Instanzen verwenden diesen Endpoint, um das Senden neuer Client-Verbindungsanforderungen an den Pod-Manager zu bestätigen.
Eingehend 1120 AllowUagHttpsInBound 8443 TCP Management-Subnetz Beliebig Zulassen Diese Regel ist für die Verwendung in einer künftigen Dienstversion geplant.
Eingehend 1200 AllowAgentJmsInBound

4001

4002

TCP Mandanten-Subnetz Beliebig Zulassen

Diese Ports werden von den Horizon Agents in den Basis-VMs,-Desktop-VMs und den Farm RDSH-VMs verwendet.

Port 4001 ist für den Java Message Service (JMS, Nicht-SSL) vorgesehen, der vom Agenten in der VM zur Kommunikation mit dem Pod als Teil der Verifizierung des Zertifikatfingerabdrucks und zum Austausch verwendet wird, um eine SSL-Verbindung mit dem Pod zu sichern.

Nachdem die Schlüssel ausgehandelt und zwischen der VM und dem Pod-Manager ausgetauscht wurden, verwendet der Agent Port 4002, um eine gesicherte SSL-Verbindung zu erstellen.
Hinweis: Die beiden Ports 4001 und 4002 sind für Vorgänge mit einem stabilen Zustand erforderlich. Mitunter muss der Agent möglicherweise einen neuen Schlüssel für den Pod erstellen.
Eingehend 1210 AllowRouterJmsInBound 4101 TCP Mandanten-Subnetz Beliebig Zulassen Wenn ein Pod für Hochverfügbarkeit (HA) aktiviert ist, erfolgt für diesen Datenverkehr ein JMS- Routing zwischen den Pod Manager-VMs (Knoten 1 und Knoten 2).
Eingehend 1300 AllowAgentUdpInBound 5678 UDP Mandanten-Subnetz Beliebig Zulassen Veraltet für Pods mit dem Manifest 1600 und höher. In der Dienstversion vom September 2019 wurde der DaaS Agent in den Horizon Agent mit dem Pod-Manifest 1600 integriert. Zuvor wurden dieser Port 5678 und das UDP-Protokoll verwendet, um die Verwendung von DaaS Agent zu unterstützen.
Eingehend 1400 AllowAzureInBound Beliebig Beliebig 168.63.129.16 Beliebig Zulassen Damit die VM die eingehende Kommunikation von der Microsoft Azure-Plattform akzeptieren kann, wie im vorangegangenen Abschnitt „Allgemeine Fakten“ und im Microsoft Azure-Dokumentationsthema Was bedeutet die IP-Adresse 168.63.129.16 beschrieben.
Eingehend 3000 DenyAllInBound Beliebig Beliebig Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den eingehenden Datenverkehrs dieser Netzwerkkarte auf die Elemente in den vorherigen Zeilen zu beschränken.

Vom Bereitsteller externer Unified Access Gateway-VMs erstellte NSGs

Alle VMs für die externe Unified Access Gateway-Konfiguration verfügen über drei (3) Netzwerkkarten. Dabei ist eine mit dem Management-Subnetz, eine mit dem Mandanten-Subnetz und eine mit dem DMZ-Subnetz verbunden. Der Bereitsteller erstellt für jede dieser drei Netzwerkkarten eine bestimmte NSG und ordnet jede NSG der entsprechenden Netzwerkkarte zu.

  • Die Verwaltungs-NIC verfügt über eine NSG, die nach dem Muster vmw-hcs-ID-uag-management-nsg benannt ist.
  • Die Mandanten-NIC verfügt über eine NSG, die nach dem Muster vmw-hcs-ID-uag-tenant-nsg benannt ist.
  • Die DMZ-NIC verfügt über eine NSG, die nach dem Muster vmw-hcs-ID-uag-dmz-nsg benannt ist.

In Ihrer Microsoft Azure-Umgebung werden diese NSGs nach dem Muster vmw-hcs-ID-uag benannt, wobei ID die Pod-ID ist, die in der Konsole auf der Detailseite des Pods angezeigt wird, sofern das externe Gateway nicht separat in einem eigenen VNet, das vom VNet des Pods verschieden ist, bereitgestellt wird. Im Falle eines externen Gateways, das in einem eigenen VNet bereitgestellt wird, ist die ID der auf der Detailseite des Pods angezeigte Wert der Bereitstellungs-ID.

Tabelle 4. Vom Bereitsteller erstellte NSG-Regeln auf der Management-Netzwerkkarte (NIC) externer Unified Access Gateway-VMs
Richtung Priorität Name Ports Protokoll Quelle Ziel Aktion Zweck
Eingehend 1000 AllowHttpsInBound 9443 TCP Management-Subnetz Beliebig Zulassen Damit der Dienst die Administrationseinstellungen des Gateways mithilfe der zugehörigen Verwaltungsschnittstelle konfigurieren kann. Gemäß Beschreibung in der Unified Access Gateway-Produktdokumentation befindet sich die Verwaltungsschnittstelle an Port 9443/TCP.
Eingehend 1100 AllowAzureInBound Beliebig Beliebig 168.63.129.16 Beliebig Zulassen Damit die VM die eingehende Kommunikation von der Microsoft Azure-Plattform akzeptieren kann, wie im vorangegangenen Abschnitt „Allgemeine Fakten“ und im Microsoft Azure-Dokumentationsthema Was bedeutet die IP-Adresse 168.63.129.16 beschrieben.
Eingehend 1200 AllowSshInBound 22 Beliebig Management-Subnetz Beliebig Zulassen Damit VMware im Rahmen der Fehlerbehebung bei Bedarf einen Notfallzugriff auf die VM durchführen kann. Die Berechtigung wird von Ihnen vor dem Notfallzugriff angefordert.
Eingehend 3000 DenyAllInBound Beliebig Beliebig Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den eingehenden Datenverkehrs dieser Netzwerkkarte auf die Elemente in den vorherigen Zeilen zu beschränken.
Ausgehend 3000 DenyAllOutBound Beliebig Beliebig Beliebig Beliebig Verweigern Wurde vom Bereitsteller hinzugefügt, um ausgehenden Datenverkehr von dieser Netzwerkkarte zu verweigern.
Tabelle 5. Vom Bereitsteller erstellte NSG-Regeln auf der Mandanten-Netzwerkkarte (NIC) externer Unified Access Gateway-VMs
Richtung Priorität Name Ports Protokoll Quelle Ziel Aktion Zweck
Eingehend 1000 AllowAzureInBound Beliebig Beliebig 168.63.129.16 Beliebig Zulassen Damit die VM die eingehende Kommunikation von der Microsoft Azure-Plattform akzeptieren kann, wie im vorangegangenen Abschnitt „Allgemeine Fakten“ und im Microsoft Azure-Dokumentationsthema Was bedeutet die IP-Adresse 168.63.129.16 beschrieben.
Eingehend 1400 AllowPcoipUdpInBound Beliebig UDP Mandanten-Subnetz Beliebig Zulassen Diese Regel unterstützt die Standardkonfiguration, die für das Unified Access Gateway verwendet wird, das mit dem Horizon Agent arbeitet. Die Horizon Agents in den Desktop- und Farm-VMs senden PCoIP-Daten per UDP an die Unified Access Gateway-Instanzen zurück.
Eingehend 3000 DenyAllInBound Beliebig Beliebig Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den eingehenden Datenverkehrs dieser Netzwerkkarte auf die Elemente in den vorherigen Zeilen zu beschränken.
Ausgehend 1000 AllowHttpsOutBound

443

8443

TCP Beliebig Mandanten-Subnetz Zulassen

Diese Regel unterstützt die Unified Access Gateway-Instanzen, die wegen neuer Client-Verbindungsanforderungen an die Pod-Manager mit den Pod-Manager-VMs kommunizieren.

Ausgehend 1100 AllowBlastOutBound 22443 Beliebig Beliebig Mandanten-Subnetz Zulassen Diese Regel unterstützt den Anwendungsfall einer Horizon Client Blast Extreme-Sitzung mit dem Horizon Agent in einer Desktop- oder Farm-VM.
Ausgehend 1200 AllowPcoipOutBound 4172 Beliebig Beliebig Mandanten-Subnetz Zulassen Diese Regel unterstützt den Anwendungsfall einer Horizon Client PCoIP-Sitzung mit dem Horizon Agent in einer Desktop-VM.
Ausgehend 1300 AllowUsbOutBound 32111 TCP Beliebig Mandanten-Subnetz Zulassen Diese Regel unterstützt den Anwendungsfall des USB-Umleitungsdatenverkehrs. Die USB-Umleitung ist eine Agentenoption in den Desktop- oder Farm-VMs. Dieser Datenverkehr verwendet Port 32111 für eine Endbenutzer-Clientsitzung mit dem Horizon Agent in einer Desktop- oder Farm-VM.
Ausgehend 1400 AllowMmrOutBound 9427 TCP Beliebig Mandanten-Subnetz Zulassen Diese Regel unterstützt die Anwendungsfälle des Multimedia Redirection (MMR)- und Client Driver Redirection (CDR)-Datenverkehrs. Diese Umleitungen sind Agentenoptionen in den Desktop- oder Farm-VMs. Dieser Datenverkehr verwendet Port 9427 für eine Endbenutzer-Clientsitzung mit dem Horizon Agent in einer Desktop- oder Farm-VM.
Ausgehend 1500 AllowAllOutBound Beliebig Beliebig Beliebig Mandanten-Subnetz Zulassen Bei Ausführung in einer VM, die mehrere Benutzersitzungen unterstützt, wählt der Horizon Agent verschiedene Ports aus, die für den PCoIP-Datenverkehr der Sitzung verwendet werden. Da diese Ports nicht im Voraus ermittelt werden können, kann vorab keine NSG-Regel definiert werden, die bestimmte Ports benennt, um diesen Datenverkehr zuzulassen. Aus diesem Grund unterstützt diese Regel, ähnlich wie bei der Priorität 1200, den Anwendungsfall mehrerer Horizon Client PCoIP-Sitzungen mit solchen VMs.
Ausgehend 3000 DenyAllOutBound Beliebig Beliebig Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den ausgehenden Datenverkehr dieser Netzwerkkarte auf die Elemente in den vorherigen Zeilen zu beschränken.
Tabelle 6. Vom Bereitsteller erstellte NSG-Regeln auf der DMZ-Netzwerkkarte (NIC) externer Unified Access Gateway-VMs
Richtung Priorität Name Ports Protokoll Quelle Ziel Aktion Zweck
Eingehend 1000 AllowHttpsInBound

80

443

TCP Internet Beliebig Zulassen Diese Regel stellt den eingehenden Datenverkehr externer Endbenutzer aus den Horizon Clients und dem Horizon-Webclient bereit, um die Anmeldeauthentifizierungsanforderung an den Pod-Manager zu stellen. Standardmäßig verwenden der Horizon Client und der Horizon-Webclient Port 443 für diese Anforderung. Um die einfache Umleitung für einen Benutzer zu erleichtern, der möglicherweise in seinem Client HTTP anstelle von HTTPS eingibt, kommt der Datenverkehr an Port 80 an und wird automatisch an Port 443 umgeleitet.
Eingehend 1100 AllowBlastInBound

443

8443

Beliebig Internet Beliebig Zulassen Diese Regel unterstützt die Unified Access Gateway-Instanzen, die den Blast-Datenverkehr von den Horizon Clients der externen Endbenutzer erhalten.
Eingehend 1200 AllowPcoipInBound 4172 Beliebig Internet Beliebig Zulassen Diese Regel unterstützt die Unified Access Gateway-Instanzen, die den PCoIP-Datenverkehr von den Horizon Clients der externen Endbenutzer erhalten.
Eingehend 1300 AllowAzureInBound Beliebig Beliebig 168.63.129.16 Beliebig Zulassen Damit die VM die eingehende Kommunikation von der Microsoft Azure-Plattform akzeptieren kann, wie im vorangegangenen Abschnitt „Allgemeine Fakten“ und im Microsoft Azure-Dokumentationsthema Was bedeutet die IP-Adresse 168.63.129.16 beschrieben.
Eingehend 3000 DenyAllInBound Beliebig Beliebig Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den eingehenden Datenverkehrs dieser Netzwerkkarte auf die Elemente in den vorherigen Zeilen zu beschränken.

Vom Bereitsteller interner Unified Access Gateway-VMs erstellte NSGs

Alle VMs für die interne Unified Access Gateway-Konfiguration verfügen über zwei (2) Netzwerkkarten. Dabei ist eine mit dem Management-Subnetz und eine mit dem Mandanten-Subnetz verbunden. Der Bereitsteller erstellt für jede dieser beiden Netzwerkkarten eine spezifische NSG und ordnet jede NSG der passenden Netzwerkkarte zu.

  • Die Management-Netzwerkkarte (NIC) verfügt über eine NSG, die nach dem Muster vmw-hcs-podUUID-uag-management-nsg benannt ist.
  • Die Mandanten-Netzwerkkarte (NIC) verfügt über eine NSG, die nach dem Muster vmw-hcs-podUUID-uag-tenant-nsg benannt ist.

In Ihrer Microsoft Azure-Umgebung befinden sich diese NSGs in der Ressourcengruppe des Pods, die nach dem Muster vmw-hcs-podUUID-uag-internal benannt ist.

Tabelle 7. Vom Bereitsteller erstellte NSG-Regeln auf der Management-Netzwerkkarte (NIC) interner Unified Access Gateway-VMs
Richtung Priorität Name Ports Protokoll Quelle Ziel Aktion Zweck
Eingehend 1000 AllowHttpsInBound 9443 TCP Management-Subnetz Beliebig Zulassen Damit der Dienst die Administrationseinstellungen des Gateways mithilfe der zugehörigen Verwaltungsschnittstelle konfigurieren kann. Gemäß Beschreibung in der Unified Access Gateway-Produktdokumentation befindet sich die Verwaltungsschnittstelle an Port 9443/TCP.
Eingehend 1100 AllowAzureInBound Beliebig Beliebig 168.63.129.16 Beliebig Zulassen Damit die VM die eingehende Kommunikation von der Microsoft Azure-Plattform akzeptieren kann, wie im vorangegangenen Abschnitt „Allgemeine Fakten“ und im Microsoft Azure-Dokumentationsthema Was bedeutet die IP-Adresse 168.63.129.16 beschrieben.
Eingehend 1200 AllowSshInBound 22 Beliebig Management-Subnetz Beliebig Beliebig Damit VMware im Rahmen der Fehlerbehebung bei Bedarf einen Notfallzugriff auf die VM durchführen kann. Die Berechtigung wird von Ihnen vor dem Notfallzugriff angefordert.
Eingehend 3000 DenyAllInBound Beliebig Beliebig Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den eingehenden Datenverkehrs dieser Netzwerkkarte auf die Elemente in den vorherigen Zeilen zu beschränken.
Ausgehend 3000 DenyAllOutBound Beliebig Beliebig Beliebig Beliebig Verweigern Wurde vom Bereitsteller hinzugefügt, um ausgehenden Datenverkehr von dieser Netzwerkkarte zu verweigern.
Tabelle 8. Vom Bereitsteller erstellte NSG-Regeln auf der Mandanten-Netzwerkkarte (NIC) interner Unified Access Gateway-VMs
Richtung Priorität Name Ports Protokoll Quelle Ziel Aktion Zweck
Eingehend 1000 AllowAzureInBound Beliebig Beliebig 168.63.129.16 Beliebig Zulassen Damit die VM die eingehende Kommunikation von der Microsoft Azure-Plattform akzeptieren kann, wie im vorangegangenen Abschnitt „Allgemeine Fakten“ und im Microsoft Azure-Dokumentationsthema Was bedeutet die IP-Adresse 168.63.129.16 beschrieben.
Eingehend 1100 AllowHttpsInBound

80

443

TCP VirtualNetwork Beliebig Zulassen Diese Regel stellt den eingehenden Datenverkehr interner Endbenutzer aus den Horizon Clients und dem Horizon-Webclient bereit, um die Anmeldeauthentifizierungsanforderung an den Pod-Manager zu stellen. Standardmäßig verwenden der Horizon Client und der Horizon-Webclient Port 443 für diese Anforderung. Um die einfache Umleitung für einen Benutzer zu erleichtern, der möglicherweise in seinem Client HTTP anstelle von HTTPS eingibt, kommt der Datenverkehr an Port 80 an und wird automatisch an Port 443 umgeleitet.
Eingehend 1200 AllowBlastInBound

443

8443

Beliebig VirtualNetwork Beliebig Zulassen Diese Regel unterstützt die Unified Access Gateway-Instanzen, die den Blast-Datenverkehr von den Horizon Clients der internen Endbenutzer erhalten.
Eingehend 1300 AllowPcoipInBound 4172 Beliebig VirtualNetwork Beliebig Zulassen Diese Regel unterstützt die Unified Access Gateway-Instanzen, die den PCoIP-Datenverkehr von den Horizon Clients der internen Endbenutzer erhalten.
Eingehend 1400 AllowPcoipUdpInBound Beliebig UDP Mandanten-Subnetz Beliebig Zulassen Diese Regel unterstützt die Standardkonfiguration, die für das Unified Access Gateway verwendet wird, das mit dem Horizon Agent arbeitet. Die Horizon Agents in den Desktop- und Farm-VMs senden PCoIP-Daten per UDP an die Unified Access Gateway-Instanzen zurück.
Eingehend 3000 DenyAllInBound Beliebig Beliebig Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den eingehenden Datenverkehrs dieser Netzwerkkarte auf die Elemente in den vorherigen Zeilen zu beschränken.
Ausgehend 1000 AllowHttpsOutBound

443

8443

TCP Beliebig Mandanten-Subnetz Zulassen

Diese Regel unterstützt die Unified Access Gateway-Instanzen, die wegen neuer Client-Verbindungsanforderungen an den Pod mit den Pod-Manager-VMs kommunizieren.

Ausgehend 1100 AllowBlastOutBound 22443 Beliebig Beliebig Mandanten-Subnetz Zulassen Diese Regel unterstützt den Anwendungsfall einer Horizon Client Blast Extreme-Sitzung mit dem Horizon Agent in einer Desktop- oder Farm-VM.
Ausgehend 1200 AllowPcoipOutBound 4172 Beliebig Beliebig Mandanten-Subnetz Zulassen Diese Regel unterstützt den Anwendungsfall einer Horizon Client PCoIP-Sitzung mit dem Horizon Agent in einer Desktop-VM.
Ausgehend 1300 AllowUsbOutBound 32111 TCP Beliebig Mandanten-Subnetz Zulassen Diese Regel unterstützt den Anwendungsfall des USB-Umleitungsdatenverkehrs. Die USB-Umleitung ist eine Agentenoption in den Desktop- oder Farm-VMs. Dieser Datenverkehr verwendet Port 32111 für eine Endbenutzer-Clientsitzung mit dem Horizon Agent in einer Desktop- oder Farm-VM.
Ausgehend 1400 AllowMmrOutBound 9427 TCP Beliebig Mandanten-Subnetz Zulassen Diese Regel unterstützt die Anwendungsfälle des Multimedia Redirection (MMR)- und Client Driver Redirection (CDR)-Datenverkehrs. Diese Umleitungen sind Agentenoptionen in den Desktop- oder Farm-VMs. Dieser Datenverkehr verwendet Port 9427 für eine Endbenutzer-Clientsitzung mit dem Horizon Agent in einer Desktop- oder Farm-VM.
Ausgehend 1500 AllowAllOutBound Beliebig Beliebig Beliebig Mandanten-Subnetz Zulassen Bei Ausführung in einer VM, die mehrere Benutzersitzungen unterstützt, wählt der Horizon Agent verschiedene Ports aus, die für den PCoIP-Datenverkehr der Sitzung verwendet werden. Da diese Ports nicht im Voraus ermittelt werden können, kann vorab keine NSG-Regel definiert werden, die bestimmte Ports benennt, um diesen Datenverkehr zuzulassen. Aus diesem Grund unterstützt diese Regel, ähnlich wie bei der Priorität 1200, den Anwendungsfall mehrerer Horizon Client PCoIP-Sitzungen mit solchen VMs..
Ausgehend 3000 DenyAllOutBound Beliebig Beliebig Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den ausgehenden Datenverkehr dieser Netzwerkkarte auf die Elemente in den vorherigen Zeilen zu beschränken.

Die vom Bereitsteller der Gateway-Connector-VM erstellte NSG, wenn ein externes Gateway in einem eigenen VNet bereitgestellt wird

Die Gateway-Connector-VM verfügt über eine einzelne Netzwerkkarte. Diese Netzwerkkarte ist mit dem Verwaltungssubnetz des VNet des externen Gateways verknüpft. Der Bereitsteller erstellt eine einzelne NSG und ordnet diese NSG spezifisch dieser Netzwerkkarte zu. Standardmäßig weist die vom Bereitsteller erstellte NSG für die Management-Netzwerkkarte des Gateway Connectors die gleichen Regeln wie die vom Bereitsteller erstellte NSG für die Pod Manager-VM auf.

Tabelle 9. Vom Bereitsteller erstellte NSG-Regeln auf der Management-Netzwerkkarte für die Connector-VM des externen Gateways
Richtung Priorität Name Ports Protokoll Quelle Ziel Aktion Zweck
Eingehend 1000 AllowSshInBound 22 Beliebig Management-Subnetz Beliebig Zulassen Wie im Thema DNS-Anforderungen für einen Horizon Cloud-Pod in Microsoft und zugehörige Dienstfunktionen beschrieben, kommuniziert die kurzlebige Jump-Box-VM bei ihrer ersten Erstellung und während darauf folgenden Softwareaktualisierungen auf dem Pod über SSH an Port 22 der VM mit dieser Gateway Connector-VM. Gemäß Beschreibung in diesem Thema ist für den täglichen Pod-Betrieb auch keine Verfügbarkeit von Port 22 auf der Gateway Connector-VM erforderlich. Wenn Sie jedoch bei Vorgängen mit stabilem Zustand eine Support-Anfrage an VMware stellen und das Supportteam bestimmt, dass zur Fehlerbehebung dieser Anforderung eine Jump-Box-VM für die SSH-Kommunikation mit der Gateway Connector-VM bereitgestellt wird, unterstützt diese NSG-Regel diesen Anwendungsfall. Die Berechtigung wird von Ihnen vor dem Notfallzugriff angefordert.
Eingehend 1100 AllowAzureInBound Beliebig Beliebig 168.63.129.16 Beliebig Zulassen Damit die VM die eingehende Kommunikation von der Microsoft Azure-Plattform akzeptieren kann, wie im vorangegangenen Abschnitt „Allgemeine Fakten“ und im Microsoft Azure-Dokumentationsthema Was bedeutet die IP-Adresse 168.63.129.16 beschrieben.
Eingehend 1200 AllowHttpsInBound 443 Beliebig Management-Subnetz Beliebig Zulassen Damit die Cloud-Steuerungsebene sicher mit dem REST API Endpoint des Gateway Connectors kommunizieren kann.
Eingehend 1300 AllowApacheGeodeInBound 10334 - 10336, 41000-41002, 41100-41102, 42000-42002 Beliebig Management-Subnetz Beliebig Zulassen Diese Portgruppen werden verwendet, um Benutzersitzungen auf die Pod-Manager-VMs und Dateifreigabeinformationen zwischen den Pod-Manager-VMs und der Gateway Connector-VM zu replizieren.
Eingehend 1400 AllowTelegrafInBound 9172 Beliebig Management-Subnetz Beliebig Zulassen Diese Regel ist für die Verwendung in einer künftigen Version der Horizon-Infrastrukturüberwachung-Funktion geplant.
Eingehend 1500 AllowAgentJmsInBound 4001, 4002 Beliebig Management-Subnetz Beliebig Zulassen Diese Regel ist für die Verwendung in einer künftigen Version der Horizon-Infrastrukturüberwachung-Funktion geplant.
Eingehend 3000 DenyAllInBound Beliebig Beliebig Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den eingehenden Datenverkehrs dieser Netzwerkkarte auf die Elemente in den vorherigen Zeilen zu beschränken.

Vom Bereitsteller erstellte NSG der temporären Jump Box-VM

Während der Ausführung von Workflows bezüglich der Pod-Bereitstellung, z. B. Bereitstellen eines Pods oder Hinzufügen einer Gateway-Konfiguration zu einem Pod, verfügt die temporäre Jump Box über eine NSG in der temporären Jump Box-Ressourcengruppe. Diese NSG wird gelöscht, wenn die Ressourcengruppe der Jump Box nach Abschluss des Workflows gelöscht wird.

Tabelle 10. Vom Bereitsteller erstellte NSG-Regeln auf der Management-Netzwerkkarte der Jump Box-VM
Richtung Priorität Name Ports Protokoll Quelle Ziel Aktion Zweck
Eingehend 100 AllowSSHInBound 22 Beliebig Management-Subnetz Management-Subnetz Zulassen Wie im Thema DNS-Anforderungen für einen Horizon Cloud-Pod in Microsoft und zugehörige Dienstfunktionen beschrieben, benötigen laufende Pod-Vorgänge keinen eingehenden Datenverkehr zu Port 22 der kurzlebigen Jump-Box-VM. Wenn Sie jedoch bei Vorgängen mit stabilem Zustand eine Support-Anfrage an VMware stellen und das Supportteam bestimmt, dass zur Fehlerbehebung dieser Anforderung eine Jump-Box-VM für die SSH-Kommunikation mit der Pod Manager-VM bereitgestellt wird, unterstützt diese NSG-Regel diesen Anwendungsfall. Die Berechtigung wird von Ihnen vor dem Notfallzugriff angefordert.
Hinweis: In Fällen, in denen die Cloud-Steuerungsebene den Zugriff auf den Pod verloren hat, kann das Supportteam eine Notfall-Jumpbox mit einer öffentlichen IP einsetzen, um den Zugriff auf den Pod herzustellen. In diesem Szenario muss diese Regel Source=Any und Destination=Any lauten.
Ausgehend 100 AllowSSHOutbound 22 TCP Management-Subnetz Management-Subnetz Zulassen Damit die Jump-Box-VM die für sie vorgesehenen Funktionen zum Konfigurieren der anderen vom Dienst bereitgestellten VMs ausführen kann (gemäß Anforderung durch den Dienst).
Ausgehend 101 AllowHttpsOutbound 443 TCP Management-Subnetz Beliebig Zulassen Damit die Jump-Box-VM bestimmte extern gespeicherte Softwarekomponenten herunterlädt, z. B. die Microsoft Azure-CLI (Befehlszeilenschnittstelle). Die Jump-Box verwendet diese Software, um die vorgesehenen Funktionen für die Konfiguration der anderen vom Dienst bereitgestellten VMs auszuführen.
Ausgehend 102 AllowHttpOutbound 80 TCP Management-Subnetz Beliebig Zulassen Damit die Jump-Box-VM bestimmte extern gespeicherte Softwarekomponenten herunterlädt, z. B. die Ubuntu-Softwareupdates für die Linux-basierten VMs des Pods. Die Jump-Box verwendet diese Software, um die vorgesehenen Funktionen für die Konfiguration der anderen vom Dienst bereitgestellten VMs auszuführen.
Ausgehend 103 AllowUagOutbound 9443 TCP Management-Subnetz Management-Subnetz Zulassen Damit der Dienst die Administrationseinstellungen des Gateways mithilfe der zugehörigen Verwaltungsschnittstelle konfigurieren kann. Gemäß Beschreibung in der Unified Access Gateway-Produktdokumentation befindet sich die Verwaltungsschnittstelle an Port 9443/TCP.
Ausgehend 104 AllowDnsOutbound 53 Beliebig Management-Subnetz Beliebig Zulassen Damit die Jump-Box die DNS-Dienste erreichen kann.
Ausgehend 1000 DenyAllOutBound Beliebig TCP Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den ausgehenden Datenverkehr mit dieser Netzwerkkarte mit TCP auf die Elemente in den vorherigen Zeilen zu beschränken.

Vom Virtuelle Horizon Edge-Appliance-Bereitsteller erstellte NSGs

Die Virtuelle Horizon Edge-Appliance wird bereitgestellt, wenn Sie die Horizon Universal Console verwenden, um Horizon-Infrastrukturüberwachung auf dem Pod zu aktivieren. Die Virtuelle Horizon Edge-Appliance verfügt über eine Netzwerkkarte, die mit demselben Verwaltungssubnetz verbunden ist, das mit den Pod-Manager-VMs verbunden ist. Der Bereitsteller erstellt eine bestimmte NSG mit einem Namen nach dem Muster vmw-hcs-podUUID-edge-nsg und ordnet diese NSG der Netzwerkkarte zu.

In Ihrer Microsoft Azure-Umgebung befinden sich diese NSGs in der Ressourcengruppe des Pods, die nach dem Muster vmw-hcs-podUUID-edge benannt ist.

Tabelle 11. Vom Bereitsteller erstellte NSG-Regeln auf der Virtuelle Horizon Edge-Appliance-Management-Netzwerkkarte
Richtung Priorität Name Ports Protokoll Quelle Ziel Aktion Zweck der Regel
Eingehend 100 AllowSSHInbound 22 Beliebig Management-Subnetz Beliebig Zulassen Für den täglichen Betrieb der Appliance muss Port 22 nicht verfügbar sein. Wenn Sie jedoch bei Vorgängen mit stabilem Zustand eine Support-Anfrage an VMware stellen und das Supportteam bestimmt, dass zur Fehlerbehebung dieser Anforderung eine Jump-Box-VM für die SSH-Kommunikation mit der Appliance bereitgestellt wird, unterstützt diese NSG-Regel diesen Anwendungsfall. Die Berechtigung wird von Ihnen vor dem Notfallzugriff angefordert.
Ausgehend 101 AllowHttpsOutbound 443 TCP Management-Subnetz Beliebig Zulassen Damit die Appliance bestimmte extern gespeicherte Softwarekomponenten herunterlädt, z. B. die Microsoft Azure-CLI (Befehlszeilenschnittstelle). Die Appliance verwendet diese Software, um ihre vorgesehenen Funktionen zum Konfigurieren der anderen vom Dienst bereitgestellten VMs für die Erfassung der vorgesehenen Überwachungsdaten auszuführen.
Ausgehend 102 AllowHttpOutbound 80 TCP Management-Subnetz Beliebig Zulassen Damit die Appliance bestimmte extern gespeicherte Softwarekomponenten herunterlädt, z. B. die Ubuntu-Softwareupdates für das Linux-basierte Betriebssystem.
Ausgehend 103 AllowUagOutbound 9443 TCP Management-Subnetz Management-Subnetz Zulassen Diese Regel ist für die Verwendung in einer künftigen Version der Horizon-Infrastrukturüberwachung-Funktion geplant.
Ausgehend 104 AllowDnsOutbound 53 Beliebig Management-Subnetz Beliebig Zulassen Um DNS-Dienste zu erreichen.
Ausgehend 106 AllowTelegrafOutBound 9172 Beliebig Management-Subnetz Management-Subnetz Zulassen Um die Überwachungsdaten von den Pod-Manager-VMs zu erfassen, für deren Erfassung die Appliance vorgesehen ist.
Ausgehend 107 AllowJmsBrokerOutbound 4002 Beliebig Management-Subnetz Management-Subnetz Zulassen Diese Regel ist für die Verwendung in einer künftigen Version der Horizon-Infrastrukturüberwachung-Funktion geplant.
Ausgehend 1000 DenyAllOutBound Beliebig Tcp Beliebig Beliebig Verweigern Wird durch den Bereitsteller hinzugefügt, um den ausgehenden Datenverkehr mit dieser Netzwerkkarte mit TCP auf die Elemente in den vorherigen Zeilen zu beschränken.