Verhindern der Erschöpfung von IPv4-Adressen in Azure

Unternehmensnetzwerke verwenden in der Regel Adressräume aus den privaten IPv4-Adressbereichen, die durch Request for Comments (RFC) 1918 definiert sind, wie 10.0.0.0/8, 172.16.0.0/12und 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 Adressverwaltungspraktiken, die einfache Routingkonfigurationen und agile Prozesse für die IP-Adresszuweisung priorisieren. Sie priorisieren häufig keine effiziente Verwendung des IPv4-Adressraums.

In der Cloud sind große Netzwerke einfach zu erstellen. Einige gängige Architekturmuster wie Microservices oder Containerisierung können zu einer erhöhten IPv4-Adressnutzung führen. Daher ist es wichtig, konservativere Adressverwaltungsmethoden zu übernehmen und IPv4-Adressen als begrenzte Ressource zu behandeln.

Hinweis

Es wird empfohlen, die von RFC 1918 definierten Adressblöcke in Ihren virtuellen Azure-Netzwerken zu verwenden. Weitere Informationen finden Sie unter Adressbereiche für virtuelle Netzwerke.

In diesem Artikel werden zwei Methoden beschrieben, um den IPv4-Adressraumverbrauch zu minimieren, wenn Sie große Netzwerke in Azure erstellen. Die Methoden basieren auf Netzwerktopologien, die dieselben IPv4-Adressblöcke in mehreren virtuellen Netzwerken oder Zielzonen wiederverwenden.

• Methode 1: Verwenden Sie IPv4-Subnetz-Peering , um ein oder mehrere Subnetze vom Peering zwischen dem virtuellen Netzwerk der Zielzone und dem virtuellen Hubnetzwerk auszuschließen. Sie können Subnetzen, die von der Peering-Beziehung ausgeschlossen sind, in allen Landing-Zonen die gleichen nicht-routalen IP-Adressbereiche zuweisen. Diese IP-Adressbereiche können nicht mit anderen routingfähigen IP-Adressbereichen überlappen.

• Methode 2: Stellen Sie Anwendungen in isolierten virtuellen Netzwerken bereit, die nicht mit den virtuellen Netzwerken der Zielzonen verbunden sind. Ordnen Sie ihre Endpunkte azure Private Link-Diensten zu. Erstellen Sie in den virtuellen Netzwerken der Landezonen private Endpunkte, die den Private Link-Diensten zugeordnet sind. Die isolierten virtuellen Netzwerke können jeden IPv4-Adressraum verwenden, auch wenn sie sich mit dem routingfähigen Adressraum des Unternehmensnetzwerks überlappt.

Methode 1 funktioniert am besten in herkömmlichen Unternehmensumgebungen, in denen mehrere Systeme und Anwendungen voneinander abhängen. Methode 2 funktioniert am besten in lose gekoppelten Umgebungen, in denen Anwendungen unabhängig arbeiten.

Ausrichtung der Azure-Zielzone

Die Empfehlungen in diesem Artikel gelten für Netzwerktopologien, die auf der Azure-Zielzonenarchitektur basieren:

• Jede Region, in der Azure-Ressourcen gehostet werden, verfügt über ein Hub-and-Spoke-Netzwerk.

• Hub-and-Spoke-Netzwerke in verschiedenen Regionen verbinden sich über ein globales virtuelles Netzwerk-Peering.

• Hub-and-Spoke-Netzwerke stellen über Azure ExpressRoute-Schaltkreise oder Standort-zu-Standort-VPNs eine Verbindung mit lokalen Standorten her.

In der Azure-Zielzonenarchitektur wird jede Anwendung in einem eigenen virtuellen Speichennetzwerk ausgeführt. Jedes virtuelle Speichennetzwerk verwendet einen eindeutigen IPv4-Adressraum im gesamten Unternehmensnetzwerk.

Alle Ressourcen in einem Landebereich können wie folgt verbunden werden:

• Verwenden Sie die IP-Adresse, um Verbindungen mit anderen Ressourcen im Unternehmensnetzwerk zu initiieren.

• Erhalten Sie direkte Verbindungen vom gesamten Unternehmensnetzwerk über deren IP-Adressen

Ressourcen benötigen jedoch nicht immer eine Erreichbarkeit vom gesamten Unternehmensnetzwerk. Beispielsweise muss in einer Zielzone, die eine Webanwendung mit drei Ebenen enthält, z. B. http-Front-End, Geschäftslogik und Datenebene, nur das HTTP-Front-End von außerhalb der Zielzone erreichbar sein. Die anderen Ebenen müssen sich miteinander und dem Front-End verbinden, müssen jedoch keine Verbindungen von Clients akzeptieren. In diesem Beispiel wird empfohlen, den IPv4-Adressverbrauch zu minimieren, indem Sie jeder Zielzone die folgenden Komponenten zuweisen:

• Ein Adressraum, der im gesamten Unternehmensnetzwerk eindeutig ist. Nur Ressourcen, die von außerhalb ihrer Zielzone erreichbar sein müssen, verwenden diesen Adressraum. Dieser Artikel bezieht sich auf diesen Adressraum als routbarer Adressraum der Landungszone.

• Ein interner Adressraum für Ressourcen, die nur mit anderen Ressourcen innerhalb ihrer eigenen Landezone kommunizieren müssen. Dieser Adressraum erfordert keine direkte Reichweite aus dem Unternehmensnetzwerk. In diesem Artikel wird dieser Adressraum als nicht routingfähiger Adressraum der Landing-Zone bezeichnet.

In den folgenden Abschnitten bezieht sich die Front-End-Komponente auf eine Anwendungskomponente, die über das gesamte Unternehmensnetzwerk erreichbar sein muss. Back-End-Komponente bezieht sich auf eine Anwendungskomponente, die keine Endpunkte im Unternehmensnetzwerk verfügbar macht und nur innerhalb ihrer eigenen Landezone erreichbar sein muss.

Methode 1: Nicht routingfähige Subnetze in virtuellen Netzwerken mit Spokes

Sie können IPv4-Subnetz-Peering verwenden, um eine Peeringbeziehung zwischen zwei virtuellen Netzwerken auf bestimmte Subnetze einzuschränken. Nur Subnetze, die in der Peeringkonfiguration enthalten sind, können den Datenverkehr aneinander weiterleiten. Subnetze, die von der Peeringkonfiguration ausgeschlossen sind, bleiben unsichtbar und können vom virtuellen Peernetzwerk nicht erreichbar sein.

Wenn Sie in einer Hub-and-Spoke-Topologie ein oder mehrere Subnetze in den einzelnen Speichen aus der Peeringkonfiguration ausschließen, bleiben diese Subnetze unsichtbar und nicht erreichbar vom Hub und von allen Remotenetzwerken, die über andere Peerings, ExpressRoute-Verbindungen oder VPN-Verbindungen mit dem Hub verbunden sind. Daher können Sie denselben Adressbereich allen Subnetzen zuweisen, die von der Peeringkonfiguration in allen virtuellen Speichennetzwerken ausgeschlossen sind. Dieser Bereich muss als nicht routbar definiert werden und darf an keiner anderen Stelle im Unternehmensnetzwerk verwendet werden.

Das folgende Diagramm enthält die folgenden Komponenten:

• Der Bereich 10.57.0.0/16 dient als nichtroutales Adressraum.

• Das virtuelle Hubnetzwerk und jedes virtuelle Landungszone-Netzwerk verwenden eindeutige routingfähige IP-Adressbereiche (10.0.0.0/24, 10.1.0.0/24und 10.2.0.0/24).

• Jedes virtuelle Netzwerk der Landing-Zone Spoke enthält auch ein oder mehrere nicht routingfähige Subnetze innerhalb des nicht routingfähigen Bereichs 10.57.0.0/16. Der Adressraum eines virtuellen Azure-Netzwerks kann mehrere IP-Adressbereiche enthalten.

• Diese Subnetze werden von der Peeringbeziehung mit dem Hub ausgeschlossen. Daher können nicht routbare Subnetze in verschiedenen Spokes der Landungszonen die gleichen oder überlappenden Adressbereiche innerhalb 10.57.0.0/16aufweisen.

Dieses Diagramm enthält einen Hub und zwei Landing-Zone Spokes in separaten Zonen. Der Hub enthält drei routingfähige Subnetze. Jede Landezonen-Speiche enthält zwei routbare Subnetze und zwei nicht routbare Subnetze. Der Hub ist über Subnetz-Peering mit jeder Landezone verbunden. Nur die routingfähigen Subnetze im Hub und in den Spokes werden in das Peering einbezogen.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Bei diesem Ansatz bleibt die vollständige Konnektivität innerhalb des virtuellen Netzwerks der Spoke einer Landing Zone erhalten. Alle Ressourcen im gleichen virtuellen Netzwerk der Spoke können sich miteinander verbinden, unabhängig davon, ob sie sich in routingfähigen oder nicht routingfähigen Subnetzen befinden. Allerdings können nur Ressourcen in routingfähigen Subnetzen eine Verbindung mit Ressourcen außerhalb ihrer eigenen Zielzone herstellen.

Bereitstellen von Anwendungen in Landing-Zonen

Wenn Sie Subnetz-Peering zum Erstellen von Landungszonen mit nicht veralteten Subnetzen verwenden, können Sie verschiedene Muster anwenden, um die Front-End- und Back-End-Komponenten einer Anwendung über routingfähige und nicht veraltete Subnetze zu verteilen. Die folgenden Überlegungen gelten sowohl für neu erstellte Anwendungen als auch für Anwendungen, die aus herkömmlichen Landezonen migriert wurden, die einen einzigen, vollständig routingfähigen Adressraum verwenden.

• Anwendungen, die über Layer-7-Anwendungsbereitstellungscontroller verfügbar gemacht werden: Zu diesen Anwendungsübermittlungscontrollern gehören Azure Application Gateway oder nicht von Microsoft stammende virtuelle Appliances (NVAs). Nur der Endpunkt des Anwendungsübermittlungscontrollers muss von Clients außerhalb der Zielzone erreichbar sein. Daher ist der Anwendungsbereitstellungscontroller die einzige Front-End-Komponente, die sich in einem routingfähigen Subnetz befinden muss.

• Anwendungen, die über einen Azure-Lastenausgleich verfügbar gemacht werden: Wenn die Anwendung einen internen Azure-Lastenausgleich verwendet, müssen sich die virtuellen Computer im Back-End-Pool des Lastenausgleichs in einem routingfähigen Subnetz befinden. Sie können alle anderen Komponenten in nicht routbaren Subnetzen bereitstellen.

Das folgende Diagramm zeigt die folgenden Muster:

• Zielzone A hostt eine dreischichtige Webanwendung, die über einen Anwendungsübermittlungscontroller verfügbar gemacht wird, der die einzige Komponente im routingfähigen Subnetz ist.

• Die Zielzone B hostt eine dreischichtige Anwendung, die über einen internen Azure-Lastenausgleich verfügbar gemacht wird.

Dieses Diagramm enthält einen Hub und zwei Landing-Zone Spokes in separaten Zonen. Der Hub enthält drei routingfähige Subnetze. Die Landing-Zone Eine Spoke enthält einen Application Delivery Controller in einem routbaren Subnetz und ein HTTP Frontend, eine Geschäftslogik und ein Tier in separaten, nicht routbaren Subnetzen. Die Landungszone "B Spoke" enthält ein TCP/IP-Front-End in einem routingfähigen Subnetz sowie Geschäftslogik und eine Datenebene in separaten, nicht routingfähigen Subnetzen. Der Hub ist über Subnet Peering mit den routbaren Subnetzen in jeder Spoke verbunden.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Ausgehende Abhängigkeiten

Die Back-End-Komponenten einer Anwendung müssen keine eingehenden Verbindungen aus dem Unternehmensnetzwerk empfangen. Möglicherweise müssen sie jedoch Verbindungen mit Endpunkten außerhalb ihrer Zielzone initiieren. Typische Beispiele sind die DNS-Auflösung (Domain Name System), die Interaktion mit Active Directory Domain Services (AD DS)-Domänencontrollern und der Zugriff auf Anwendungen in anderen Zielzonen oder gemeinsam genutzten Diensten wie Protokollverwaltung oder Sicherungssystemen.

Wenn Ressourcen in nicht routbaren Subnetzen Verbindungen zu Endpunkten außerhalb ihrer Zielzone initiieren müssen, müssen diese Verbindungen Source NAT (SNAT) hinter einer routingfähigen IP-Adresse verwenden. Daher müssen Sie eine NAT-fähige NVA in einem routingfähigen Subnetz in jeder Landungszone bereitstellen. Im folgenden Diagramm wird diese Konfiguration veranschaulicht.

Dieses Diagramm enthält einen Hub und zwei Landing-Zone Spokes in separaten Zonen. Der Hub enthält drei routingfähige Subnetze. Die Spoke der Landing-Zone A enthält einen Application Delivery Controller und NAT in separaten routingfähigen Subnetzen. Sie enthält außerdem eine HTTP-Front-End-, Geschäftslogik- und Datenebene in separaten, nicht routingfähigen Subnetzen. Der Anwendungsübermittlungscontroller verweist auf drei Komponenten im HTTP-Front-End-Subnetz. Die Verbindung von einer Komponente durchläuft die Firewall im Hub über SNAT. Die Spoke der Landing-Zone B enthält ein TCP/IP Frontend und NAT in separaten routingfähigen Subnetzen. Sie enthält auch Geschäftslogik und eine Datenebene in separaten, nicht routingfähigen Subnetzen. Die Verbindung von einer Komponente im Subnetz der Geschäftslogik geht über SNAT durch die Firewall im Hub. Der Hub ist mit jeder Landing-Zone Spoke verbunden.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Nicht routingfähige Subnetze müssen eine benutzerdefinierte Routentabelle verwenden, die den gesamten Datenverkehr außerhalb der Zielzone an den NAT-fähigen NVA weiterleitet. Im vorherigen Diagramm ist der 10.57.0.0/16 Bereich nicht routbar, während andere Bereiche innerhalb 10.0.0.0/8 routbar sind. Die benutzerdefinierte Routentabelle für jedes nicht routbare Subnetz muss die folgende benutzerdefinierte Route (UDR) enthalten.

Bestimmungsort	Typ des nächsten Sprungs	IP-Adresse des nächsten Hops
10.0.0.0/8	VirtualNetworkAppliance	<Spoke-NAT-fähige NVA-IP-Adresse>

Die Systemroutentabelle des virtuellen Netzwerks enthält bereits eine Systemroute für Ziele im nicht-routbaren Bereich 10.57.0.0/16. Sie müssen UDRs nicht für den Datenverkehr innerhalb dieses Bereichs definieren.

Routingfähige Subnetze, einschließlich des Subnetzes, das die NAT-fähige NVA hostet, müssen eine benutzerdefinierte Routentabelle verwenden, die Datenverkehr außerhalb der Zielzone weiterleitet, in der Regel an NVAs im virtuellen Hubnetzwerk. Diese NVAs routen den Datenverkehr zwischen den Spokes. Diese Hub-NVAs führen keine NAT-Vorgänge aus. Im vorherigen Diagramm muss die benutzerdefinierte Routentabelle für jedes routingfähige Subnetz die folgenden UDRs enthalten.

Bestimmungsort	Typ des nächsten Sprungs	IP-Adresse des nächsten Hops
10.0.0.0/8	VirtualNetworkAppliance	<IP-Adresse des Hubrouters/firewalls>
10.0.0.0/24	VirtualNetworkAppliance	<IP-Adresse des Hubrouters/firewalls>

Der zweite UDR mit Ziel 10.0.0.0/24 stellt sicher, dass Verbindungen mit Ressourcen im virtuellen Hubnetzwerk über die Hubfirewall weitergeleitet werden. Einige Anwendungen erfordern möglicherweise mehr UDRs. Wenn virtuelle Computer in der Zielzone Internetzugriff über NVAs benötigen, die in der Regel im Hub gehostet werden, müssen Sie auch eine Standardroute von 0.0.0.0/0definieren.

Hinweis

Die Kommunikation von Client zu AD DS Domänencontroller über NAT wird unterstützt. Die Domänencontroller-zu-Domänencontroller-Kommunikation über NAT wurde nicht getestet und wird nicht unterstützt. Weitere Informationen finden Sie unter Supportgrenzen für Windows Server Active Directory über NAT. Es wird empfohlen, Windows Server Active Directory-Domänencontroller für routingfähige Subnetze bereitzustellen.

Sie können entweder Azure Firewall oder nicht von Microsoft stammende NVAs als NAT-fähige Geräte verwenden. In den folgenden Abschnitten werden beide Optionen behandelt. Sie können Das Azure NAT-Gateway nicht verwenden, da es SNAT nur für internetgebundenen Datenverkehr unterstützt.

Implementieren von SNAT über Azure Firewall

Wenn Sie eine geringe Komplexität und minimale Verwaltung priorisieren müssen, bietet Azure Firewall die beste Lösung zum Implementieren von SNAT für Verbindungen, die aus nicht veralteten Subnetzen stammen. Azure Firewall bietet die folgenden Vorteile:

• Vollständig verwalteter Lebenszyklus
• Integrierte Hochverfügbarkeit
• Automatische Skalierung basierend auf dem Datenverkehrsvolumen

Berücksichtigen Sie bei der Verwendung der Azure Firewall die folgenden Faktoren:

• Stellen Sie Azure Firewall in einem eigenen reservierten Subnetz namens AzureFirewallSubnet bereit, das einen routingfähigen Adressraum verwenden muss.

• Einige Azure Firewall-SKUs oder -Konfigurationen erfordern möglicherweise ein zweites reserviertes Subnetz für die Firewallverwaltung. Für das Verwaltungssubnetz ist kein routingfähiger Adressraum erforderlich.

• Azure Firewall verfügt über drei verschiedene SKUs. SNAT ist nicht ressourcenintensiv, beginnen Sie also mit der Standard-SKU. Berücksichtigen Sie bei Landezonen, die große Mengen ausgehenden Netzwerkverkehrs aus nicht routbaren Subnetzen generieren, die Standard-SKU.

• Konfigurieren Sie Azure Firewall mit der Option "SNAT ausführen ", die auf "Immer" festgelegt ist. Jede Instanz verwendet ihre nicht privilegierten Ports für SNAT. Um Azure Firewall so zu konfigurieren, dass SNAT für alle empfangenen Verbindungen implementiert wird, führen Sie die SNAT-Konfigurationsschritte aus.

• Ordnen Sie alle nicht routbaren Subnetze einer benutzerdefinierten Routentabelle zu, die allen Verkehr außerhalb der Landingzone an die private IP-Adresse der Firewall weiterleitet.

Das folgende Diagramm zeigt ein Hub-and-Spoke-Netzwerk, in dem jede Zweigstelle die Azure Firewall verwendet, um SNAT für Verbindungen von nicht routbaren Subnetzen bereitzustellen.

Dieses Diagramm enthält einen Hub und zwei Landing-Zone Spokes in separaten Zonen. Der Hub enthält drei routingfähige Subnetze. Die Spoke der Landing-Zone A enthält einen Application Delivery Controller und eine Firewall in separaten routbaren Subnetzen. Sie enthält außerdem eine HTTP-Front-End-, Geschäftslogik- und Datenebene in separaten, nicht routingfähigen Subnetzen. Der Anwendungsübermittlungscontroller verweist auf drei Komponenten im HTTP-Front-End-Subnetz. Die Verbindung von einer Komponente durchläuft die Firewall im Hub über SNAT. Die Spoke der Landing-Zone B enthält ein TCP/IP Frontend und eine Firewall in separaten routingfähigen Subnetzen. Sie enthält auch Geschäftslogik und eine Datenebene in separaten, nicht routingfähigen Subnetzen. Die Verbindung von einer Komponente im Subnetz der Geschäftslogik geht über SNAT durch die Firewall im Hub. Der Hub ist mit jeder Landing-Zone Spoke verbunden.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Implementieren von SNAT über nicht von Microsoft stammende NVAs

Sie können nicht von Microsoft stammende NVAs mit NAT-Funktionen in Azure Marketplace finden. Erwägen Sie die Verwendung eines nicht von Microsoft stammenden NVA, wenn Ihre Anforderungen die Unterstützung der Azure-Firewall überschreiten. Beispielsweise benötigen Sie möglicherweise die folgenden Funktionen:

• Granulare Kontrolle über den NAT-Pool

• Benutzerdefinierte NAT-Richtlinien, z. B. müssen Sie möglicherweise unterschiedliche NAT-Adressen für unterschiedliche Verbindungen verwenden.

• Granulare Kontrolle über das horizontale Skalieren und Einbinden

Berücksichtigen Sie bei Verwendung von nicht von Microsoft stammenden NVAs die folgenden Faktoren:

• Stellen Sie einen Cluster mit mindestens zwei NVAs bereit, um eine hohe Verfügbarkeit sicherzustellen.

• Verwenden Sie einen Standard SKU Azure Load-Balancer, um die Distribution von Verbindungen aus dem nicht-routalen virtuellen Netzwerk der Spoke auf die NVAs zu verteilen. Alle Verbindungen müssen SNAT unabhängig vom Zielport verwenden, daher sollten Sie Hochverfügbarkeits-Lastenausgleichsregeln verwenden, die auch als Regeln für den Lastenausgleich für alle Ports bezeichnet werden.

• Wählen Sie zwischen Einzelarm- und Dual-Arm-Konfigurationen für NAT-fähige NVAs aus. Einzelarmkonfigurationen sind einfacher und werden im Allgemeinen empfohlen.

Das folgende Diagramm zeigt jetzt die Implementierung von SNAT in einer Hub-and-Spoke-Netzwerktopologie mithilfe von nicht von Microsoft stammenden NVAs.

Dieses Diagramm enthält einen Hub und zwei Landing-Zone Spokes in separaten Zonen. Der Hub enthält drei routingfähige Subnetze. Die Landing-Zone A Spoke enthält einen Application Delivery Controller in einem routingfähigen Subnetz und zwei NAT-Instanzen in einem routingfähigen Subnetz. Sie enthält außerdem eine HTTP-Front-End-, Geschäftslogik- und Datenebene in separaten, nicht routingfähigen Subnetzen. Der Anwendungsübermittlungscontroller verweist auf drei Komponenten im HTTP-Front-End-Subnetz. Die Verbindung von einer Komponente durchläuft eine NAT-Instanz und dann die Firewall im Hub über SNAT. Die Landing-Zone B Spoke enthält ein TCP/IP Frontend in einem routingfähigen Subnetz und zwei NAT-Instanzen in einem routingfähigen Subnetz. Sie enthält auch Geschäftslogik und eine Datenebene in separaten, nicht routingfähigen Subnetzen. Die Verbindung von einer Komponente im Geschäftslogik-Subnetz durchläuft eine NAT-Instanz und dann die Firewall im Hub über SNAT. Der Hub ist mit jeder Landing-Zone Spoke verbunden.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Verwenden Sie Methode 1 mit Azure Virtual WAN

Azure Virtual WAN unterstützt keine Subnetz-Peering. Sie können also keine virtuellen Netzwerke der Landing-Zone erstellen, die nicht-routbare Subnetze in Virtual WAN-basierten Hub-and-Spoke-Netzwerken enthalten. Sie können jedoch weiterhin das Grundlegende Prinzip der Methode 1 anwenden, indem Sie zwei virtuelle Peer-Netzwerke für jede Landungszone verwenden.

• Weisen Sie dem ersten virtuellen Netzwerk einen routingfähigen Adressraum zu, und verbinden Sie ihn mit dem virtuellen WAN-Hub.

• Weisen Sie dem zweiten virtuellen Netzwerk einen nicht routbaren Adressraum zu und verbinden Sie es mit dem routingfähigen virtuellen Netzwerk.

Das folgende Diagramm zeigt die resultierende Topologie.

Dieses Diagramm enthält einen virtuellen WAN-Hub und zwei Landezonen. Die Landungszone A enthält eine routingfähige Speiche und eine nicht routingfähige Speiche, die über virtuelles Netzwerk-Peering verbunden sind. Die routingfähige Spoke enthält einen Application Delivery Controller in einem routingfähigen Subnetz. Die nicht routbare Speiche enthält ein HTTP-Front-End, Geschäftslogik und eine Datenebene in separaten nicht routbaren Subnetzen. Der Anwendungsübermittlungscontroller stellt eine Verbindung mit drei Komponenten im HTTP-Front-End-Subnetz bereit. Landing-Zone B enthält eine Landing-Zone mit einer routbaren Spoke und eine Landing-Zone mit einer nicht routbaren Spoke, die über ein virtuelles Netzwerk-Peering verbunden sind. Die routingfähigen Speichen enthalten ein TCP/IP-Frontend in einem routbaren Subnetz. Die nicht routingfähige Speichen enthalten Geschäftslogik und eine Datenebene in separaten, nicht routingfähigen Subnetzen. Der Virtual WAN Hub ist mit jeder routingfähigen Spoke der Landing Zone verbunden.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Dieser Ansatz beschränkt die Konnektivität nicht innerhalb einer Zielzone. Die beiden virtuellen Netzwerke in der Landing-Zone werden direkt gepeert, so dass alle Ressourcen miteinander verbunden werden können, unabhängig davon, ob sie sich in einem routingfähigen oder nicht routingfähigen virtuellen Netzwerk befinden. Allerdings können nur Ressourcen im routingfähigen virtuellen Netzwerk eine Verbindung mit Ressourcen außerhalb der Zielzone herstellen.

Aus Routingperspektive gibt es keinen Unterschied zwischen den folgenden Konfigurationen:

• Routingfähige und nicht routingfähige Subnetze im selben virtuellen Netzwerk (im vorherigen Abschnitt für herkömmliche Hub-and-Spoke-Netzwerke beschrieben)

• Direkt gepeerte virtuelle Netzwerke (in diesem Abschnitt für Hub-and-Spoke-Netzwerke auf der Basis von Virtual WAN beschrieben)

Daher gelten in virtuellen WAN-basierten Netzwerken die folgenden Anleitungen:

• Sie können Anwendungskomponenten über routingfähige und nicht routingfähige Subnetze verteilen, indem Sie die gleichen Überlegungen verwenden, die in früheren Abschnitten beschrieben sind.

• Sie können ausgehende Abhängigkeiten mit NAT-fähigen NVAs in routingfähigen Subnetzen verwalten.

Methode 2: Private Link-Dienste

Mit privatem Link können Clients in einem virtuellen Netzwerk Anwendungen in einem anderen virtuellen Netzwerk nutzen, ohne Layer-3-Konnektivität zu konfigurieren, z. B. virtuelles Netzwerk-Peering oder VPN für virtuelle Netzwerke. Die beiden virtuellen Netzwerke können überlappende IP-Adressbereiche verwenden. Azure behandelt transparent die erforderliche NAT-Logik. Diese Methode gilt sowohl für herkömmliche Hub-and-Spoke-Netzwerke als auch für virtuelle WAN-basierte Netzwerke.

Führen Sie die folgenden Schritte aus, um eine Anwendung über private Links verfügbar zu machen:

1. Fügen Sie die Endpunkte der Anwendung dem Back-End-Pool eines internen Azure-Lastenausgleichs mit der Standard-SKU hinzu.

2. Ordnen Sie die Front-End-IP-Adresse des Load-Balancers einer Private-Link-Dienst-Ressource zu.

3. Erstellen Sie auf clientseitiger Seite eine private Endpunktressource , und ordnen Sie sie dem serverseitigen Privaten Link-Dienst zu.

Um die Anwendung zu nutzen, stellen Clients eine Verbindung mit dem privaten Endpunkt her. Azure leitet die Verbindung transparent an die Front-End-IP-Adresse des Load Balancers weiter, die mit dem entsprechenden privaten Link-Dienst verknüpft ist.

Sie können private Links verwenden, um die IPv4-Erschöpfung zu verringern, indem Sie jeder Zielzone zwei virtuelle Netzwerke zuweisen:

• Ein virtuelles Netzwerk, das über einen routingfähigen Adressraum verfügt, der mit dem Unternehmensnetzwerk verbunden ist

• Ein isoliertes virtuelles Netzwerk mit einem willkürlich ausgewählten Adressraum, der sich sogar mit dem Adressraum des Unternehmensnetzwerks überlappen kann

Stellen Sie Anwendungen und die Private Link-Dienste bereit, die ihre Endpunkte in den isolierten virtuellen Netzwerken verfügbar machen. Stellen Sie die privaten Endpunkte bereit, die eine Verbindung mit diesen Diensten herstellen, in den routingfähigen virtuellen Netzwerken.

Das folgende Diagramm zeigt zwei Zielzonen, die einen großen Adressraum 10.0.0.0/16verwenden, der sich mit dem Adressraum des Unternehmensnetzwerks überlappt. Jede Zielzone weist diesen Bereich einem isolierten virtuellen Netzwerk zu. Die Anwendungen werden in den isolierten virtuellen Netzwerken mit Spokes bereitgestellt und mit Private Link-Diensten verknüpft.

Dieses Diagramm enthält einen Hub und zwei Landungszonen. Der Hub enthält drei routingfähige Subnetze. Jede Landing-Zone enthält eine Landing-Zone mit routbarer Spoke und eine Landing-Zone mit isolierter Spoke. Die routingfähige Spoke enthält ein privates Subnetz für Endpunkte und ein routingfähiges Subnetz. Die isolierte Speiche enthält ein Anwendungssubnetz und ein Subnetz des privaten Link-Dienstes, das eine Verbindung mit dem privaten Endpunkt in der routingfähigen Speiche herstellt. Das Anwendungssubnetz verbindet sich mit dem Subnetz des Private-Link-Dienstes. Der Hub ist über virtuelles Netzwerk-Peering mit jeder routingfähigen Spoke der Landing-Zone verbunden.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Clients im Unternehmensnetzwerk, einschließlich Clients in anderen Zielzonen, nutzen die Anwendungen über private Endpunkte, die mit privaten Linkdiensten verknüpft sind. Das folgende Diagramm zeigt, wie diese Verbindungen hergestellt werden.

Dieses Diagramm enthält einen Hub und zwei Landungszonen. Der Hub enthält drei routingfähige Subnetze. Jede Landing-Zone enthält eine Landing-Zone mit routbarer Spoke und eine Landing-Zone mit isolierter Spoke. Die routingfähige Spoke enthält ein privates Subnetz für Endpunkte und ein routingfähiges Subnetz. Die isolierte Speiche enthält ein Anwendungssubnetz und ein Subnetz des privaten Link-Dienstes, das eine Verbindung mit dem privaten Endpunkt in der routingfähigen Speiche herstellt. Das Anwendungssubnetz verbindet sich mit dem Subnetz des Private-Link-Dienstes. Der Hub ist über virtuelles Netzwerk-Peering mit jeder routingfähigen Spoke der Landing-Zone verbunden. Es gibt zwei Flüsse. Ein Fluss fließt vom routingfähigen Subnetz in der Zielzone A, zur Firewall in einem routingfähigen Subnetz im Hub, zum privaten Endpunktsubnetz in der Zielzone B, zum Subnetz des Private-Link-Dienstes in der Zielzone B und schließlich zum Anwendungssubnetz in der Zielzone B. Der zweite Fluss fließt vom routingfähigen Subnetz H3 im Hub zum privaten Endpunktsubnetz in der Zielzone A, zum Subnetz des Private-Link-Dienstes in der Zielzone A und schließlich zum Anwendungssubnetz in der Zielzone A.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Verwenden eines Private Link-Diensts für ausgehende Abhängigkeiten

Anwendungen in isolierten virtuellen Netzwerken können keine Verbindungen mit Endpunkten im Unternehmensnetzwerk initiieren. Daher eignet sich Methode 2 am besten für Szenarien, in denen Anwendungen in verschiedenen Landezonen unabhängig funktionieren und sich nicht auf Systeme im Unternehmensnetzwerk verlassen. Sie können diese Methode jedoch weiterhin anwenden, wenn Anwendungen in isolierten virtuellen Netzwerken auf bestimmte Endpunkte außerhalb ihrer Zielzone zugreifen müssen.

Das folgende Diagramm zeigt, wie ein Privater Link-Dienst die Anwendung im isolierten virtuellen Netzwerk in Der Zielzone A ermöglicht, sowohl einen gemeinsamen Dienst im virtuellen Hubnetzwerk als auch einen Anwendungsendpunkt in Der Zielzone B zu nutzen.

Dieses Diagramm enthält einen Hub und zwei Landungszonen. Der Hub enthält zwei routingfähige Subnetze, ein Subnetz für gemeinsame Dienste und ein Subnetz für privaten Linkdienst. Das Subnetz für gemeinsame Dienste ist mit dem Subnetz des Private Link-Dienstes verbunden. Jede Landing-Zone enthält eine Landing-Zone mit routbarer Spoke und eine Landing-Zone mit isolierter Spoke. Die routingfähige Spoke enthält ein privates Subnetz für Endpunkte und ein routingfähiges Subnetz. Die isolierte Speiche in der Landungszone A enthält ein Anwendungssubnetz, ein Subnetz für Private Link-Dienst, das mit dem privaten Endpunkt in der routbaren Speiche verbunden ist, und ein weiteres privates Endpunktsubnetz. Das Anwendungssubnetz stellt eine Verbindung zu jedem privaten Endpunkt im privaten Endpunkt-Subnetz her. Ein privater Endpunkt (mit der Bezeichnung 1) stellt eine Verbindung mit dem Subnetz des Private Link-Diensts im Hub her. Ein anderer privater Endpunkt (mit der Bezeichnung 2) stellt eine Verbindung mit dem Subnetz für den Privaten Link-Dienst in der Zielzone B her. Das isolierte Spoke in der Zielzone B enthält das Subnetz für den Privaten Link-Dienst und ein Anwendungssubnetz. Jedes Anwendungssubnetz stellt eine Verbindung mit dem Subnetz des Privaten Link-Diensts in derselben Zielzone bereit. Der Hub stellt eine Verbindung zu jeder Landing-Zone mit routingfähiger Spoke her.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

• Federico Guerrini | Senior Cloud Solution Architect, EMEA Technical Lead Azure Networking
• Khush Kaviraj | Cloud-Lösungsarchitekt
• Jack Tracey | Senior Cloud Solution Architect

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

• Konfigurieren von Subnetz-Peering
• Bereitstellen von Azure Firewall in einem virtuellen Netzwerk
• Konfigurieren von SNAT in Azure Firewall
• Unterstützte IP-Adressen in einem virtuellen Azure-Netzwerk
• Privater Link
• Azure-Lastenausgleich
• Virtuelle Netzwerkverknüpfung
• Hub-and-Spoke-Netzwerktopologie

Verwandte Ressourcen

• Netzwerkarchitekturentwurf
• Architekturansätze für Netzwerke in mehrinstanzenfähigen Lösungen