Für eine erfolgreiche End-to-End-Nutzung der Dienstfunktionen müssen Sie sicherstellen, dass die auf dieser Dokumentationsseite beschriebenen Hostnamen auflösbar und vom Verwaltungs- und Mandantensubnetz unter Verwendung der auf dieser Seite angegebenen spezifischen Ports und Protokolle erreichbar sind.
Kurzinformationen zu Hostnamen, DNS-Hostnamen und zur Beziehung zur Horizon Cloud on Microsoft Azure-Bereitstellung
Der Grund, warum auf dieser Seite neben dem Begriff Hostname auch der Begriff DNS-Name vorkommt, liegt darin, dass DNS ein Netzwerkstandard für die Auflösung von Hostnamen ist, um die Kommunikation zwischen diesen Hostnamen zu ermöglichen.
Ein Hostname ist ein eindeutiger Name, der einer Maschineninstanz in einem bestimmten Netzwerk zugewiesen ist. Wie bereits in der Branche der Softwarenetzwerke beschrieben, verwenden Systeme DNS (Domain Name System), um Hostnamen zu Kommunikationszwecken in ihre IP-Adressen aufzulösen.
Der Pod-Bereitstellungsvorgang erfordert, dass die bereitgestellten Instanzen über eine Netzwerkkommunikation über das ausgewählte VNet der Bereitstellung mit den auf dieser Seite beschriebenen Hostnamen (DNS-Namen) verfügen.
Nach der erfolgreichen Bereitstellung des Pods in Ihrem Abonnement erfordern verschiedene alltägliche Dienstvorgänge Netzwerkzugriff auf bestimmte DNS-Namen, ebenso wie der Pod-Aktualisierungsvorgang zur Aktualisierung der Pod-Software, wenn neue Software zur Verfügung gestellt wird.
Auf dieser Seite werden die Anforderungen beschrieben. Manchmal werden auf dieser Seite die Begriffe DNS-Name und Hostname synonym verwendet.
Einige allgemeine Hauptpunkte
- Info zu diesen benötigten DNS-Namen
-
Die Bereitstellung und Ausführung eines
Horizon Cloud-Pods erfordert Netzwerkzugriff auf bestimmte DNS-Adressen über Ihre Microsoft Azure-VNets. Damit der Pod-Bereitsteller funktioniert, müssen Sie Ihre Firewalls so konfigurieren, dass der Netzwerkzugriff auf diese Adressen möglich ist. Der Zweck jeder DNS-Adresse wird in den folgenden Tabellen angegeben.
Die DNS-Konfiguration in Ihrem VNet muss nicht nur die Netzwerkkommunikation zu diesen DNS-Adressen ermöglichen, sondern auch die Namen wie in diesem Artikel beschrieben auflösen.
Wenn Sie die Option zum Bereitstellen des externen Gateways im eigenen vom VNet des Pod-Managers getrennten VNet auswählen, muss das Subnetz dieses VNets dieselben DNS-Anforderungen erfüllen wie das Management-Subnetz des Pod-Manager-VNets.
Neben dem Pod-Bereitsteller und seinen Workflows benötigen verschiedene Dienstfunktionen Zugriff auf bestimmte DNS-Adressen, damit diese Funktionen durchgängig funktionieren. Diese DNS-Namen werden auch in den folgenden Tabellen bereitgestellt.
Einige dieser DNS-Namen verfügen über ein regionales Element.
Durch die Aktivierung von Horizon-Infrastrukturüberwachung auf einem Pod wird die Virtuelle Horizon Edge-Appliance im VNet des Pod-Managers und im Verwaltungssubnetz automatisch instanziiert. Für Virtuelle Horizon Edge-Appliance gelten eigene DNS-Namensanforderungen. Deshalb müssen Sie vor dem Aktivieren von Horizon-Infrastrukturüberwachung auf einem Pod sicherstellen, dass die DNS-Anforderungen der Virtuelle Horizon Edge-Appliance erfüllt werden, die in den folgenden Tabellen angegeben werden.
Gemäß der Beschreibung in Enge Integration in das VMware-Ökosystem können Sie Horizon Cloud mit anderen Produkten aus dem VMware-Ökosystem verwenden. Für diese anderen Produkte gelten möglicherweise zusätzliche DNS-Anforderungen. Solche zusätzlichen DNS-Anforderungen werden hier nicht ausführlich beschrieben. Informationen zu solchen DNS-Anforderungen finden Sie im Dokumentationssatz für die spezifischen Produkte, die Sie in Ihren Pod integrieren werden.
- Informationen zu Ports und Protokollen nach der Bereitstellung eines Pods für laufende dienstbezogene Vorgänge
- Nachdem ein Pod erfolgreich bereitgestellt wurde, sind spezifische Ports und Protokolle für den laufenden Horizon Cloud-Betrieb erforderlich. Weitere Informationen dazu finden Sie unter Horizon Cloud-Pod – Anforderungen an Ports und Protokolle.
DNS-Namen der regionalen Steuerungsebene
In Ihrer Begrüßungs-E-Mail für den Horizon Service wird angegeben, in welcher regionalen Steuerungsebeneninstanz Ihr Mandantenkonto erstellt wurde. Aufgrund eines bekannten Problems, das aufgetreten ist, als Ihnen die Begrüßungs-E-Mail gesendet wurde, werden in der von Ihnen empfangenen E-Mail möglicherweise die Namen der Systemzeichenfolge für die Regionen anstelle benutzerfreundlicher Namen angezeigt. Wenn Sie einen Systemzeichennamen in Ihrer Begrüßungs-E-Mail sehen, können Sie die folgende Tabelle verwenden, um zu erfahren, was in Ihrer E-Mail mit den DNS-Namen der regionalen Steuerungsebene angezeigt wird.
| Ihre Begrüßungs-E-Mail lautet: | Regionaler DNS-Name |
|---|---|
USA |
cloud.horizon.vmware.com |
EU_CENTRAL_1 oder Europe |
cloud-eu-central-1.horizon.vmware.com |
AP_SOUTHEAST_2 oder Australia |
cloud-ap-southeast-2.horizon.vmware.com |
PROD1_NORTHCENTRALUS2_CP1 oder USA-2 |
cloud-us-2.horizon.vmware.com |
PROD1_NORTHEUROPE_CP1 oder Europe-2 |
cloud-eu-2.horizon.vmware.com |
PROD1_AUSTRALIAEAST_CP1 oder Australia-2 |
cloud-ap-2.horizon.vmware.com |
Japan |
cloud-jp.horizon.vmware.com |
UK |
cloud-uk.horizon.vmware.com |
Europe-3 |
cloud-de.horizon.vmware.com |
Für die regionalen DNS-Adressen, die in den folgenden Tabellen für die Virtuelle Horizon Edge-Appliance aufgelistet werden, verwenden diese Adressen dieselben Regionen wie die DNS-Namen der regionalen Steuerungsebene.
DNS-Anforderungen für den Gesamtprozess der Pod-Bereitstellung, Pod-Updates, die Aktivierung verschiedener Dienste und den laufenden Betrieb
Für eine erfolgreiche End-to-End-Nutzung der Dienstfunktionen müssen Sie sicherstellen, dass die folgenden DNS-Namen auflösbar und über das Verwaltungs- und Mandantensubnetz mithilfe bestimmter Ports und Protokolle, die in den Tabellen dieses Artikels angegeben werden, erreichbar sind. Zu den Dienstfunktionen, die die Fähigkeit zum Erreichen bestimmter DNS-Namen benötigen, gehören:
- Der Pod-Bereitsteller, der einen pod-manager-basierten Horizon-Pod automatisch in Ihrem Microsoft Azure-Abonnement bereitstellt
- Die Pod-Aktualisierungsfunktion zum Aktualisieren der Pod-Software auf eine aktuelle Version
- Der Prozess zum Importieren von Images, der den Assistenten „Aus Marketplace importieren“ verwendet
- Die agent-bezogenen Funktionen, wie z. B. automatische Agent-Aktualisierung (AAU)
- Universal Broker
- Horizon-Infrastrukturüberwachung und die zugehörige Virtuelle Horizon Edge-Appliance
- Funktionen mit Bezug auf den Cloud Management Service (CMS)
- Vor allem bei Pod-Bereitstellungen, Pod-Aktualisierungen und beim Aktivieren von Horizon-Infrastrukturüberwachung auf einem Pod
-
Sie müssen sicherstellen, dass die folgenden DNS-Namen aus den Verwaltungs- und Mandantensubnetzen unter Verwendung der in den folgenden Tabellen angegebenen spezifischen Ports und Protokolle auflösbar und erreichbar sind. Die in diesen Workflows verwendeten Appliances nutzen bestimmte ausgehende Ports, um die von diesen Prozessen benötigte Software sicher in die Azure-Umgebung herunterzuladen. Diese DNS-Namen werden auch verwendet, damit die entsprechenden workflow-bezogenen Appliances mit der Steuerungsebene der Cloud kommunizieren können.
Für neue Pod-Bereitstellungen müssen Sie die Netzwerk-Firewall, NSG-Regeln (Network Security Group) und Proxyserver konfigurieren, damit die bereitstellungsbezogenen Haupt-Appliances Kontakt zu den DNS-Adressen auf den von ihnen benötigten Ports herstellen können. Andernfalls schlägt der Pod-Bereitstellungsprozess fehl.
Durch Aktivierung von Horizon-Infrastrukturüberwachung auf einem Pod wird die Virtuelle Horizon Edge-Appliance im selben VNet- und Verwaltungsnetzwerk wie die Pod-Manager-Appliances des Pods instanziiert. Sie müssen sicherstellen, dass die Virtuelle Horizon Edge-Appliance mittels Konfiguration der Netzwerk-Firewall sowie der NSG-Regeln und Proxy-Server Kontakt zu den DNS-Adressen auf den von ihr benötigten Ports herstellen kann. Ansonsten schlägt die Bereitstellung dieser Appliance fehl.
- Wenn Sie die Funktion verwenden, um das externe Gateway im eigenen VNet bereitzustellen
- Das Verwaltungssubnetz in diesem VNet muss dieselben DNS-Anforderungen erfüllen, die in der folgenden Tabelle für das Verwaltungssubnetz im VNet des Pods angegeben werden. Für das Back-End-Subnetz und das DMZ-Subnetz des VNet des externen Gateways gelten keine spezifischen DNS-Anforderungen.
- Wenn Sie den Pod entweder mit einem externen Gateway, einem internen Gateway oder mit beiden bereitstellen
- Sie müssen ein Zertifikat hochladen, das der Pod-Bereitsteller in diesen Gateway-Konfigurationen konfiguriert. Wenn das Zertifikat oder die Zertifikate, die Sie für diesen Zweck bereitstellen, CRLs (Zertifikatsperrlisten) oder OCSP (Online Certificate Status Protocol)-Einstellungen verwenden, die sich auf bestimmte DNS-Namen beziehen, müssen Sie sicherstellen, dass der ausgehende Internetzugriff aus dem VNet diese DNS-Server auflösen und erreichen kann. Während der Konfiguration Ihres bereitgestellten Zertifikats in der Unified Access Gateway-Gateway-Konfiguration greift die Unified Access Gateway-Software auf diese DNS-Namen zu, um den Sperrstatus des Zertifikats zu überprüfen. Wenn diese DNS-Namen nicht erreichbar sind, schlägt die Bereitstellung des Pods während der Phase Verbindung fehl. Diese Namen sind in hohem Maße von der Zertifizierungsstelle abhängig, die Sie zum Abrufen der Zertifikate verwendet haben. Sie unterliegen daher nicht der Kontrolle von VMware.
DNS-Anforderungen für die Bereitstellung neuer Pods, Pod-Updates und Dienstvorgänge, die mandantenübergreifend angewendet werden
In der folgenden Tabelle werden die DNS-Anforderungen für die Bereitstellung neuer Pods, Pod-Updates und Dienstvorgänge beschrieben, die mandantenübergreifend gelten. Informationen zur Aktivierung von Horizon-Infrastrukturüberwachung und den DNS-Anforderungen der Virtuelle Horizon Edge-Appliance finden Sie im folgenden Abschnitt. Da die Funktion Horizon-Infrastrukturüberwachung pro Pod aktiviert wird, müssen die DNS-Anforderungen in einer eigenen Tabelle beschrieben werden.
d1mes20qfad06k.cloudfront.net aufgrund eines Upgrades auf die regionalen Steuerungsebeneninstanzen des Diensts für keine der regionalen Steuerungsebeneninstanzen mehr erforderlich. Alle Instanzen der regionalen Steuerungsebene verwenden jetzt den DNS-Namen
hydra-softwarelib-cdn.azureedge.net. Der Inhalt der folgenden Tabelle ist auf diese aktuelle Situation abgestimmt.
| Subnetz-Quelle | Ziel (DNS-Name) | Port | Protokoll | Zweck |
|---|---|---|---|---|
| Management | Einer der folgenden Namen – je nachdem, welche regionale Steuerungsebeneninstanz in Ihrem Horizon Cloud-Mandantenkonto festgelegt ist. Die regionale Instanz wird beim Erstellen des Kontos festgelegt, wie unter Bereitstellung und Onboarding in Horizon Cloud für Microsoft Azure- und Horizon-Pods beschrieben.
|
443 | TCP | Regionale Steuerungsebeneninstanz
|
| Management | softwareupdate.vmware.com | 443 | TCP | VMware-Softwarepaketserver. Dient zum Herunterladen von Updates der Agent-bezogenen Software, die bei den Image-bezogenen Vorgängen des Systems verwendet wird. |
| Management | hydra-softwarelib-cdn.azureedge.net | 443 | TCP | Horizon Cloud-Inhaltsbereitstellungsserver. Im Management-Subnetz wird diese Site vom -Dienst zum Herunterladen erforderlicher Binärdateien verwendet, die von der Pod-Infrastruktur verwendet werden. |
| Management | packages.microsoft.com | 443 und 11371 | TCP | Microsoft Softwarepaketserver. Zum sicheren Herunterladen der Microsoft Azure Command Line Interface-(CLI)-Software. |
| Management | azure.archive.ubuntu.com | 80 | TCP | Ubuntu-Softwarepaketserver. Wird von den Pod-bezogenen Linux-basierten VMs für Aktualisierungen des Ubuntu-Betriebssystems verwendet. |
| Management | api.snapcraft.io | 443 | TCP | Ubuntu-Softwarepaketserver. Wird von den Linux-basierten VMs des Pods für Ubuntu-Betriebssystem-Updates verwendet. |
| Management | archive.ubuntu.com | 80 | TCP | Ubuntu-Softwarepaketserver. Wird von den Linux-basierten VMs des Pods für Ubuntu-Betriebssystem-Updates verwendet. |
| Management | changelogs.ubuntu.com | 80 | TCP | Ubuntu-Softwarepaketserver. Wird von den Linux-basierten VMs des Pods zur Verfolgung von Ubuntu-Betriebssystem-Updates verwendet. |
| Management | security.ubuntu.com | 80 | TCP | Ubuntu-Softwarepaketserver. Wird von den Linux-basierten VMs des Pods für sicherheitsrelevante Ubuntu-Betriebssystem-Updates verwendet. |
| Management | esm.ubuntu.com | 80 und 443 | TCP | Ubuntu-Softwarepaketserver. Wird von den Linux-basierten VMs des Pods für die Verfolgung von Sicherheits-Updates für hohe und kritische CVEs (Common Vulnerabilities and Exposures) im Ubuntu-Basisbetriebssystem und in der Infrastruktur für die horizontale Skalierung verwendet. |
| Management | Eine der folgenden Optionen, je nachdem, in welcher Microsoft Azure-Cloud Sie Ihren Pod bereitstellen:
|
443 | TCP | Diese Webadresse wird in der Regel von Anwendungen zur Authentifizierung bei Microsoft Azure-Diensten verwendet. Einige Beschreibungen in der Dokumentation zu Microsoft Azure finden Sie unter OAuth 2.0-Autorisierungscode-Fluss, Azure Active Directory v2.0 und das OpenID Connect-Protokoll und Nationale Clouds. Unter dem Thema Nationale Clouds werden die verschiedenen Azure AD-Authentifizierungs-Endpoints für die einzelnen nationalen Microsoft Azure-Clouds beschrieben. |
| Management | Eine der folgenden Optionen, je nachdem, in welcher Microsoft Azure-Cloud Sie Ihren Pod bereitstellen:
|
443 | TCP | Wird für Anforderungen der Pod-API an die Microsoft Azure-Ressourcenmanager-Endpoints zur Verwendung von Microsoft Azure-Ressourcenmanager-Diensten verwendet. Microsoft Azure Resource Manager stellt eine konsistente Verwaltungsebene zum Ausführen von Aufgaben über Azure PowerShell, Azure CLI, Azure-Portal, REST-API und Client SDKs bereit. |
| Management | Eine der folgenden Optionen, je nachdem, in welcher Microsoft Azure-Cloud Sie Ihren Pod bereitstellen:
|
443 | TCP | Der Zugriff auf die Azure Active Directory (Azure AD) Graph-API, die für den programmgesteuerten Zugriff des Pods auf Azure Active Directory (Azure AD) über OData REST API-Endpoints verwendet wird. |
| Management | Wenn Ihre Firewall oder Netzwerksicherheitsgruppe (NSG) die Verwendung von Diensttags unterstützt, ist eine der folgenden Optionen zulässig:
Wenn Ihre Firewall oder Netzwerksicherheitsgruppe (NSG) die Verwendung von Diensttags nicht unterstützt, können Sie den Hostnamen der Datenbank verwenden. Dieser Name folgt dem Muster *.postgres.database.azure.com. |
5432 | TCP | Wird für die Pod-Kommunikation mit dem Microsoft Azure-PostgreSQL-Datenbankserver verwendet. Ab der Version von September 2019 werden Pods, die nach diesem Veröffentlichungsdatum neu bereitgestellt wurden, und Pod, die auf die Manifestversion dieser Version aktualisiert wurden, mit einem Microsoft Azure-PostgreSQL-Datenbankserver konfiguriert. Informationen zu Diensttags in Sicherheitsgruppen finden Sie im Microsoft Azure-Dokumentationsthema zu Diensttags. |
| Management | Einer der folgenden Namen – je nachdem, welche regionale Steuerungsebeneninstanz in Ihrem Horizon Cloud-Mandantenkonto festgelegt ist. Die regionale Instanz wird beim Erstellen des Kontos festgelegt, wie unter Bereitstellung und Onboarding in Horizon Cloud für Microsoft Azure- und Horizon-Pods beschrieben.
|
443 | TCP | Regionale Instanz des Universal Broker-Dienstes
|
| Management | Abhängig von der regionalen Steuerungsebene, die für Ihr Horizon Cloud-Konto gilt:
|
443 | TCP | Cloud Monitoring Service (CMS) |
| Mandant | hydra-softwarelib-cdn.azureedge.net | 443 | TCP | Horizon Cloud-Inhaltsbereitstellungsserver. Im Mandantensubnetz wird diese Site von verschiedenen imagebezogenen Prozessen des Systems verwendet, einschließlich Prozessen, die am automatischen Workflow „Image aus Marketplace importieren“ und am Workflow „Agenten-Paarbildung“ des Systems beteiligt sind. |
| Mandant | scapi.vmware.com | 443 | TCP | VMware Cloud Services, die für das VMware Service Usage Data-Programm verwendet werden. Vom Mandantensubnetz ausgehend, sendet der Horizon Agent in den Pod-bereitgestellten Desktop-Instanzen und Farmserver-Instanzen Agent-bezogene Konfigurationsinformationen. |
Obligatorische Anforderung an die VMware-Systemüberwachung – monitor.horizon.vmware.com
Die in diesem Abschnitt beschriebene obligatorische Anforderung ermöglicht es dem VMware-Überwachungssystem, Sicherheitsereignisse auf den von VMware verwalteten Instanzen zu erkennen, die in den Verwaltungs-, Mandanten- und DMZ-Subnetzen der Horizon Cloud on Microsoft Azure-Bereitstellung bereitgestellt werden.
Bei einer Horizon Cloud on Microsoft Azure-Bereitstellung steuert und verwaltet VMware diese Ressourcen in der Bereitstellung: Pod-Manager-Instanzen, Unified Access Gateway-Instanzen, Azure-Dateien im Zusammenhang mit App Volumes, Azure PostgreSQL-Dienst, Virtuelle Horizon Edge-Appliance und, wenn für Fehlerbehebungssituationen erforderlich, die supportbezogene Jumpbox-Instanz.
Die Verwaltungszuständigkeit von VMware für die bereitgestellten Instanzen erfordert eine obligatorische VMware-Systemüberwachung dieser Instanzen.
Für diese obligatorische VMware-Systemüberwachung müssen die unten beschriebenen Anforderungen erfüllt sein.
Die Instanzen der Bereitstellung müssen ausgehend den Hostnamen monitor.horizon.vmware.com auf den Ports 1514/TCP und 1515/TCP erreichen.
- Diese Anforderung gilt, wenn in Ihrem Netzwerk die SSL-Überprüfung aktiviert ist.
- Wenn die SSL-Überprüfung im Netzwerk aktiviert ist, müssen Sie angeben, dass der Host monitor.horizon.vmware.com ausgeschlossen wird.
- Diese Anforderung gilt, wenn der Einsatz über eine interne Gateway-Konfiguration verfügt.
-
Sie müssen die ausgehende Kommunikation für die interne Gateway-Konfiguration einrichten, indem Sie alle Schritte und Informationen im
KB-Artikel 90145 ausführen. Folgen Sie dem KB-Artikel wie beschrieben, einschließlich der abschließenden Hinweise am Ende des KB-Artikels.
Wenn Sie dann zusätzlich einen Proxy oder eine Firewall für die ausgehende Kommunikation verwenden, müssen Sie die folgenden Anforderungen erfüllen, die bei der Verwendung des Proxys oder der Firewall für die ausgehende Kommunikation gelten.
- Diese Anforderung gilt, wenn Sie einen Proxy oder eine Firewall für die ausgehende Kommunikation verwenden.
-
Wenn Sie einen Proxy oder eine Firewall für Ihre ausgehende Kommunikation verwenden, müssen Sie die Kommunikation auf dem Proxy oder der Firewall wie folgt zulassen:
- Kommerzielle Umgebungen – Hostnamen monitor.horizon.vmware.com auf 1514/TCP und 1515/TCP zulassen
- Umgebungen der US-Regierung: Eröffnen Sie einen Fall beim VMware Federal Support, um den Hostnamen des Überwachungssystems anzufordern.
In solchen Umgebungen müssen Sie die oben genannte Kommunikation für diese Quellen zulassen:
- Verwaltung – die Pod-Manager-Instanzen
- DMZ – die Unified Access Gateway-Instanzen der externen Gateway-Konfiguration
- Mandant – die Unified Access Gateway-Instanzen der internen Gateway-Konfiguration
Hinweis: Wenn die Bereitstellung über eine interne Gateway-Konfiguration verfügt, müssen Sie die zuvor beschriebene Anforderung erfüllen, die für die interne Gateway-Konfiguration gilt, nämlich die Schritte in KB-Artikel 90145.
Virtuelle Horizon Edge-Appliance-DNS-Anforderungen
Durch Aktivierung von Horizon-Infrastrukturüberwachung auf einem Pod wird die Linux-basierte Virtuelle Horizon Edge-Appliance in Ihrem Microsoft Azure-Abonnement instanziiert. Die Virtuelle Horizon Edge-Appliance wird im Abonnement des Pods mit einer Netzwerkkarte im Verwaltungssubnetz des Pods bereitgestellt – demselben Verwaltungssubnetz wie die Pod-Manager-Appliances dieses Pods. In der folgenden Tabelle sind die aufgelisteten Zwecke im Zusammenhang mit dieser virtuellen Appliance aufgeführt.
uk enthalten. Wie in den Versionshinweisen angegeben, steht diese
Horizon-Infrastrukturüberwachung-Funktion derzeit nur eingeschränkt zur Verfügung.
| Subnetz-Quelle | Ziel (DNS-Name) | Port/Protokoll | Zweck |
|---|---|---|---|
| Management |
|
80 und 443/TCP | Ubuntu-Softwarepaketserver. Wird von der Linux-basierten Appliance für Ubuntu-Betriebssystem-Updates verwendet. |
| Management | esm.ubuntu.com | 80 und 443/TCP | Ubuntu-Softwarepaketserver. Wird von der Linux-basierten Appliance für die Verfolgung von Sicherheits-Updates für hohe und kritische CVEs (Common Vulnerabilities and Exposures) im Ubuntu-Basisbetriebssystem und in der Infrastruktur für die horizontale Skalierung verwendet. |
| Management |
|
443/TCP | Wird für den programmgesteuerten Zugriff auf Azure Blob Storage verwendet. Wird zum Herunterladen der Docker-Images aus den DNS-Adressen verwendet, die vom Modul der Appliance benötigt werden. |
| Management | *.azure-devices.net oder einer der folgenden regionsspezifischen Namen, je nachdem, welche regionale Steuerungsebene für Ihr Mandantenkonto gilt: Nordamerika:
Europa:
Australien:
Japan:
|
443/TCP | Wird zum Verbinden der Appliance mit der Horizon Cloud-Steuerungsebene, zum Herunterladen von Konfigurationen für das Appliance-Modul und zum Aktualisieren des Laufzeitstatus des Appliance-Moduls verwendet. |
| Management |
|
443/TCP | Wird zum Herunterladen von Docker- und Kubernetes-Binärdateien verwendet, die von der Appliance benötigt werden. |
| Management | Abhängig von der regionalen Steuerungsebene, die für Ihr Mandantenkonto gilt: Nordamerika:
Europa:
Australien:
Japan:
|
443/TCP | Wird zum Senden der von der Appliance erfassten Pod-Überwachungsdaten an die Horizon Cloud-Steuerungsebene verwendet. |
| Management | Wenn Ihre Firewall oder Netzwerksicherheitsgruppe (NSG) die Verwendung von Diensttags unterstützt, wenden Sie das Azure-Diensttag AzureCloud an. Wenn Ihre Firewall oder NSG die Verwendung von Diensttags nicht unterstützt, verwenden Sie den Hostnamen:
|
1514 und 1515/TCP | Wird für die Systemüberwachung verwendet |
Falls für eine aktive Support-Anfrage erforderlich, temporäre Jumpbox-Ports und ‑Protokolle
Wenn Sie eine Support-Anfrage an VMware stellen und das Supportteam feststellt, dass diese Anfrage durch die Bereitstellung einer temporären Jumpbox-VM für die SSH-Kommunikation mit den von VMware verwalteten Appliances bearbeitet werden kann, benötigt diese Jumpbox die hier beschriebenen Ports und Protokolle.
Für eine supportbezogene Jumpbox-Bereitstellung werden Sie um Erlaubnis gefragt. Dase VMware Support-Team informiert Sie in jeder Support-Situation über sämtliche Anforderungen.
Diese supportbezogene Jumpbox-VM ist so konzipiert, dass sie als Quelle mit den folgenden Zielen kommuniziert:
- Port 22 der Pod-Manager-VMs des Pods über SSH und Port 22.
- Port 9443 der Unified Access Gateway-VMs unter Verwendung von HTTPS.
- Der Port 22 der Gateway-Connector-VM über SSH, in einer Bereitstellung, bei der das externe Gateway in seinem eigenen VNet bereitgestellt wird.
- Der Virtuelle Horizon Edge-Appliance-Port 22 unter Verwendung von SSH in einer Bereitstellung mit Horizon-Infrastrukturüberwachung konfiguriert.
Da diesen VMs dynamisch IP-Adressen zugewiesen werden, können die folgenden Netzwerkregeln die beschriebene Kommunikation bereitstellen. Erkundigen Sie sich während der Support-Anforderungen stets beim VMware Support nach den Anforderungen für die supportbezogene Jumpbox-Bereitstellung.
- Das Management-Subnetz CIDR als Quelle und Ziel, mit Zielport 22, Quellport beliebig und Protokoll TCP.
- Das Management-Subnetz CIDR als Quelle und Ziel, mit Zielport 9443, Quellport beliebig und Protokoll TCP, wenn eine Unified Access Gateway-Konfiguration involviert ist.
