Für eine erfolgreiche End-to-End-Nutzung der Dienstfunktionen müssen Sie sicherstellen, dass die in diesem Dokumentationsartikel beschriebenen DNS-Namen (Domain Name Service) auflösbar und über das Verwaltungs- und Mandantensubnetz mithilfe bestimmter Ports und Protokolle, die in den Tabellen dieses Artikels angegeben werden, erreichbar sind.

Für die Pod-Bereitstellung ist es erforderlich, dass die VMs über das von Ihnen ausgewählte VNet Zugriff auf diese Hosts (DNS-Namen) haben. 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. In diesem Artikel werden diese DNS-Anforderungen beschrieben.

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.

Tabelle 1. Regionen in ihrer Begrüßungs-E-Mail, die den DNS-Namen der regionalen Steuerungsebene zugeordnet sind
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.

Achtung: Ab Anfang 2021 ist der DNS-Name 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.
Tabelle 2. DNS-Anforderungen für die Bereitstellung neuer Pods, Pod-Updates und Dienstvorgänge, die mandantenübergreifend angewendet werden
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.
  • cloud.horizon.vmware.com
  • cloud-us-2.horizon.vmware.com
  • cloud-eu-central-1.horizon.vmware.com
  • cloud-eu-2.horizon.vmware.com
  • cloud-ap-southeast-2.horizon.vmware.com
  • cloud-ap-2.horizon.vmware.com
  • cloud-jp.horizon.vmware.com
  • cloud-uk.horizon.vmware.com
  • cloud-de.horizon.vmware.com
443 TCP Regionale Steuerungsebeneninstanz
  • USA: cloud.horizon.vmware.com, cloud-us-2.horizon.vmware.com
  • Europa: cloud-eu-central-1.horizon.vmware.com, cloud-eu-2.horizon.vmware.com
  • Asien-Pazifik: cloud-ap-southeast-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com
  • Japan: cloud-jp.horizon.vmware.com
  • Großbritannien: cloud-uk.horizon.vmware.com
  • Deutschland: cloud-de.horizon.vmware.com
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:
  • Microsoft Azure (global): login.microsoftonline.com
  • Microsoft Azure Deutschland: login.microsoftonline.de
  • Microsoft Azure China: login.chinacloudapi.cn
  • Microsoft Azure US-Regierung: login.microsoftonline.us
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:
  • Microsoft Azure (global): management.azure.com
  • Microsoft Azure Deutschland: management.microsoftazure.de
  • Microsoft Azure China: management.chinacloudapi.cn
  • Microsoft Azure US-Regierung: management.usgovcloudapi.net
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:
  • Microsoft Azure (global): graph.windows.net
  • Microsoft Azure Deutschland: graph.cloudapi.de
  • Microsoft Azure China: graph.chinacloudapi.cn
  • Microsoft Azure US-Regierung: graph.windows.net
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:
  • Globaler Azure-SQL-Diensttag: Sql
  • Regionsspezifischer SQL-Diensttag für die Azure-Region, in der der Pod bereitgestellt wird: Sql. Region , z. B. Sql.WestUS.

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.
  • connector-azure-us.vmwarehorizon.com
  • connector-azure-eu.vmwarehorizon.com
  • connector-azure-aus.vmwarehorizon.com
  • connector-azure-jp.vmwarehorizon.com
  • connector-azure-uk.vmwarehorizon.com
  • connector-azure-de.vmwarehorizon.com

443 TCP Regionale Instanz des Universal Broker-Dienstes
  • Vereinigte Staaten: connector-azure-us.vmwarehorizon.com
  • Europa: connector-azure-eu.vmwarehorizon.com
  • Australien: connector-azure-aus.vmwarehorizon.com
  • Japan: connector-azure-jp.vmwarehorizon.com
  • Großbritannien: connector-azure-uk.vmwarehorizon.com
  • Deutschland: connector-azure-de.vmwarehorizon.com
Management Abhängig von der regionalen Steuerungsebene, die für Ihr Horizon Cloud-Konto gilt:
  • Nordamerika: kinesis.us-east-1.amazonaws.com
  • Europa, Deutschland: kinesis.eu-central-1.amazonaws.com
  • Australien: kinesis.ap-southeast-2.amazonaws.com
  • Japan: kinesis.ap-northeast-1.amazonaws.com
  • Großbritannien: kinesis.eu-west-2.amazonaws.com
443 TCP Cloud Monitoring Service (CMS)
Verwaltung – Pod-Manager-VMs, Unified Access Gateway-VMs, Gateway-Connector-VM, Virtuelle Horizon Edge-Appliance

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:

  • Kommerzielle Umgebungen: Erlauben Sie den Hostnamen monitor.horizon.vmware.com
  • Umgebungen der US-Regierung: Eröffnen Sie einen Fall beim VMware Federal Support, um den Hostnamen des Überwachungssystems anzufordern.

1514

1515

TCP Wird für die Systemüberwachung verwendet
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.

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.

Hinweis: In dieser Tabelle sind im Gegensatz zur vorherigen Tabelle keine DNS-Namen mit uk enthalten. Wie in den Versionshinweisen angegeben, steht diese Horizon-Infrastrukturüberwachung-Funktion derzeit nur eingeschränkt zur Verfügung.
Tabelle 3. DNS-Anforderungen für Horizon Infrastructure Monitoring
Subnetz-Quelle Ziel (DNS-Name) Port/Protokoll Zweck
Management
  • azure.archive.ubuntu.com
  • archive.ubuntu.com
  • changelogs.ubuntu.com
  • security.ubuntu.com
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
  • *.blob.core.windows.net
  • horizonedgeprod.azurecr.io
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:

  • edgehubprodna.azure-devices.net

Europa:

  • edgehubprodeu.azure-devices.net

Australien:

  • edgehubprodap.azure-devices.net

Japan:

  • edgehubprodjp.azure-devices.net
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
  • *.docker.com
  • *.docker.io
  • docker.io
  • cloud.google.com
  • gcr.io
  • ghcr.io
  • dl.k8s.io
  • k8s.gcr.io
  • storage.googleapis.com
  • cloud.weave.works
  • packages.cloud.google.com
  • apt.kubernetes.io
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:

  • kinesis.us-east-1.amazonaws.com
  • sauron.horizon.vmware.com

Europa:

  • kinesis.eu-central-1.amazonaws.com
  • sauron-eu.horizon.vmware.com

Australien:

  • kinesis.ap-southeast-2.amazonaws.com
  • sauron-ap.horizon.vmware.com

Japan:

  • kinesis.ap-northeast-1.amazonaws.com
  • sauron-jp.horizon.vmware.com
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:

  • Kommerzielle Umgebungen: Erlauben Sie den Hostnamen monitor.horizon.vmware.com
  • Umgebungen der US-Regierung: Eröffnen Sie einen Fall beim VMware Federal Support, um den Hostnamen des Überwachungssystems anzufordern.
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.