In diesem Artikel wird beschrieben, wie Sie den Verbrauch an privatem Adressraum minimieren können, wenn Sie große Netzwerke in Azure aufbauen. Möglicherweise müssen Sie den Verbrauch an Adressraum minimieren, wenn keine geeigneten Zuweisungsrichtlinien festgelegt wurden und Ihnen die privaten IP-Adressen ausgehen, die Sie virtuellen Azure-Netzwerken zuweisen können. In diesem Artikel werden zwei Methoden für die richtige Verwaltung von IP-Adressen in Azure vorgestellt.
Szenariodetails
Unternehmensnetzwerke verwenden in der Regel Adressräume, die in den gemäß RFC 1918 definierten privaten IPv4-Adressbereichen liegen. Dies sind die Adressbereiche 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16. In lokalen Umgebungen bieten diese Bereiche genügend IP-Adressen, um selbst die Anforderungen der größten Netzwerke zu erfüllen. Daher entwickeln viele Organisationen Verfahren zur Adressverwaltung, die einfachen Routingkonfigurationen und flexiblen Prozessen für die IP-Zuweisung den Vorzug geben. Die effiziente Nutzung des Adressraums steht nicht im Vordergrund.
In der Cloud können mühelos große Hybridnetzwerke aufgebaut werden, und einige gängige Architekturmuster – z. B. Microservices oder Containerisierung – können zu einem höheren Verbrauch an IP-Adressen führen. Deshalb ist es wichtig, diese Verfahren zur Adressverwaltung anzupassen. In einer Cloudumgebung sollten Sie private IPv4-Adressen als eine begrenzte Ressource behandeln.
IP-Adressbereiche für virtuelle Azure-Netzwerke
Wir empfehlen Ihnen, in Ihren virtuellen Azure-Netzwerken die in RFC 1918 definierten Adressblöcke zu verwenden. Diese Adressblöcke sind für universelle private Netzwerke gedacht und können nicht über das öffentliche Internet geroutet werden.
Sie können auch andere Bereiche verwenden, aber vor einer Verwendung dieser Bereiche in Ihrem virtuellen Netzwerk sollten Sie sich anhand der IANA-Dokumentation (Internet Assigned Numbers Authority) über die möglichen Auswirkungen auf Ihre Umgebung informieren. Sie können die folgenden Bereiche verwenden:
- Freigegebener Adressraum, der durch RFC 6598 für die Netzwerkadressübersetzung (NAT) auf Netzbetreiberniveau definiert ist und in Azure Virtual Network als privater Adressraum behandelt wird. Der Adressblock lautet 100.64.0.0/10.
- Öffentliche IP-Adressen, die über das Internet geroutet werden können und die nicht im Besitz Ihrer Organisation sind. Von dieser Praxis wird abgeraten, da Ressourcen im virtuellen Netzwerk nicht auf Internetendpunkte zugreifen können, die über die öffentlichen IP-Adressen verfügbar gemacht werden.
- Spezielle Adressblöcke, die von der IANA definiert werden, z. B. 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24 und 233.252.0.0/24.
Hinweis
Der IP-Adressbereich der Klasse E 240.0.0.0/4 wird von Windows daran gehindert, sie einer NIC zuzuweisen und hat Kompatibilitätsprobleme im Falle von Linux. Es kann zwar möglich sein, einen Bereich programmgesteuert einem virtuellen Netzwerk zuzuweisen, aber wir empfehlen die Verwendung in virtuellen Azure-Netzwerken nicht.
Hinweis
Die oben genannten Bereiche bieten keine langfristige Lösung für Organisationen, die mit der Erschöpfung von IPv4-Adressen zu kämpfen haben. In diesem Fall sollten Sie den Verbrauch an privatem Adressraum minimieren.
Die folgenden IP-Adressbereiche können nicht in virtuellen Azure-Netzwerken verwendet werden:
- 224.0.0.0/4 (Multicast)
- 255.255.255.255/32 (Übertragung)
- 127.0.0.0/8 (Loopback)
- 169.254.0.0/16 (verbindungslokal)
- 168.63.129.16/32 (Internes DNS)
Ausrichtung der Azure-Zielzone
Die Empfehlungen in diesem Artikel beziehen sich auf Szenarien, die auf der Azure-Zielzonenarchitektur basieren. Hierbei wird Folgendes vorausgesetzt:
- Jede Region verfügt über eine Hub-and-Spoke-Topologie.
- Hub-and-Spoke-Netzwerke, die sich in verschiedenen Regionen befinden, sind über ein globales Peering virtueller Netzwerke oder per Anbindung an dieselben Azure ExpressRoute-Leitungen miteinander verbunden.
- Hub-and-Spoke-Netzwerke sind über eine Kombination aus ExpressRoute-Leitungen und Site-to-Site-VPNs mit lokalen Standorten verbunden.
Das folgende Diagramm zeigt eine Beispielarchitektur. Die Empfehlungen gelten auch für Netzwerke, die auf Azure Virtual WAN aufsetzen, das ebenfalls über Hub-and-Spoke-Netzwerke in jeder Region verfügt.
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
In einem Szenario, das auf der Azure-Zielzonenarchitektur basiert, werden Anwendungen in einer eigenen Zielzone bereitgestellt. Jede Zielzone umfasst ein virtuelles Spoke-Netzwerk, das per Peering mit einem regionalen Hub verbunden ist. Virtuelle Spoke-Netzwerke sind ein integraler Bestandteil des Unternehmensnetzwerks, denen routingfähige IPv4-Adressen zugewiesen werden. Diese Adressen sind im gesamten Unternehmensnetzwerk eindeutig. Somit nutzen alle im virtuellen Azure-Netzwerk bereitgestellten Architekturkomponenten IPv4-Adressen im Adressraum des Unternehmensnetzwerks, selbst wenn nur einige wenige Komponenten Endpunkte verfügbar machen, die vom gesamten Unternehmensnetzwerk aus erreichbar sein müssen. Bei diesen Architekturkomponenten kann es sich um virtuelle Computer (VMs), virtuelle Netzwerkgeräte (NVAs) von Drittanbietern oder um PaaS-Dienste (Platform-as-a-Service) handeln, die in virtuelle Netzwerke integriert sind.
Im weiteren Verlauf dieses Artikels bezieht sich Front-End-Komponente auf eine Anwendungskomponente, die vom gesamten Unternehmensnetzwerk oder von außerhalb der Zielzone der Komponente aus erreichbar ist. Back-End-Komponente bezieht sich auf eine Anwendungskomponente, die keine Endpunkte im Unternehmensnetzwerk verfügbar macht und nur innerhalb ihrer eigenen Zielzone erreichbar sein muss. Beispielsweise ist eine Webanwendung, die einen Endpunkt verfügbar macht, eine Front-End-Komponente und eine Datenbank, die keinen Endpunkt verfügbar macht, eine Back-End-Komponente.
In den folgenden Abschnitten werden zwei Methoden beschrieben, mit denen Sie den Verbrauch an privatem Adressraum minimieren können, wenn Sie große Netzwerke in Azure aufbauen.
Methode 1: Nicht routingfähige virtuelle Zielzonen-Spoke-Netzwerke
RFC 1918 definiert IP-Adressblöcke aus dem IPv4-32-Bit-Adressraum als nicht routingfähig für das öffentliche Internet, sodass Sie sie in verschiedenen privaten Netzwerken für die interne Kommunikation wiederverwenden können. Diese Methode basiert auf demselben Prinzip wie der private Adressraum. Einer oder mehrere Adressbereiche des gesamten privaten Adressraums, der von Ihrer Organisation verwendet wird, werden als nicht routingfähig innerhalb des Unternehmensnetzwerks Ihrer Organisation deklariert. Die Adressbereiche werden in mehreren Zielzonen wiederverwendet. Das Ergebnis für jede Zielzone:
- Ihr wird ein routingfähiger Adressraum zugewiesen, der sich aus einem oder mehreren Adressbereichen zusammensetzt. Ihre Organisation verwaltet die Adressbereiche zentral und ordnet sie eindeutig einer Zielzone für die Kommunikation mit dem Unternehmensnetzwerk zu. Adressen im routingfähigen Bereich werden Front-End-Komponenten zugewiesen.
- Sie kann den nicht routingfähigen Adressraum verwenden, d. h. die Adressbereiche, die Ihre Organisation im Unternehmensnetzwerk als nicht routingfähig deklariert hat. Sie können diese reservierten Bereiche für die interne Kommunikation in allen Zielzonen verwenden. Die Adressen im nicht routingfähigen Bereich werden den Back-End-Komponenten zugewiesen.
In einem kundenseitig verwalteten oder auf Virtual WAN basierenden Azure-Hub-and-Spoke-Netzwerk dürfen zwei oder mehr virtuelle Spoke-Netzwerke keine überlappenden IP-Adressräume aufweisen. Nicht routingfähige Adressblöcke können keinem Zielzonen-Spoke zugewiesen werden. Das Peering virtueller Netzwerke ist nicht transitiv, sodass ein virtuelles Zielzonen-Spoke-Netzwerk ein Peering mit einem virtuellen Spoke-Netzwerk der zweiten Ebene durchführen kann, das über einen nicht routingfähigen Adressraum verfügt. Das folgende Diagramm zeigt die duale VNet-Topologie für Zielzonen.
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
Jede Anwendungszielzone enthält zwei virtuelle Netzwerke mit Peering. Ein virtuelles Netzwerk verfügt über routingfähige IP-Adressen und hostet Front-End-Komponenten. Das andere virtuelles Netzwerk umfasst nicht routingfähige IP-Adressen und hostet Back-End-Komponenten. Der routingfähige Zielzonen-Spoke ist per Peering mit dem regionalen Hub verbunden. Der nicht routingfähige Zielzonen-Spoke wird per Peering mit dem routingfähigen Zielzonen-Spoke verbunden. Das Peering virtueller Netzwerke ist nicht transitiv, sodass nicht routingfähige Präfixe weder für den regionalen Hub noch für den Rest des Unternehmensnetzwerks sichtbar sind. Die routingfähigen virtuellen Netzwerke können keine nicht routingfähigen Adressbereiche verwenden. Einige Organisationen verfügen über fragmentierten Adressraum, der bereits routingfähigen Netzwerken zugewiesen ist. Es kann schwierig sein, ungenutzte große Adressblöcke zu identifizieren und sie als nicht routingfähig zu deklarieren. In diesem Fall sollten Sie ungenutzte Adressen in Betracht ziehen, die nicht im RFC 1918-Adressraum enthalten sind. Das obige Diagramm zeigt ein Beispiel für NAT-Adressen auf Netzbetreiberniveau (wie RFC 6598) in virtuellen, nicht routingfähigen Spoke-Netzwerken.
Migration einer Zielzone mit einem einzelnen virtuellen Netzwerk
Das Peering virtueller Netzwerke bietet vollständige Layer-3-Konnektivität zwischen zwei virtuellen Netzwerken, die per Peering verbunden sind. Anwendungskomponenten, die in herkömmlichen Zielzonen mit einem einzelnen virtuellen Netzwerk bereitgestellt werden und über IP miteinander kommunizieren, können frei zwischen routingfähigen und nicht routingfähigen virtuellen Spoke-Netzwerken in einer Zielzone verschoben werden. In diesem Abschnitt werden zwei typische Migrationsmuster beschrieben.
Die folgenden Anwendungen werden über einen Layer-7-ADC (Application Delivery Controller) verfügbar gemacht:
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
Anwendungen, die über einen Layer-7-ADC verfügbar gemacht werden, können in den nicht routingfähigen Spoke verschoben werden. Der ADC ist die einzige Front-End-Komponente, die sich im routingfähigen Zielzonen-Spoke befinden muss.
Die folgenden Anwendungen werden über einen Azure-Lastenausgleich verfügbar gemacht:
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
Wenn eine Anwendung ihre Endpunkte mittels Azure-Lastenausgleich verfügbar macht, müssen die im Back-End-Pool für den Lastenausgleich enthaltenen Compute-Instanzen im selben virtuellen Netzwerk verbleiben. Der Azure-Lastenausgleich unterstützt nur Back-End-Instanzen in deren eigenem virtuellen Netzwerk.
Ausgehende Abhängigkeiten
Die Back-End-Komponenten einer Anwendung müssen nicht vom Unternehmensnetzwerk aus erreichbar sein oder eingehende Verbindungen annehmen, aber sie müssen häufig ausgehende Verbindungen herstellen können. Back-End-Komponenten müssen unter Umständen eine Verbindung mit Endpunkten herstellen, die sich außerhalb ihrer Zielzonen befinden. Dies gilt z. B. für die DNS-Auflösung, Active Directory Domain Services-Domänencontroller, den Zugriff auf Anwendungsendpunkte, die von anderen Zielzonen verfügbar gemacht werden, oder für den Zugriff auf Protokollierungs- oder Sicherungsfunktionen.
Hinweis
Die Kommunikation zwischen dem Client und den Active Directory Domain Services (ADDS)-Domänencontrollern (DCs) für NAT wurde getestet und wird unterstützt. Die DC-zu-DC-Kommunikation wurde nicht getestet und wird nicht unterstützt, wie weiter unten in der Beschreibung der Supportgrenzen für Active Directory für NAT aufgeführt ist.
Wenn Dienste Verbindungen in nicht routingfähigen virtuellen Spoke-Netzwerken initiieren, müssen Sie SNAT (Source NAT) für Verbindungen hinter einer routingfähigen IP-Adresse implementieren. Zur Implementierung von SNAT stellen Sie ein NAT-fähiges Gerät im routingfähigen virtuellen Spoke-Netzwerk bereit. Jede Zielzone führt ein dediziertes virtuelles Netzwerkgerät (NVA) für die Netzwerkadressenübersetzung (NAT) aus. Es gibt zwei Optionen für die Implementierung von SNAT in einer Zielzone: Azure Firewall oder NVAs von Drittanbietern. In beiden Fällen müssen alle Subnetze im nicht routingfähigen Spoke einer benutzerdefinierten Routingtabelle zugeordnet werden. Wie in der folgenden Abbildung dargestellt, leitet die Routingtabelle Datenverkehr an Ziele außerhalb der Zielzone an das SNAT-Gerät weiter. Azure NAT Gateway unterstützt SNAT nicht für Datenverkehr, der für einen privaten IP-Adressraum (z. B. den RFC 1918-Adressraum) bestimmt ist.
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
Implementieren von SNAT über Azure Firewall
Azure Firewall:
- Bietet Hochverfügbarkeit.
- Bietet native Skalierbarkeit und drei verschiedene SKUs. SNAT ist keine ressourcenintensive Aufgabe, erwägen Sie daher zunächst die Basis-SKU. Für Zielzonen mit einem hohen Bedarf an ausgehendem Datenverkehr aus dem nicht routingfähigen Adressraum sollten Sie die Standard-SKU verwenden.
- Führt SNAT für den Datenverkehr hinter den privaten IP-Adressen einer seiner Instanzen durch. Jede Instanz kann alle nicht privilegierten Ports verwenden.
Das folgende Diagramm zeigt das Layout der Zielzone für die Implementierung von SNAT in einer Hub-and-Spoke-Netzwerktopologie unter Verwendung von Azure Firewall.
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
Sie müssen alle Subnetze im nicht routingfähigen Spoke einer benutzerdefinierten Routingtabelle zuordnen, um Datenverkehr an Ziele außerhalb der Zielzone an Azure Firewall zu senden.
Das folgende Diagramm zeigt das Layout der Zielzone zur Implementierung von SNAT in einem Virtual WAN-basierten Hub-and-Spoke-Netzwerk unter Verwendung von Azure Firewall.
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
Sie müssen alle Subnetze im nicht routingfähigen Spoke bzw. alle Spokes ohne Verbindung mit Virtual WAN einer benutzerdefinierten Routingtabelle zuordnen, um Datenverkehr an Ziele außerhalb der Zielzone an Azure Firewall zu senden.
Bei beiden Layouts müssen Sie in jedem routingfähigen Spoke der Zielzone für die Azure Firewall-Bereitstellung die Option SNAT ausführen auf Immer festlegen, um Ressourcen im nicht routingfähigen Spoke Zugriff auf routingfähige IP-Adressen außerhalb ihrer Zielzone zu ermöglichen. Anweisungen zum Konfigurieren von Azure Firewall für die SNAT-Implementierung für alle eingehenden Verbindungen finden Sie in der öffentlichen Dokumentation. Der folgende Screenshot zeigt die erforderliche Konfiguration für die Verwendung von Azure Firewall als NAT-Gerät für Verbindungen, die von Ressourcen in nicht routingfähigen virtuellen Spoke-Netzwerken initiiert werden.
Implementieren von SNAT über NVAs von Drittanbietern
Drittanbieter-NVAs mit NAT-Funktionen stehen im Azure Marketplace zur Verfügung. Sie bieten:
- Präzise Kontrolle über das Ab- und Aufskalieren.
- Präzise Steuerung des NAT-Pools.
- Benutzerdefinierte NAT-Richtlinien, z. B. die Verwendung unterschiedlicher NAT-Adressen in Abhängigkeit von den Eigenschaften der eingehenden Verbindung, etwa der Quell- oder Ziel-IP-Adresse.
Beachten Sie die folgenden Empfehlungen:
- Stellen Sie Cluster mit mindestens zwei NVAs bereit, um Hochverfügbarkeit zu gewährleisten. Verwenden Sie einen Azure-Lastenausgleich, um eingehende Verbindungen vom nicht routingfähigen virtuellen Spoke-Netzwerk auf die NVAs zu verteilen. Es wird eine Lastenausgleichsregel für Hochverfügbarkeitsports benötigt, da der Cluster SNAT für alle Verbindungen implementiert, die die Zielzone verlassen. Azure Load Balancer Standard unterstützt Lastenausgleichsregeln für Hochverfügbarkeitsports.
- Der Azure SDN-Stack unterstützt NVAs mit Einzel- oder Dualverbindung. NVAs mit Einzelverbindung werden bevorzugt, da sie den Adressraumverbrauch in den routingfähigen virtuellen Spoke-Netzwerken verringern.
Das folgende Diagramm zeigt das Layout der Zielzone zur Implementierung von SNAT in einer Hub-and-Spoke-Netzwerktopologie unter Verwendung von NVAs von Drittanbietern.
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
Das folgende Diagramm zeigt das Layout der Zielzone zur Implementierung von SNAT in einer Virtual WAN-basierten Hub-and-Spoke-Netzwerktopologie unter Verwendung von NVAs von Drittanbietern.
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
Für beide Layouts mit NVAs von Drittanbietern müssen Sie mehrere Instanzen hinter einem Azure-Lastenausgleich bereitstellen, um eine hohe Verfügbarkeit zu gewährleisten. Es wird die Standard-SKU von Azure Load Balancer benötigt.
Methode 2: Azure Private Link-Dienste
Private Link bietet Zugriff auf Anwendungen, die in einem virtuellen Netzwerk bereitgestellt werden, das nicht mit Ihrem virtuellen Netzwerk verbunden ist. Im virtuellen Netzwerk auf der Server- oder Anwendungsseite wird ein Private Link-Dienst bereitgestellt und einem Anwendungsendpunkt zugeordnet, der an der Front-End-IP-Adresse eines internen Azure-Lastenausgleichs mit SKU-Standard verfügbar gemacht wird. Im clientseitigen virtuellen Netzwerk wird eine private Endpunktressource bereitgestellt und dem Private Link-Dienst zugeordnet. Der private Endpunkt macht den Anwendungsendpunkt in Ihren virtuellen Netzwerken verfügbar. Private Link stellt die Logik zum Tunneln und für NAT bereit, um den Datenverkehr zwischen der Client- und der Serverseite zu routen. Weitere Informationen finden Sie unter Was ist Azure Private Link?.
Private Link erfordert keine Layer-3-Verbindung zwischen dem virtuellen Netzwerk auf der Clientseite und dem virtuellen Netzwerk auf der Serverseite. Die beiden virtuellen Netzwerke können überlappende IP-Adressräume aufweisen. Private Link ermöglicht die Bereitstellung von Anwendungen in dedizierten, isolierten virtuellen Netzwerken, die alle denselben nicht routingfähigen Adressraum nutzen. Die Anwendungen werden als Private Link-Dienste im Unternehmensnetzwerk verfügbar gemacht, das einen routingfähigen Adressraum verwendet. Im Kontext der Azure-Zielzonenarchitektur umfasst die resultierende Zielzonentopologie folgende Elemente:
- Ein isoliertes virtuelles Netzwerk, das die gesamte Anwendung und den Private Link-Dienst hostet, der den Endpunkten der Anwendung zugeordnet ist. Das Anwendungsteam definiert den Adressraum des virtuellen Netzwerks.
- Ein virtuelles Spoke-Netzwerk mit einem routingfähigen Adressraum, der den privaten Endpunkt hostet, der dem Private Link-Dienst zugeordnet ist. Das virtuelle Spoke-Netzwerk wird mittels Peering direkt mit dem regionalen Hub verbunden.
Das folgende Diagramm zeigt die Topologie der Zielzone mit aktiviertem Private Link-Dienst.
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
Verwenden eines Private Link-Diensts für ausgehende Abhängigkeiten
Wenn Sie Anwendungen in isolierten virtuellen Spoke-Netzwerken bereitstellen, verwenden Sie einen Private Link-Dienst für ausgehende Abhängigkeiten. Definieren Sie private Endpunkte im isolierten virtuellen Spoke-Netzwerk, und ordnen Sie sie einem Private Link-Dienst in routingfähigen virtuellen Netzwerken zu. Das folgende Diagramm zeigt den konzeptionellen Ansatz.
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
In realen, groß angelegten Implementierungen ist die Private Link-Methode möglicherweise nicht anwendbar:
- Wenn die im isolierten virtuellen Netzwerk bereitgestellten Anwendungen mehrere ausgehende Abhängigkeiten aufweisen. Wenn Sie einen Private Link-Dienst und einen privaten Endpunkt für jede ausgehende Abhängigkeit bereitstellen, erhöht dies die Komplexität und den Verwaltungsaufwand.
- Wenn die ausgehende Abhängigkeit Endpunkte im routingfähigen Netzwerk umfasst, die nicht in einen Azure Load Balancer-Back-End-Pool aufgenommen werden können, ist Private Link nicht anwendbar.
Um diese beiden Einschränkungen zu überwinden, stellen Sie eine Proxy/NAT-Lösung im routingfähigen Spoke bereit und machen ihn mit Private Link vom isolierten virtuellen Netzwerk aus zugänglich.
Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.
Verwenden Sie einen einzelnen privaten Endpunkt oder Private Link-Dienst, um eine Proxy/NAT-Lösung verfügbar zu machen, die im routingfähigen Netzwerk bereitgestellt wird. Regeln für die Port- und die Adressübersetzung werden auf den NVAs definiert. Diese Regeln ermöglichen die Verwendung eines einzelnen privaten Endpunkts im isolierten virtuellen Netzwerk für den Zugriff auf mehrere Abhängigkeiten im routingfähigen Netzwerk.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautoren:
- Federico Guerrini | EMEA Technical Lead
- Khush Kaviraj | Cloud Solution Architect
- Jack Tracey | Senior Cloud Solution Architect
Andere Mitwirkende:
- Jodi Martis | Technical Writer
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
Nächste Schritte
- Bereitstellen von Azure Firewall in einem virtuellen Netzwerk
- Konfigurieren von SNAT in Azure Firewall
- Unterstützte IP-Adressen in einem virtuellen Azure-Netzwerk
- Azure Private Link
- Azure-Lastenausgleich
- Peering in virtuellen Netzwerken