Azure Stack Hub Ruggedized-Netzwerkintegration

Artikel
07/12/2023

In diesem Thema wird die Azure Stack-Netzwerkintegration behandelt.

Grenzkonnektivität (Uplink)

Die Planung der Netzwerkintegration ist eine wichtige Voraussetzung, um erfolgreich integrierte Azure Stack-Systeme bereitstellen, betreiben und verwalten zu können. Bei der Planung der Konnektivität über Border-Geräte entscheiden Sie zuerst, ob Sie dynamisches Routing mit Border Gateway Protocol (BGP) verwenden möchten. Hierfür muss eine autonome 16-Bit-BGP-Systemnummer (öffentlich oder privat) zugewiesen oder statisches Routing verwendet werden, wenn Border-Geräten eine statische Standardroute zugewiesen wird.

Für TOR-Switches (Top of Rack) sind Layer 3-Uplinks mit für physische Schnittstellen konfigurierte Point-to-Point-IP-Adressen (Netzwerke vom Typ „/30“) erforderlich. Layer 2-Uplinks mit TOR-Switches mit Unterstützung für Azure Stack-Vorgänge werden nicht unterstützt.

BGP-Routing

Durch ein dynamisches Routingprotokoll wie BGP wird die Erkennung von Netzwerkänderungen durch Ihr System sichergestellt und die Verwaltung vereinfacht. Zur Verbesserung der Sicherheit kann für das BGP-Peering zwischen TOR und Grenze ein Kennwort festgelegt werden.

Wie im folgenden Diagramm dargestellt, wird die Ankündigung des privaten IP-Bereichs für den TOR-Switch durch eine Präfixliste blockiert. Die Präfixliste lehnt die Ankündigung des privaten Netzwerks ab und wird als Routenzuordnung für die Verbindung zwischen TOR und Grenze angewendet.

Software Load Balancer (SLB) in der Azure Stack-Lösung stellt mittels Peering eine Verbindung mit TOR-Geräten her, damit die VIP-Adressen dynamisch angekündigt werden können.

Um sicherzustellen, dass Benutzerdatenverkehr nach einem Fehler umgehend und transparent wiederhergestellt wird, ermöglicht die zwischen den TOR-Geräten konfigurierte vPC- oder MLAG-Vernetzung die Verwendung von MLAG (Multi-Chassis Link Aggregation) für die Hosts sowie des HSRP- oder VRRP-Protokolls, das Redundanz für die IP-Netzwerke bietet.

Statisches Routing

Statisches Routing erfordert zusätzliche Konfiguration für die Border-Geräte. Vor jeder Änderung sind mehr manuelle Intervention und Verwaltung sowie eine gründliche Analyse erforderlich. Bei Problemen, die durch Konfigurationsfehler verursacht wurden, kann der Rollback je nach den vorgenommenen Änderungen relativ zeitintensiv sein. Diese Routingmethode wird nicht empfohlen, jedoch unterstützt.

Zum Integrieren von Azure Stack in Ihre Netzwerkumgebung mithilfe von statischem Routing müssen alle vier physischen Verknüpfungen zwischen dem Border- und dem Tor-Gerät verbunden sein. Hohe Verfügbarkeit kann aufgrund der Funktionsweise von statischem Routing nicht garantiert werden.

Das Grenzgerät muss für Datenverkehr an Netzwerke innerhalb von Azure Stack mit statischen Routen konfiguriert sein, die auf jede der vier festgelegten P2P-IP-Adressen zwischen dem Tor-Gerät und dem Grenzgerät verweisen, für den Betrieb ist jedoch nur das externe oder öffentliche VIP-Netzwerk erforderlich. Statische Routen zum BMC-Netzwerk und den externen Netzwerken sind für die erste Bereitstellung erforderlich. Operatoren können statische Routen auch an der Grenze beibehalten, um auf Verwaltungsressourcen im BMC- und im Infrastrukturnetzwerk zuzugreifen. Das Hinzufügen von statischen Routen zu Switchinfrastruktur- und Switchverwaltungsnetzwerken ist optional.

Die Tor-Geräte sind mit einer statischen Standardroute vorkonfiguriert, die sämtlichen Datenverkehr an die Border-Geräte sendet. Die einzige Datenverkehrsausnahme von der Standardregel ist der private Bereich. Dieser wird mithilfe einer Zugriffssteuerungsliste für die Verbindung zwischen dem Tor- und Border-Gerät blockiert.

Statisches Routing wird nur auf die Uplinks zwischen den Tor- und Border-Switches angewendet. Im Rack kommt nach wie vor dynamisches BGP-Routing zum Einsatz, da es ein unverzichtbares Hilfsmittel für SLB und andere Komponenten darstellt. Es kann daher nicht deaktiviert oder entfernt werden.

* Das BMC-Netzwerk ist nach der Bereitstellung optional.

** Das Switchinfrastrukturnetzwerk ist optional, da das gesamte Netzwerk in das Switchverwaltungsnetzwerk eingeschlossen werden kann.

*** Das Switchverwaltungsnetzwerk ist erforderlich und kann separat aus dem Switchinfrastrukturnetzwerk hinzugefügt werden.

Transparenter Proxy

Wenn Ihr Rechenzentrum verlangt, dass für den gesamten Datenverkehr ein Proxy verwendet wird, müssen Sie einen transparenten Proxy konfigurieren. Dieser muss den gesamten Datenverkehr gemäß den Richtlinien verarbeiten und den Datenverkehr zwischen den Zonen in Ihrem Netzwerk trennen.

Die Azure Stack-Lösung unterstützt keine normalen Webproxys.

Ein transparenter Proxy (auch abfangender, inline oder erzwungener Proxy genannt) fängt die normale Kommunikation auf der Netzwerkschicht ab, ohne dass eine spezielle Clientkonfiguration erforderlich ist. Clients müssen nicht wissen, dass der Proxy vorhanden ist.

Das Abfangen von SSL-Datenverkehr wird nicht unterstützt und kann beim Zugriff auf Endpunkte zu Dienstfehlern führen. Das maximal unterstützte Zeitlimit für die Kommunikation mit Endpunkten, die für die Identität erforderlich sind, ist 60 Sekunden mit drei Wiederholungsversuchen.

DNS

In diesem Abschnitt wird die DNS-Konfiguration (Domain Name System) behandelt.

Konfigurieren der bedingten DNS-Weiterleitung

Diese Informationen gelten nur für eine AD FS-Bereitstellung.

Um die Namensauflösung mit Ihrer vorhandenen DNS-Infrastruktur zu ermöglichen, konfigurieren Sie eine bedingte Weiterleitung.

Zum Hinzufügen einer bedingten Weiterleitung müssen Sie den privilegierten Endpunkt verwenden.

Verwenden Sie für diesen Vorgang einen Computer in Ihrem Datencenternetzwerk, der mit dem privilegierten Endpunkt in Azure Stack kommunizieren kann.

Öffnen Sie eine Windows PowerShell-Sitzung mit erhöhten Rechten (Als Administrator ausführen), und stellen Sie eine Verbindung zur IP-Adresse des privilegierten Endpunkts her. Verwenden Sie die Anmeldeinformationen für die CloudAdmin-Authentifizierung.
```
\$cred=Get-Credential Enter-PSSession -ComputerName \<IP Address of ERCS\> -ConfigurationName PrivilegedEndpoint -Credential \$cred 
```
Nachdem Sie eine Verbindung mit dem privilegierten Endpunkt hergestellt haben, führen Sie folgenden PowerShell-Befehl aus. Ersetzen Sie die bereitgestellten Beispielwerte durch Ihren Domänennamen und die IP-Adressen des DNS-Servers, den Sie verwenden möchten.
```
Register-CustomDnsServer -CustomDomainName "contoso.com" -CustomDnsIPAddresses "192.168.1.1","192.168.1.2" 
```

Auflösen von Azure Stack-DNS-Namen von außerhalb von Azure Stack

Die autoritativen Server enthalten die Informationen zu externen DNS-Zonen und zu allen vom Benutzer erstellten Zonen. Integrieren Sie diese Server, um die Zonendelegierung oder die bedingte Weiterleitung für das Auflösen von Azure Stack-DNS-Namen von außerhalb von Azure Stack zu aktivieren.

Erhalten der externen Endpunktinformationen des DNS-Servers

Sie benötigen folgende Informationen, um Ihre Azure Stack-Bereitstellung in Ihre DNS-Infrastruktur zu integrieren:

Vollqualifizierte Domänennamen des DNS-Servers
IP-Adressen des DNS-Servers

Die vollqualifizierten Domänennamen für die Azure Stack-DNS-Server weisen folgendes Format auf:

Wenn Sie die Beispielwerte verwenden, sind die vollqualifizierten Domänennamen für die DNS-Server Folgende:

azs-ns01.east.cloud.fabrikam.com

azs-ns02.east.cloud.fabrikam.com

Diese Informationen sind im Verwaltungsportal verfügbar, werden aber auch am Ende aller Azure Stack-Bereitstellungen in einer Datei namens AzureStackStampInformation.json festgehalten. Diese Datei befindet sich im Ordner „C:\CloudDeployment\logs“ des virtuellen Computers der Bereitstellung. Wenn Sie nicht sicher sind, welche Werte für Ihre Azure Stack-Bereitstellung verwendet werden, können Sie diese Werte hier abrufen.

Wenn der virtuelle Computer für die Bereitstellung nicht mehr verfügbar ist oder nicht darauf zugegriffen werden kann, können Sie die Werte abrufen, indem Sie eine Verbindung mit dem privilegierten Endpunkt herstellen und das PowerShell-Cmdlet Get-AzureStackStampInformation ausführen. Weitere Informationen finden Sie unter Privilegierter Endpunkt.

Einrichten der bedingten Weiterleitung an Azure Stack

Der einfachste und sicherste Weg, um Azure Stack in Ihre DNS-Infrastruktur zu integrieren, ist die bedingte Weiterleitung der Zone von dem Server aus, der die übergeordnete Zone hostet. Dieser Ansatz wird empfohlen, wenn Sie die direkte Kontrolle über die DNS-Server besitzen, die die übergeordnete Zone für Ihren externen DNS-Namespace von Azure Stack hosten.

Wenn Sie nicht mit der bedingten Weiterleitung mit DNS vertraut sind, lesen Sie folgenden TechNet-Artikel: Weisen Sie einem Domänennamen eine bedingte Weiterleitung zu, oder gehen Sie gemäß der Dokumentation Ihrer DNS-Lösung vor.

In Szenarios, in denen Sie angegeben haben, dass Ihre externe Azure Stack-DNS-Zone wie die untergeordnete Domäne des Namens Ihrer Unternehmensdomäne aussehen soll, kann die bedingte Weiterleitung nicht verwendet werden. Die DNS-Delegierung muss konfiguriert werden.

Beispiel:

DNS-Domänenname des Unternehmens: contoso.com
Externer Azure Stack-DNS-Domänenname: azurestack.contoso.com

Bearbeiten von IP-Adressen der DNS-Weiterleitung

IP-Adressen der DNS-Weiterleitung werden während der Bereitstellung von Azure Stack festgelegt. Wenn die IP-Adressen der Weiterleitung allerdings aus irgendeinem Grund aktualisiert werden müssen, können Sie die Werte bearbeiten, indem Sie eine Verbindung mit dem privilegierten Endpunkt herstellen und die PowerShell-Cmdlets Get-AzSDnsForwarder und Set-AzSDnsForwarder [[-IPAddress] <IPAddress[]>] ausführen. Weitere Informationen finden Sie unter Privilegierter Endpunkt.

Delegieren der externen DNS-Zone an Azure Stack

Damit DNS-Namen von außerhalb einer Azure Stack-Bereitstellung auflösbar sind, müssen Sie eine DNS-Delegierung einrichten.

Jede Registrierungsstelle hat seine eigenen DNS-Verwaltungstools, um die Namenservereinträge für eine Domäne zu ändern. Bearbeiten Sie auf der DNS-Verwaltungsseite der Registrierungsstelle die NS-Einträge, und ersetzen Sie die NS-Einträge für die Zone durch die in Azure Stack erstellten Einträge.

Die meisten DNS-Registrierungsstellen erfordern, dass Sie mindestens zwei DNS-Server angeben, um die Delegierung abzuschließen.

Firewall

Azure Stack richtet für die eigenen Infrastrukturrollen virtuelle IP-Adressen (VIPs) ein. Diese VIPs stammen aus dem öffentlichen IP-Adresspool. Jede VIP wird durch eine Zugriffssteuerungsliste (Access Control List, ACL) auf der softwaredefinierten Netzwerkebene geschützt. Für zusätzlichen Schutz werden außerdem übergreifende ACLs für die physischen Switches (TORs und BMC) verwendet. Für jeden Endpunkt in der externen DNS-Zone, die zum Zeitpunkt der Bereitstellung angegeben wurde, wird ein DNS-Eintrag erstellt. Dem Benutzerportal wird z. B. der DNS-Hosteintrag „portal.<region>.<fqdn>“ zugewiesen.

Das folgende Architekturdiagramm zeigt die verschiedenen Netzwerkebenen und ACLs:

Architekturdiagramm der verschiedenen Netzwerkebenen und ACLs

Ports und URLs

Damit Sie Azure Stack-Dienste (wie Portale, Azure Resource Manager, DNS, usw.) für externe Netzwerke zur Verfügung stellen können, müssen Sie für diese Endpunkte den eingehenden Datenverkehr für bestimmte URLs, Ports und Protokolle zulassen.

In einer Bereitstellung mit einem Uplink zwischen einem transparenten Proxy und einem herkömmlichen Proxyserver bzw. wenn eine Firewall die Lösung schützt, müssen sowohl für die eingehende als auch die ausgehende Kommunikation bestimmte Ports und URLs zugelassen werden. Dazu gehören Ports und URLs für Identität, der Marketplace, Patch und Update, Registrierung und Nutzungsdaten.

Ausgehende Kommunikation

Azure Stack unterstützt nur transparente Proxyserver. In einer Bereitstellung mit einem Uplink zwischen einem transparenten Proxy und einem herkömmlichen Proxyserver müssen für die ausgehende Kommunikation bei einer Bereitstellung im verbundenen Modus die Ports und URLs in der folgenden Tabelle zugelassen werden.

Hinweis

Azure Stack bietet keine Unterstützung für die Verwendung von ExpressRoute zur Kommunikation mit den in der folgenden Tabelle aufgeführten Azure-Diensten, da ExpressRoute den Datenverkehr möglicherweise nicht an alle Endpunkte weiterleiten kann.

Zweck	Ziel-URL	Protocol	Ports	Quellnetzwerk
Identity	Azure login.windows.net login.microsoftonline.com graph.windows.net https://secure.aadcdn.microsoftonline-p.com www.office.com ManagementServiceUri = https://management.core.windows.net ARMUri = https://management.azure.com https://.msftauth.net https://.msauth.net https://.msocdn.com Azure Government* https://login.microsoftonline.us/ https://graph.windows.net/ Azure China 21Vianet https://login.chinacloudapi.cn/ https://graph.chinacloudapi.cn/ Azure Deutschland https://login.microsoftonline.de/ https://graph.cloudapi.de/	HTTP HTTPS	80 443	Öffentliche VIP - /27 Öffentliches Infrastrukturnetzwerk
Marketplace-Syndikation	Azure https://management.azure.com https://.blob.core.windows.net https://.azureedge.net Azure Government https://management.usgovcloudapi.net/ https://.blob.core.usgovcloudapi.net/ Azure China 21Vianet* https://management.chinacloudapi.cn/ http://*.blob.core.chinacloudapi.cn	HTTPS	443	Öffentliche VIP - /27
Patches und Updates	https://*.azureedge.net https://aka.ms/azurestackautomaticupdate	HTTPS	443	Öffentliche VIP - /27
Registrierung	Azure https://management.azure.com Azure Government https://management.usgovcloudapi.net/ Azure China 21Vianet https://management.chinacloudapi.cn	HTTPS	443	Öffentliche VIP - /27
Verwendung	Azure https://.trafficmanager.net Azure Government* https://.usgovtrafficmanager.net Azure China 21Vianet* https://*.trafficmanager.cn	HTTPS	443	Öffentliche VIP - /27
Windows Defender	.wdcp.microsoft.com .wdcpalt.microsoft.com .wd.microsoft.com .update.microsoft.com *.download.microsoft.com https://www.microsoft.com/pkiops/crl https://www.microsoft.com/pkiops/certs https://crl.microsoft.com/pki/crl/products https://www.microsoft.com/pki/certs https://secure.aadcdn.microsoftonline-p.com	HTTPS	80 443	Öffentliche VIP - /27 Öffentliches Infrastrukturnetzwerk
NTP	(IP des für die Bereitstellung bereitgestellten NTP-Servers)	UDP	123	Öffentliche VIP - /27
DNS	(IP des für die Bereitstellung bereitgestellten DNS-Servers)	TCP UDP	53	Öffentliche VIP - /27
CRL	(URL unter CRL-Verteilungspunkten auf Ihrem Zertifikat)	HTTP	80	Öffentliche VIP - /27
LDAP	Active Directory-Gesamtstruktur, bereitgestellt für die Graph-Integration	TCP UDP	389	Öffentliche VIP - /27
LDAP SSL	Active Directory-Gesamtstruktur, bereitgestellt für die Graph-Integration	TCP	636	Öffentliche VIP - /27
LDAP GC	Active Directory-Gesamtstruktur, bereitgestellt für die Graph-Integration	TCP	3268	Öffentliche VIP - /27
LDAP GC SSL	Active Directory-Gesamtstruktur, bereitgestellt für die Graph-Integration	TCP	3269	Öffentliche VIP - /27
AD FS	AD FS-Metadatenendpunkt, bereitgestellt für die AD FS-Integration	TCP	443	Öffentliche VIP - /27
Sammlungsdienst für Diagnoseprotokolle	Von Azure Storage bereitgestellte Blob SAS URL	HTTPS	443	Öffentliche VIP - /27

Eingehende Kommunikation

Eine Reihe von Infrastruktur-VIPs wird für die Veröffentlichung von Azure Stack-Endpunkten in externen Netzwerken benötigt. Die Tabelle Endpunkt (VIP) enthält jeweils den Endpunkt, den erforderlichen Port und das Protokoll. Informationen zu Endpunkten, für die zusätzliche Ressourcenanbieter (etwa der SQL-Ressourcenanbieter) erforderlich sind, finden Sie in der Bereitstellungsdokumentation des jeweiligen Ressourcenanbieters.

Interne Infrastruktur-VIPs sind nicht aufgeführt, da sie zum Veröffentlichen von Azure Stack nicht benötigt werden. Benutzer-VIPs sind dynamisch und werden von den Benutzern selbst definiert. Der Azure Stack-Operator hat darauf keinen Einfluss.