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.

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 die gleichen nicht routingfähigen IP-Adressbereiche subnetzen zuweisen, die von der Peeringbeziehung über alle Zielzonen ausgeschlossen sind. 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. Dieser Artikel bezieht sich auf diesen Adressraum als nicht routingfähiges Adressraum der Zielzone.

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 routingfähig definiert werden und kann nicht an anderer Stelle im Unternehmensnetzwerk verwendet werden.

Das folgende Diagramm enthält die folgenden Komponenten:

• Der Bereich 10.57.0.0/16 dient als nicht routingfähiges 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 Landing-Zone-Spoke-Virtualnetzwerk enthält auch ein oder mehrere nicht routbare Subnetze innerhalb des nicht routbaren 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 Landing-Zone-Spokes die gleichen oder überlappenden Adressbereiche innerhalb von 10.57.0.0/16 enthalten.

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 Speichennetzwerk können sich gegenseitig 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 Zielzonen mit nicht routingfähigen Subnetzen verwenden, können Sie verschiedene Muster anwenden, um die Front-End- und Back-End-Komponenten einer Anwendung über routingfähige und nicht routingfähige 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 routingfähigen 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.

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 routingfähigen Subnetzen Verbindungen mit Endpunkten außerhalb ihrer Zielzone initiieren müssen, müssen diese Verbindungen eine routingfähige IP-Adresse als Ausgangs-NAT 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.

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 routingfähig, während andere Bereiche innerhalb 10.0.0.0/8 routingfähig sind. Die benutzerdefinierte Routentabelle für jedes nicht routingfähige Subnetz muss die folgende benutzerdefinierte Route (UDR) enthalten.

Die Systemroutentabelle des virtuellen Netzwerks enthält bereits eine Systemroute für Ziele im nicht routingfähigen 10.57.0.0/16 Bereich. 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.

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.

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 routingfähigen 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 Landungszonen, die große Mengen ausgehenden Datenverkehrs aus nicht routingfähigen 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 routingfähigen Subnetze einer benutzerdefinierten Routentabelle zu, die den gesamten Datenverkehr außerhalb der Zielzone an die private IP-Adresse der Firewall weiterleitet.

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

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-Lastenausgleich, um Verbindungen aus dem nicht routingfähigen virtuellen Netzwerk an 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.

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 Zielzonennetzwerke erstellen, die nicht routingfähige Subnetze in virtuellen WAN-basierten Hub-and-Spoke-Netzwerken haben. 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 routbaren virtuellen Netzwerk.

Das folgende Diagramm zeigt die resultierende Topologie.

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 Zielzone sind direkt miteinander verbunden, sodass sich alle Ressourcen miteinander verbinden können, unabhängig davon, ob sie sich in einem routbaren oder nicht routbaren 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.

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.

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.

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