Azure Stack Hub Ruggedized-Netzwerkintegration
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.
Domain Name System
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:
<NAMINGPREFIX>-ns01.<REGION>.<EXTERNALDOMAINNAME>
<NAMINGPREFIX>-ns02.<REGION>.<EXTERNALDOMAINNAME>
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, finden Sie weitere Informationen im TechNet-Artikel Assign a Conditional Forwarder for a Domain Name (Zuweisen einer bedingten Weiterleitung für einen Domänennamen) oder in der spezifischen Dokumentation für Ihre DNS-Lösung.
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:
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.
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.
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 | Protokoll | Ports | Quellnetzwerk |
---|---|---|---|---|
Identität | 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 |
Verbrauch | 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 |
Domain Name System | (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.
Hinweis
IKEv2-VPN ist eine standardbasierte IPsec-VPN-Lösung, für die UDP-Port 500 und 4500 sowie TCP-Port 50 verwendet werden. Da diese Ports in Firewalls nicht immer geöffnet sind, kann eine IKEv2-VPN-Verbindung die Proxys und Firewalls ggf. nicht immer durchlaufen.
Endpunkt (VIP) | A-Eintrag des DNS-Hosts | Protokoll | Ports |
---|---|---|---|
AD FS | Adfs.<region>.<fqdn> | HTTPS | 443 |
Portal (Administrator) | Adminportal.<region>.<fqdn> | HTTPS | 443 |
Administratorhosting | *.adminhosting.<region>.<fqdn> | HTTPS | 443 |
Azure Resource Manager (Administrator) | Adminmanagement.<region>.<fqdn> | HTTPS | 443 |
Portal (Benutzer) | Portal.<region>.<fqdn> | HTTPS | 443 |
Azure Resource Manager (Benutzer) | Management.<region>.<fqdn> | HTTPS | 443 |
Diagramm | Graph.<region>.<fqdn> | HTTPS | 443 |
Zertifikatsperrliste | Crl.<region>.<fqdn> | HTTP | 80 |
Domain Name System | *.<region>.<fqdn> | TCP und UDP | 53 |
Hosting | *.hosting.<region>.<fqdn> | HTTPS | 443 |
Key Vault (Benutzer) | *.vault.<region>.<fqdn> | HTTPS | 443 |
Key Vault (Administrator) | *.adminvault.<region>.<fqdn> | HTTPS | 443 |
Speicherwarteschlange | *.queue.<region>.<fqdn> | HTTP HTTPS |
80 443 |
Storage-Tabelle | *.table.<region>.<fqdn> | HTTP HTTPS |
80 443 |
Speicherblob | *.blob.<region>.<fqdn> | HTTP HTTPS |
80 443 |
SQL-Ressourcenanbieter | sqladapter.dbadapter.<region>.<fqdn> | HTTPS | 44300-44304 |
MySQL-Ressourcenanbieter | mysqladapter.dbadapter.<region>.<fqdn> | HTTPS | 44300-44304 |
App Service | *.appservice.<region>.<fqdn> | TCP | 80 (HTTP) 443 (HTTPS) 8172 (MSDeploy) |
*.scm.appservice.<region>.<fqdn> | TCP | 443 (HTTPS) | |
api.appservice.<region>.<fqdn> | TCP | 443 (HTTPS) 44300 (Azure Resource Manager) |
|
ftp.appservice.<region>.<fqdn> | TCP, UDP | 21, 1021, 10001-10100 (FTP) 990 (FTPS) |
|
VPN-Gateways | Weitere Informationen finden Sie unter Häufig gestellte Fragen zum VPN-Gateway. | ||