Damit die First-Generation-Horizon Cloud on Microsoft Azure-Bereitstellung von Tag 0 an erfolgreich ist, 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.
Über diese Seite
Wie in VMware KB-Artikel 93762 beschrieben, ist die Funktion Horizon-Infrastrukturüberwachung veraltet. Ab Oktober 2023 wurden die Informationen zu Ports und Protokollen, die sich auf diese veraltete Funktion beziehen, von dieser Seite entfernt.
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/).
Kurze Einführung
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 Hostnamen, 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.
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 First-Gen-Mandanten – Horizon Cloud-Pod – Anforderungen an Ports und Protokolle.
First-Gen-Mandanten – 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 |
Hostnamen, 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 Hostnamen 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 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
- Funktionen mit Bezug auf den Cloud Monitoring Service (CMS)
- Insbesondere für die Pod-Bereitstellung und Pod-Updates
-
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.
- 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.
- Wenn Sie App Volumes on Azure-Funktionen verwenden möchten
- Der Pod-Bereitsteller stellt ein Azure-Speicherkonto für die Verwendung durch die App Volumes on Azure-Funktionen des Pods in der Ressourcengruppe des Pod-Managers bereit. Bei der Bereitstellung weist Azure Cloud diesem Speicherkonto einen vollqualifizierten Domänennamen (FQDN) zu, der das Muster *.file.core.windows.net aufweist, wobei * der von Azure generierte Name des Speicherkontos ist. Dieser FQDN muss von Ihrem DNS-Server aufgelöst werden können, damit App Volumes auf die diesem Speicherkonto zugrundeliegenden Dateifreigaben zugreifen und diese mounten und die App Volumes-Funktionalität bereitstellen kann. Sie müssen sicherstellen, dass Ihr DNS-Server diesen FQDN jederzeit für die App Volumes Manager -Prozesse, die in den Pod-Manager-Instanzen ausgeführt werden, und für den App Volumes Agent, der auf den VDI-Desktops läuft, auflöst. Dieser Endpoint ist ein Microsoft Azure-Endpoint innerhalb Ihrer Microsoft Azure-Cloud-Umgebung. Die Verbindung wird direkt innerhalb des Microsoft Azure-Cloud-Bereichs hergestellt.
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.
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.
| Subnetz-Quelle | Ziel (DNS-Name) | Port | Protokoll | Proxy-Datenverkehr (sofern in der Bereitstellung konfiguriert) | 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 | Ja | Regionale Steuerungsebeneninstanz
|
| Management | softwareupdate.vmware.com | 443 | TCP | Ja | 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 | Nein Der Pod-Manager und die Unified Access Gateway-Binärmanifeste werden hier gespeichert und von hier aus bereitgestellt. Diese Manifeste werden nur zu Zeiten von Pod- und Gateway-Bereitstellungen und -Upgrades verwendet. Diese Verbindung zu diesem Endpoint ist so konfiguriert, dass sie direkt und nicht über einen Proxy erfolgt. |
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 | Nein Diese Site befindet sich außerhalb der Anwendung und des Diensts. Daher wird für die Verbindung nicht der konfigurierte Proxy verwendet. Dieser Endpoint ist ein Microsoft Azure-Endpoint innerhalb Ihrer Microsoft Azure-Cloud-Umgebung. Die Verbindung wird direkt innerhalb des Microsoft Azure-Cloud-Bereichs hergestellt. |
Microsoft Softwarepaketserver. Zum sicheren Herunterladen der Microsoft Azure Command Line Interface-(CLI)-Software. |
| Management | azure.archive.ubuntu.com | 80 | TCP | Nein Diese Site befindet sich außerhalb der Anwendung und des Diensts. Daher wird für die Verbindung nicht der konfigurierte Proxy verwendet. Dieser Endpoint ist ein Microsoft Azure-Endpoint innerhalb Ihrer Microsoft Azure-Cloud-Umgebung. Die Verbindung wird direkt innerhalb des Microsoft Azure-Cloud-Bereichs hergestellt. |
Ubuntu-Softwarepaketserver. Wird von den Pod-bezogenen Linux-basierten VMs für Aktualisierungen des Ubuntu-Betriebssystems verwendet. |
| Management | api.snapcraft.io | 443 | TCP | Nein Dieser Endpoint befindet sich außerhalb der Anwendung und des Diensts. Für die Verbindung wird der konfigurierte Proxy nicht verwendet. |
Ubuntu-Softwarepaketserver. Der Pod-Manager und Unified Access Gateway-Instanzen führen Ubuntu-Betriebssysteme aus. Diese Ubuntu-Betriebssysteme sind so konfiguriert, dass sie Updates für diese Ubuntu-Betriebssysteme von dieser Ubuntu-Site beziehen. |
| Management | archive.ubuntu.com | 80 | TCP | Nein Dieser Endpoint befindet sich außerhalb der Anwendung und des Diensts. Für die Verbindung wird der konfigurierte Proxy nicht verwendet. |
Ubuntu-Softwarepaketserver. Der Pod-Manager und Unified Access Gateway-Instanzen führen Ubuntu-Betriebssysteme aus. Diese Ubuntu-Betriebssysteme sind so konfiguriert, dass sie Updates für diese Ubuntu-Betriebssysteme von dieser Ubuntu-Site beziehen. |
| Management | changelogs.ubuntu.com | 80 | TCP | Nein Diese Site befindet sich außerhalb der Anwendung und des Diensts. Daher wird für die Verbindung nicht der konfigurierte Proxy verwendet. |
Ubuntu-Softwarepaketserver. Der Pod-Manager und Unified Access Gateway-Instanzen führen Ubuntu-Betriebssysteme aus. Diese Ubuntu-Betriebssysteme sind so konfiguriert, dass sie diese Ubuntu-Site für die Verfolgung von Ubuntu-Betriebssystem-Updates verwenden. |
| Management | security.ubuntu.com | 80 | TCP | Nein Dieser Endpoint befindet sich außerhalb der Anwendung und des Diensts. Für die Verbindung wird der konfigurierte Proxy nicht verwendet. |
Ubuntu-Softwarepaketserver. Der Pod-Manager und Unified Access Gateway-Instanzen führen Ubuntu-Betriebssysteme aus. Diese Ubuntu-Betriebssysteme sind für die Verwendung dieser Ubuntu-Site für sicherheitsbezogene Ubuntu-Betriebssystem-Updates konfiguriert. |
| Management | esm.ubuntu.com | 80 und 443 | TCP | Nein Dieser Endpoint befindet sich außerhalb der Anwendung und des Diensts. Für die Verbindung wird der konfigurierte Proxy nicht verwendet. |
Ubuntu-Softwarepaketserver. Der Pod-Manager und Unified Access Gateway-Instanzen führen Ubuntu-Betriebssysteme aus. Diese Ubuntu-Betriebssysteme sind so konfiguriert, dass sie diese Ubuntu-Site zur Verfolgung von Sicherheitsupdates für hohe und kritische CVEs (Common Vulnerabilities and Exposures) im Ubuntu-Basisbetriebssystem und in der Infrastruktur für die horizontale Skalierung verwenden. |
| Management | Eine der folgenden Optionen, je nachdem, in welcher Microsoft Azure-Cloud Sie Ihren Pod bereitstellen:
|
443 | TCP | Ja | 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 | Ja | 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 | Ja | 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 | Nein Dieser Endpoint ist der Microsoft Azure-PostgreSQL-Datenbankdienst innerhalb Ihrer Microsoft Azure-Cloud-Umgebung. Die Verbindung erfolgt direkt innerhalb des Microsoft Azure-Cloud-Bereichs. |
Wird für die Pod-Kommunikation mit dem Microsoft Azure PostgreSQL-Datenbankdienst verwendet, der für diese Horizon Cloud on Microsoft Azure-Bereitstellung konfiguriert ist. 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 | Ja | Regionale Instanz des Universal Broker-Dienstes
|
| Management | Abhängig von der regionalen Steuerungsebene, die für Ihr Horizon Cloud-Konto gilt:
|
443 | TCP | Ja | Cloud Monitoring Service (CMS) |
| Management |
|
443 | TCP | Nein | Der Endpoint *.blob.core.windows.net wird für den programmatischen Zugriff auf den Azure Blob Storage verwendet. Dieser Endpoint ist ein Microsoft Azure-Endpoint innerhalb Ihrer Microsoft Azure-Cloud-Umgebung. Die Verbindung mit diesem Endpoint wird direkt innerhalb des Microsoft Azure-Cloud-Bereichs hergestellt. Der Endpoint sauron-jp.horizon.vmware.com ermöglicht dem VMware-Überwachungssystem, Sicherheitsereignisse auf den von VMware verwalteten Instanzen zu erkennen. Aktiviert die Verwaltungszuständigkeit von VMware für die bereitgestellten Instanzen. Dies erfordert eine obligatorische VMware-Systemüberwachung dieser Instanzen. |
| Mandant | hydra-softwarelib-cdn.azureedge.net | 443 | TCP | Nein | 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 | Nein | 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. |
| Mandant | *.file.core.windows.net | 445 | TCP | Nein Dieser Endpoint ist der Microsoft Azure-Dateispeicherdienst innerhalb Ihrer Microsoft Azure-Cloud-Umgebung. Die Verbindung erfolgt direkt innerhalb des Microsoft Azure-Cloud-Bereichs. |
Wird für App Volumes on Azure-Funktionalität verwendet. Wird für den programmatischen Zugriff auf die SMB-Dateifreigabe in der Ressourcengruppe des Pod-Managers verwendet, um auf die App Volumes AppStacks zuzugreifen, die in dieser SMB-Dateifreigabe gespeichert sind. |
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 folgende Ressourcen in der Bereitstellung: Pod-Manager-Instanzen, Unified Access Gateway-Instanzen, Azure-Dateien im Zusammenhang mit App Volumes, Azure PostgreSQL-Dienst sowie die supportbezogene Jumpbox-Instanz, wenn diese zur Fehlerbehebung benötigt wird.
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 Port 1514 (TCP und UDP) und auf Port 1515 (TCP und UDP) 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 UDP) und 1515 (TCP und UDP) 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.
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.
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.
