First-Gen-Mandanten – Standardmäßige Netzwerk-Sicherheitsgruppenregeln für die VMs in einem in Microsoft Azure bereitgestellten Horizon Cloud-Pod

In diesem Dokumentationsthema wird erläutert, was angezeigt wird, wenn Sie sich nach der Verwendung einer First-Gen-Horizon Cloud-Bereitstellung zum Erstellen eines Pods in 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.

Vor dem Lesen dieser Seite

Berücksichtigen Sie Folgendes, bevor Sie diese Seite lesen.

Nicht vergessen: Wie im KB-Artikel 92424 beschrieben, wurde das Ende der Verfügbarkeit der Horizon Cloud First-Gen-Steuerungsebene angekündigt. Die Produktdokumentation zu First-Gen- Horizon Cloud wurde entsprechend dieser Ankündigung aktualisiert.

Hinweis: Wie in KB-Artikel 93762 beschrieben, können First-Gen-Mandanten die Funktion Horizon-Infrastrukturüberwachung nicht mehr aktivieren oder verwenden, da sie veraltet ist. Ab Oktober 2023 wurden die Informationen auf dieser Seite, die sich zuvor auf diese veraltete Funktion bezogen, entsprechend aktualisiert.

Achtung: Diese Informationen gelten nur, wenn Sie auf eine First-Gen-Mandantenumgebung in der First-Gen-Steuerungsebene zugreifen können. Wie im KB-Artikel 92424 beschrieben, hat die First-Gen-Steuerungsebene das Ende der Verfügbarkeit (End of Availability, EOA) erreicht. Weitere Informationen finden Sie in diesem Artikel.

Ab August 2022 steht Horizon Cloud Service – next-gen allgemein mit einem eigenen Handbuch namens Verwenden der Next-Gen-Horizon-Steuerungsebene zur Verfügung.

Ein Hinweis darauf, ob es sich um eine Next-Gen- oder First-Gen-Umgebung handelt, ist das Muster, das im URL-Feld des Browsers angezeigt wird, nachdem Sie sich bei Ihrer Umgebung angemeldet haben und die Bezeichnung Horizon Universal Console sehen. Bei einer Next-Gen-Umgebung enthält die URL-Adresse der Konsole eine Komponente wie /hcsadmin/. Die URL der First-Gen-Konsole enthält einen anderen Abschnitt (/horizonadmin/).

Allgemeine Einführung

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 von denen getrennt, die für die Basis-VMs, Farmen und VDI-Desktops verwendet werden, die vom Pod bereitgestellt werden, wenn Sie sie mithilfe der Horizon Universal Console erstellen. Für diese NSGs gelten unterschiedliche Nutzungsinformationen. Informationen zu diesen NSGs finden Sie in den folgenden Themen:

• Die Netzwerksicherheitsgruppen (NSGs), die mit dem Horizon Cloud-Assistenten „Virtuelle Maschine aus Marketplace importieren“ erstellt wurden
• Informationen zu Netzwerksicherheitsgruppen und Farmen in einem Horizon Cloud-Pod
• 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 First-Gen-Mandanten – 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.
• Die Horizon Cloud-Regeln beginnen 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.
• 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.
• 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.
• Wenn Sie eine Support-Anfrage an VMware stellen und das Supportteam feststellt, dass die Bereitstellung einer temporären Jumpbox-VM der beste Weg ist, diese Anfrage zu bearbeiten, verfügt diese temporäre Jumpbox über eine NSG in ihrer temporären Jumpbox-Ressourcengruppe. Diese NSG wird gelöscht, wenn die Jumpbox-Ressourcengruppe gelöscht wird, sobald das Supportteam fertig ist.

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.

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	Wenn Sie bei Vorgängen mit stabilem Zustand eine Support-Anfrage an VMware stellen und das Supportteam bestimmt, dass zur Fehlerbehebung dieser Anforderung eine Jumpbox-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. Die kurzlebige Jumpbox-VM kommuniziert mit einer Pod-Manager-VM über SSH mit dem Port 22 der VM. Für den täglichen Pod-Betrieb ist die Verfügbarkeit von Port 22 auf der Pod-Manager-VM nicht erforderlich.
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	Veraltet. Diese NSG wurde von der Funktion Horizon-Infrastrukturüberwachung verwendet, die gemäß der Beschreibung im VMware KB-Artikel 93762 veraltet ist.
Eingehend	1500	AllowAgentJmsInBound	4001, 4002	Beliebig	Management-Subnetz	Beliebig	Zulassen	Veraltet. Diese NSG wurde von der Funktion Horizon-Infrastrukturüberwachung verwendet, die gemäß der Beschreibung im VMware KB-Artikel 93762 veraltet 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 (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	Aus Gründen der Codekonsistenz und Wartungsfreundlichkeit schreibt der Pod-Bereitsteller diese Regel immer in diese NSG. Bei einer Bereitstellung, bei der das externe Gateway des Pods in einem eigenen, vom Pod getrennten VNet bereitgestellt wird, unterstützt diese Regel den eingehenden Datenverkehr von den Unified Access Gateway-Instanzen des externen Gateways zur Ü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 3. 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 4. 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-Umleitung (MMR)- und Clientlaufwerksumleitung (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 5. 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 6. 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 7. 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-Umleitung (MMR)- und Clientlaufwerksumleitung (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 8. 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	Wenn Sie bei Vorgängen mit stabilem Zustand eine Support-Anfrage an VMware stellen und das Supportteam bestimmt, dass zur Fehlerbehebung dieser Anforderung eine Jumpbox-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. Die kurzlebige Jumpbox-VM kommuniziert mit dieser Gateway-Connector-VM über SSH mit dem Port 22 der VM. Für den täglichen Pod-Betrieb ist die Verfügbarkeit von Port 22 auf der Gateway-Connector-VM nicht erforderlich.
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	Veraltet. Diese NSG wurde von der Funktion Horizon-Infrastrukturüberwachung verwendet, die gemäß der Beschreibung im VMware KB-Artikel 93762 veraltet ist.
Eingehend	1500	AllowAgentJmsInBound	4001, 4002	Beliebig	Management-Subnetz	Beliebig	Zulassen	Veraltet. Diese NSG wurde von der Funktion Horizon-Infrastrukturüberwachung verwendet, die gemäß der Beschreibung im VMware KB-Artikel 93762 veraltet 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.

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

Wenn Sie eine Support-Anfrage an VMware stellen und das Supportteam feststellt, dass die Bereitstellung einer temporären Jumpbox-VM der beste Weg ist, diese Anfrage zu bearbeiten, verfügt diese temporäre Jumpbox über eine NSG in ihrer temporären Jumpbox-Ressourcengruppe. Diese NSG wird gelöscht, wenn die Jumpbox-Ressourcengruppe gelöscht wird, sobald das Supportteam diese Arbeit abgeschlossen hat. Die Berechtigung wird von Ihnen vor dem Notfallzugriff angefordert.

Tabelle 9. Vom Dienst erstellte NSG-Regeln auf der Management-Netzwerkkarte der temporären Jumpbox-VM

Richtung	Priorität	Name	Ports	Protokoll	Quelle	Ziel	Aktion	Zweck
Eingehend	100	AllowSSHInBound	22	Beliebig	Management-Subnetz	Management-Subnetz	Zulassen	Für die SSH-Kommunikation mit den von VMware verwalteten Appliances, die an der Untersuchung Ihrer Serviceanfrage durch das VMware-Supportteam beteiligt sind. Die kurzlebige Jumpbox-VM kommuniziert über SSH und Port 22. 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 Jumpbox-VM ihre vorgesehenen Funktionen ausführen kann.
Ausgehend	101	AllowHttpsOutbound	443	TCP	Management-Subnetz	Beliebig	Zulassen	Damit die Jumpbox-VM bestimmte extern gespeicherte Softwarekomponenten herunterlädt, z. B. die Microsoft Azure-CLI (Befehlszeilenschnittstelle), um ihre vorgesehenen Funktionen auszuführen.
Ausgehend	102	AllowHttpOutbound	80	TCP	Management-Subnetz	Beliebig	Zulassen	Damit die Jumpbox-VM bestimmte extern gespeicherte Softwarekomponenten herunterlädt, z. B. Ubuntu-Software-Updates, um die vorgesehenen Funktionen ausführen zu können.
Ausgehend	103	AllowUagOutbound	9443	TCP	Management-Subnetz	Management-Subnetz	Zulassen	Damit die Jumpbox-VM ihre vorgesehenen Funktionen im Zusammenhang mit den Gateway-Verwaltungseinstellungen über die Verwaltungsschnittstelle des Gateways ausführt.
Ausgehend	104	AllowDnsOutbound	53	Beliebig	Management-Subnetz	Beliebig	Zulassen	Damit die Jump-Box die DNS-Dienste erreichen kann.
Ausgehend	105	AllowHttpProxyOutbound	Beliebig	TCP	Beliebig	Beliebig	Zulassen	Wenn die Pod-Bereitstellung für die Verwendung eines Proxys mit einem anderen Proxy-Port als 80 konfiguriert ist, erstellt der temporäre Jumpbox-Bereitsteller diese Regel in dieser NSG. Diese Regel unterstützt die temporäre Jumpbox in einer solchen Proxy-Umgebung. Diese Regel wird in dieser NSG nicht angezeigt, wenn für die Konfiguration der Pod-Bereitstellung kein Proxy angegeben ist oder ein Proxy mit Proxy-Port 80 angegeben wurde.
Ausgehend	1000	DenyAllOutBound	Beliebig	TCP	Beliebig	Beliebig	Verweigern	Beschränkt den ausgehenden Datenverkehr dieser Netzwerkkarte mit TCP auf die Elemente in den vorherigen Zeilen.