IPv6-Hub-and-Spoke-Netzwerktopologie

In diesem Artikel wird beschrieben, wie Sie eine IPv4 Hub-Spoke-Netzwerktopologie auf IPv6 umstellen. Sie stellt die Hub-and-Spoke-Netzwerktopologie als Ausgangspunkt dar und beschreibt die Schritte zum Implementieren der IPv6-Unterstützung.

In einem Hub-and-Spoke-Netzwerk ist das virtuelle Hub-Netzwerk ein zentraler Verbindungspunkt für die virtuellen Spoke-Netzwerke. Die virtuellen Spoke-Netzwerke stellen eine Verbindung mit dem Hub her und können eine Isolation für Anwendungsressourcen bereitstellen. Weitere Informationen finden Sie unter Umstellung auf IPv6.

Architecture

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

1. Öffentliches Internet und standortübergreifendes Netz: Benutzer oder Dienste können über das öffentliche Internet auf Azure-Ressourcen zugreifen. Das standortübergreifende Netzwerk umfasst lokale virtuelle Computer, die eine sichere Verbindung mit dem Azure Netzwerk herstellen. IPv4-Datenverkehr verwendet entweder ein VPN-Gateway oder Azure ExpressRoute. Der IPv6-Datenverkehr verwendet das private IPv6-Peering von ExpressRoute. Azure VPN Gateway kann IPv6-Datenverkehr in anderen Konfigurationen übertragen, aber nicht, wenn er mit einem IPv6-fähigen ExpressRoute-Gateway koexistiert, wie hier gezeigt.

2. Azure Virtual Network Manager: Diese Verwaltungsschicht gruppiert zentral und konfiguriert die virtuellen Netzwerke in der Topologie. Es stellt Konnektivitäts-, Sicherheitsadministrator- und Routingkonfigurationen über Netzwerkgruppen hinweg bereit.

3. Virtuelles Hub-Netzwerk: Der Hub ist der zentrale Punkt der Netzwerktopologie. Die Netzwerkkonfiguration unterstützt sowohl IPv4 als auch IPv6 (dualer Stapel), mit Ausnahme der komponenten, die in den IPv6-Unterstützungseinschränkungen angegeben sind.

   • Azure Bastion stellt Remotedesktop Protocol/Secure Shell (RDP/SSH)-Konnektivität vom Azure Portal zu den virtuellen Computern direkt über Transport Layer Security (TLS) bereit.
   • Azure Firewall prüft und filtert IPv4-Datenverkehr zwischen dem Hub und dem öffentlichen Internet. Die Unterstützung für Dual-Stack-IPv6 ist als Vorschau verfügbar und umfasst nur Netzwerkregeln und den DNS-Proxy, sodass diese Architektur das Firewallsubnetz auf IPv4 beschränkt und die IPv6-Inspektion an den NVA-Pool weiterleitet.
   • Ein Pool mit virtuellen IPv6-fähigen Netzwerkgeräten (NVAs) wird in einem eigenen Hub-Subnetz hinter einem internen Lastenausgleich ausgeführt. Der Pool prüft und filtert IPv6-Datenverkehr zwischen den Speichen, dem öffentlichen Internet und dem standortübergreifenden Netzwerk. Es stellt das IPv6-Äquivalent des Inspektionspfads bereit, der Azure Firewall für IPv4 bereitstellt. Stellen Sie mindestens zwei Instanzen bereit, damit der Ausfall einer Instanz die IPv6-Konnektivität nicht unterbricht.
   • ExpressRoute verbindet das standortübergreifende Netzwerk mit dem Hub und führt sowohl IPv4- als auch IPv6-Datenverkehr.
   • VPN Gateway stellt auch das lokale Netzwerk mit dem Hub in Verbindung und kann als IPv4-Failoverpfad für private ExpressRoute-Peering dienen. Die Koexistenz allein erzeugt kein Failover. Konfigurieren Sie Ihr lokales Netzwerk so, dass sie die Routen bevorzugt, die es über ExpressRoute lernt, z. B. durch Festlegen einer höheren lokalen BGP-Einstellung. Da VPN Gateway mit einem IPv6-fähigen ExpressRoute-Gateway in diesem Hub koexistiert, führt es nur IPv4-Datenverkehr.
   • Die Dienste im virtuellen Hubnetzwerk senden Protokolle und Metriken (Diagnose) an Azure Monitor zur Überwachung.

4. Virtuelle Speichennetzwerke: Vier Speichen verbinden sich mit dem Hub. Jede Speiche ist ein Dual-Stack-Netzwerk, das sowohl IPv4 als auch IPv6 unterstützt.

   • Benutzerdefinierte IPv6-Routen (UDRs) definieren benutzerdefinierte Routen für IPv6-Verkehr von der Speiche.
   • Die virtuellen Speichennetzwerke werden über Peeringverbindungen oder verbundene Gruppen verbunden. Peering-Verbindungen und verbundene Gruppen sind nicht-transitive Verbindungen mit geringer Latenz zwischen virtuellen Netzwerken. Per Peering gekoppelte oder verbundene virtuelle Netzwerke können über den Azure-Backbone Datenverkehr miteinander austauschen.
   • Der gesamte ausgehende IPv4-Datenverkehr aus den virtuellen Speichennetzwerken fließt über den Hub. Eine IPv4-Standardroute in der Routingtabelle jedes Speichensubnetz sendet diesen Datenverkehr an Azure Firewall. Eine separate IPv6-Standardroute sendet ausgehenden IPv6-Datenverkehr an den IPv6-NVA-Pool, da diese Architektur Azure Firewall IPv4-only behält.
   • Innerhalb jeder Speiche gibt es drei Subnetze, die als Ressourcen-Subnetze bezeichnet werden und jeweils eine virtuelle Maschine beherbergen.
   • Jede virtuelle Maschine ist mit einem internen Load Balancer verbunden, der für die Unterstützung von IPv4- und IPv6-Adressbereichen konfiguriert ist. Der Load Balancer verteilt den eingehenden Netzwerkverkehr auf die virtuellen Maschinen.

Components

• Azure Virtual Network ist die grundlegende Netzwerkebene in Azure, die eine sichere Kommunikation zwischen Azure-Ressourcen, dem Internet und lokalen Netzwerken ermöglicht. In dieser Architektur bildet sie die Hub-and-Spoke-Topologie, die Dual-Stack-Konfigurationen (IPv4 und IPv6) für zentralisierte und isolierte Konnektivität unterstützt.
• Eine virtuelle Netzwerkschnittstelle ist eine logische Schnittstelle, die Azure-Ressourcen mit einem virtuellen Netzwerk verbindet. In dieser Architektur können virtuelle Computer sowohl über IPv4 als auch über IPv6 kommunizieren. Eine Schnittstelle wird Dual-Stack-fähig, wenn Sie zusätzlich zu ihrer vorhandenen IPv4-Konfiguration eine IPv6-Konfiguration hinzufügen.
• Eine öffentliche IP-Adresse stellt eine eingehende Verbindung mit Azure-Ressourcen über das Internet bereit. In dieser Architektur unterstützt sie sowohl den IPv4- als auch den IPv6-Zugriff auf Dienste, die im virtuellen Netzwerk gehostet werden.
• Virtual Network Manager ist ein zentraler Verwaltungsdienst zum Organisieren und Konfigurieren virtueller Netzwerke und deren Konnektivität. In dieser Architektur verwaltet sie Netzwerkgruppen und Verbindungen über den Hub und die Speichennetzwerke.
• Azure Firewall ist ein Netzwerksicherheitsdienst, der Azure-Ressourcen durch Prüfen und Filtern von Datenverkehr schützt. In dieser Architektur erzwingt sie die IPv4-Datenverkehrskontrolle zwischen dem Hub und dem öffentlichen Internet. Eine verwaltete Azure Firewall-Instanz befindet sich in einem eigenen Subnetz, das in dieser Architektur ausschließlich IPv4 verwendet, da sich die Dual-Stack-IPv6-Unterstützung noch in der Vorschau befindet und Anwendungsregeln, DNAT, Threat Intelligence, IDPS, Explicit Proxy und IP-Gruppen ausschließt.
• Eine virtuelle Netzwerk-Appliance (NVA) ist ein virtueller Computer, der eine Netzwerkfunktion ausführt, z. B. eine Firewall oder einen Router. In dieser Architektur überprüft und filtert ein Pool von IPv6-fähigen NVAs im Hub IPv6-Datenverkehr. Ein interner Lastenausgleich ist dem Pool vorgeschaltet, sodass keine einzelne Appliance zu einem Single Point of Failure für die IPv6-Konnektivität wird.
• VPN Gateway und ExpressRoute sind Dienste, die eine sichere lokale Konnektivität zwischen Azure und lokalen Netzwerken bieten. Sie können virtuelle Netzwerkgateways erstellen, die virtuelle Azure-Netzwerke mit VPN-Geräten (Virtual Private Network) oder ExpressRoute-Schaltkreisen verbinden, die verschlüsselte oder private Kommunikation ermöglichen. In dieser Architektur leitet ExpressRoute standortübergreifenden IPv6-Datenverkehr über IPv6-Privat-Peering weiter, und VPN Gateway leitet nur IPv4-Datenverkehr weiter, da beide Gateways koexistieren.
• Azure Load Balancer ist ein Layer-4-Lastenausgleichsdienst, der eingehenden Netzwerkdatenverkehr über mehrere Back-End-Ressourcen verteilt, um hohe Verfügbarkeit und Skalierbarkeit sicherzustellen. In dieser Architektur verteilt ein interner Lastenausgleich in jedem Spoke den IPv6-Datenverkehr auf die virtuellen Maschinen in diesem Spoke, und ein interner Lastenausgleich im Hub ist dem IPv6-NVA-Pool vorgeschaltet.
• Azure NAT Gateway bietet nur ausgehende Internetverbindung für ein Subnetz. In dieser Architektur verschafft ein dem NVA-Subnetz zugeordnetes StandardV2-NAT-Gateway dem IPv6-NVA-Pool einen expliziten Pfad für ausgehenden Datenverkehr, da der dem Pool vorgeschaltete interne Load Balancer keine ausgehende Konnektivität bereitstellt.
• Eine Routentabelle ist eine Reihe von UDRs, die benutzerdefinierte Kontrolle darüber bieten, wie Datenverkehr innerhalb und zwischen virtuellen Azure-Netzwerken fließt. In dieser Architektur leiten UDRs IPv6-Datenverkehr über Hub-and-Spoke-Subnetze, um Datenverkehrsfluss und Sicherheitsrichtlinien zu erzwingen.
• Azure Virtual Machines ist eine Infrastruktur als IaaS-Lösung (Infrastructure as a Service), die flexible, skalierbare Computeressourcen bereitstellt. In dieser Architektur werden virtuelle Computer in Speichensubnetzen bereitgestellt, die mithilfe von Dual-Stack-Netzwerkschnittstellen konfiguriert werden, die unterstützung für IPv4- und IPv6-Workloads ermöglichen.
• Azure Bastion ist eine verwaltete Plattform als Dienst (PaaS), die sicheren RDP- und SSH-Zugriff auf virtuelle Computer bietet, ohne sie dem öffentlichen Internet offen zu stellen. In dieser Architektur wird es im Hub ausgeführt und ermöglicht den TLS-gesicherten Remotezugriff auf die virtuellen Maschinen in den per Peering verbundenen Spoke-virtuellen Netzwerken.
• Azure Monitor ist eine Observability-Plattform, die Telemetriedaten aus Azure- und Hybridumgebungen sammelt, analysiert und verarbeitet. In dieser Architektur werden Diagnosen und Metriken von Hubdiensten gesammelt, um leistungsüberwachung und operative Sichtbarkeit zu unterstützen.

Einschränkungen der IPv6-Unterstützung

Mehrere Dienste, die häufig in einer Hub-Spoke-Topologie vorkommen, tragen keinen IPv6-Datenverkehr, oder führen sie nur unter bestimmten Bedingungen aus. Berücksichtigen Sie diese Einschränkungen, bevor Sie Ihren Adressraum und Ihr Routing planen.

Die vollständige Liste finden Sie unter IPv6 für Azure Virtual Network Einschränkungen und ExpressRoute IPv6-Einschränkungen.

Ein interner Load Balancer verteilt nur eingehenden Datenverkehr und bietet keine ausgehende Konnektivität. Subnetze in virtuellen Netzwerken, die Sie mit einer aktuellen API-Version erstellen, sind standardmäßig privat, sodass sie keinen standardmäßigen ausgehenden Zugriff haben. Jedes Subnetz, das IPv6-Datenverkehr an das Internet sendet, benötigt eine explizite Ausgangsmethode, einschließlich des NVA-Subnetzes. Diese Architektur fügt ein StandardV2 NAT-Gateway an das NVA-Subnetz an, bei dem es sich um die einzige NAT-Gateway-SKU handelt, die IPv6 unterstützt.

Kombinieren Sie ein StandardV2 NAT-Gateway nicht mit Ausgangsregeln für Azure Load Balancer im selben Subnetz. Das NAT-Gateway stört ausgehende IPv6-Verbindungen, die diese Regeln verwenden. Ein StandardV2 NAT-Gateway bietet auch NAT64-Übersetzung, sodass IPv6-Workloads IPv4-ziele erreichen können, aber für den namenbasierten Zugriff auf diese Ziele ist eine DNS64-Lösung eines Drittanbieters erforderlich, um AAAA-Einträge zu synthetisieren.

Umstellen eines virtuellen Hub-Netzwerks auf IPv6

Um ein virtuelles Hubnetzwerk zur Unterstützung von IPv6 zu übertragen, müssen Sie die Netzwerkinfrastruktur so aktualisieren, dass sie IPv6-Adressbereiche aufnehmen kann, sodass der zentrale Teil des Netzwerks IPv6-Datenverkehr verarbeiten kann. Mit diesem Ansatz wird sichergestellt, dass der zentrale Hub den Datenverkehr mithilfe von IPv6 effizient zwischen verschiedenen Netzwerksegmenten (Speichen) leiten und verwalten kann. Um IPv6 im virtuellen Netzwerk des Hubs zu implementieren, gehen Sie folgendermaßen vor:

Hinzufügen von IPv6-Adressraum zum virtuellen Netzwerk des Hubs und zu den Subnetzen des Hubs

Sie müssen zuerst IPv6-Adressbereiche zum virtuellen Hubnetzwerk und dann zu seinen Subnetzen hinzufügen. Verwenden Sie den /56-Adressblock für das virtuelle Netzwerk und den /64-Adressblock für jedes Subnetz. Die folgende Tabelle zeigt ein Beispiel-Setup.

Fügen Sie dem Azure Firewall Subnetz keinen IPv6-Adressraum hinzu. Diese Architektur belässt Azure Firewall bei IPv4, da die Dual-Stack-Unterstützung derzeit nur als Vorschau verfügbar ist und weder Anwendungsregeln noch IDPS abdeckt. Das VPN-Gateway koexistiert mit dem IPv6-fähigen ExpressRoute-Gateway, sodass es nur IPv4-Datenverkehr trägt. Leiten Sie IPv6 nicht darüber weiter, auch wenn sein Subnetz für Dual-Stack konfiguriert ist.

Das Azure Bastion Subnetz benötigt nur IPv6-Adressraum, wenn Sie einen Bastion-Host mit dualem Stapel ausführen. Sie können einen vorhandenen Host, der nur IPv4 unterstützt, nicht konvertieren. Stellen Sie Bastion daher mit aktiviertem Dual Stack erneut bereit, bevor Sie sich auf diesen Adressbereich verlassen.

Die IPv6-Adressen in der Tabelle sind Beispiele. Ersetzen Sie 2001:db8:1234:: durch den IPv6-Adressblock Ihrer Organisation. Planen und dokumentieren Sie Ihre IPv6-Adresszuweisungen sorgfältig, um Überschneidungen zu vermeiden und eine effiziente Nutzung des Adressraums sicherzustellen. Informationen zum Hinzufügen des IPv6-Adressraums zum virtuellen Hubnetzwerk finden Sie unter Hinzufügen von IPv6 zu einem virtuellen Netzwerk, das Anweisungen zur Verwendung des Azure-Portals, PowerShell und der Azure CLI enthält.

Bereitstellen des IPv6 NVA-Pools für hohe Verfügbarkeit

Der IPv6 NVA führt jeden geprüften IPv6-Fluss in dieser Architektur durch, sodass eine einzelne Appliance zu einem einzigen Fehlerpunkt für das IPv6-Internet und die standortübergreifende Konnektivität wird. Stellen Sie einen Pool von Appliances anstelle eines virtuellen Computers bereit.

• Stellen Sie mindestens zwei NVA-Instanzen bereit, und verteilen Sie sie über Verfügbarkeitszonen in Regionen, die Zonen unterstützen.
• Schalten Sie dem Pool einen internen Standard-Load Balancer mit einer Dual-Stack-Front-End-Konfiguration vor. Konfigurieren Sie eine Portregel für hohe Verfügbarkeit , indem Sie das Protokoll auf "All " und den Port auf "0 " festlegen, damit der Lastenausgleich alle Protokollflüsse an alle Ports an die Instanzen weiterleitet, einschließlich ICMP. ICMP ist für IPv6 wichtig, da Neighbor Discovery und Path-MTU-Erkennung von ICMPv6 abhängen. Weitere Informationen finden Sie unter Erstellen eines internen Dualstapel-Lastenausgleichs.
• Verweisen Sie jeden IPv6 UDR auf die IPv6-Front-End-Adresse des Lastenausgleichs und nicht auf eine einzelne Appliance. Die Beispiele in diesem Artikel verwenden 2001:db8:1234:0004::4 im NVA-Subnetz als Front-End-Adresse.
• Wenden Sie eine Netzwerksicherheitsgruppe auf das NVA-Subnetz an. In einer Dual-Stack-Konfiguration funktionieren Load Balancer-Integritätstests nicht für IPv6, es sei denn, eine Netzwerksicherheitsgruppe ist aktiv, sodass der Load Balancer keine fehlerhafte Appliance erkennen kann.
• Fügen Sie ein StandardV2 NAT-Gateway an das NVA-Subnetz an. Der interne Lastenausgleich bietet keine ausgehende Verbindung, sodass die Appliances eine explizite Ausgangsmethode benötigen, um das Internet zu erreichen.
• Vergewissern Sie sich, dass Ihr NVA-Anbieter das Design überprüft und unterstützt. Befolgen Sie die Vorgaben des Anbieters zur Aktiv/Aktiv- gegenüber Aktiv/Standby-Topologie sowie dazu, ob für die Appliance Source Network Address Translation (SNAT) erforderlich ist, um einen symmetrischen Datenverkehr sicherzustellen.

Informationen zu den verfügbaren Entwurfsmustern, deren Konvergenzzeiten und ihren Verkehrssymmetrie-Kompromissen finden Sie unter Bereitstellen von hoch verfügbaren NVAs.

Konfigurieren von UDRs für jedes Hub-Subnetz

UDRs sind Routen, die Sie manuell einrichten, um die Azure Standardsystemrouten außer Kraft zu setzen. In Azure sind UDRs für die Steuerung des Netzwerkdatenverkehrs in einem virtuellen Netzwerk unerlässlich. Sie können UDRs verwenden, um den Datenverkehr von einem Subnetz zu bestimmten Anwendung, Gateways oder Zielen in Azure oder zu lokalen Netzwerken zu leiten. Wenn Sie dem virtuellen Hubnetzwerk IPv6-Unterstützung hinzufügen, müssen Sie:

• IPv6-Routen hinzufügen. Vorhandene IPv4-Routen gelten nicht für IPv6-Datenverkehr, da jede Route über ein einzelnes Zieladressenpräfix verfügt. Erstellen Sie separate Routen, die die IPv6-Zielpräfixe und die nächsten erforderlichen Hops angeben.
• Verknüpfen Sie die Routentabelle mit Subnetzen Nachdem Sie die Routen definiert haben, ordnen Sie die Routentabelle den relevanten Subnetzen innerhalb des virtuellen Netzwerks zu. Diese Zuordnung bestimmt, welche Subnetze die von Ihnen definierten Routen verwenden.

Sie definieren Routen für Zielpräfixe, nicht für einzelne Ressourcen. Sie ordnen eine Routentabelle einem Subnetz zu, und jede Ressource in diesem Subnetz folgt den Routen in dieser Tabelle. Weitere Informationen finden Sie unter Übersicht über benutzerdefinierte Routen.

In der Beispielarchitektur verfügt das virtuelle Hubnetzwerk über IPv6-Routen für das Gateway-Subnetz und das NVA-Subnetz. Das Azure Firewall Subnetz verfügt über keine IPv6-Routen, da es nur IPv4 ist und das Azure Bastion Subnetz keine Routentabelle aufweist, da Azure Bastion UDRs AzureBastionSubnetnicht unterstützt. Die Adresse des nächsten Hops 2001:db8:1234:0004::4 ist die IPv6-Front-End-Adresse des internen Lastenausgleichs, der dem NVA-Pool vorgeschaltet ist, und nicht die Adresse einer einzelnen Appliance. Die folgende Tabelle zeigt Beispiel-IPv6-UDRs.

Wiederholen Sie die Prüfroute für jedes Spoke-Präfix, das vom NVA-Pool geprüft werden soll. Deaktivieren Sie die BGP-Routenverteilung im GatewaySubnet nicht, da das Gateway nicht funktioniert. Die Verteilung sollte in den NVA- und Spoke-Subnetzen aktiviert bleiben, sodass BGP-gelernte lokale IPv6-Präfixe für überprüften Datenverkehr weiterhin zur Verfügung stehen.

Erstellen Sie keine Routen, die den Virtual network gateway Next-Hop-Typ verwenden. Azure unterstützt diesen nächsten Hoptyp nur, wenn das Gateway des virtuellen Netzwerks ein VPN-Gateway ist. Wenn ein VPN-Gateway und ein ExpressRoute-Gateway im selben virtuellen Netzwerk bereitgestellt werden, behandelt Azure das ExpressRoute-Gateway als Gateway des virtuellen Netzwerks, sodass der nächste Hoptyp in dieser Architektur nicht angewendet wird.

Wenn Sie Ihre UDRs einrichten, müssen Sie sie an Ihre Organisationsnetzwerkrichtlinien und die Architektur Ihrer Azure-Bereitstellung anpassen.

Ändern Sie die ExpressRoute-Leitung (falls zutreffend).

Um IPv6 auf dem ExpressRoute-Schaltkreis zu aktivieren, müssen Sie:

• IPv6 privates Peering aktivieren. Das private IPv6-Peering für den ExpressRoute-Schaltkreis aktivieren. Diese Konfiguration ermöglicht IPv6-Datenverkehr zwischen Ihrem lokalen Netzwerk und dem virtuellen Hubnetzwerk.
• Zuordnen des IPv6-Adressraums. Stellen Sie ein Paar von /126 IPv6-Subnetzen bereit, die Sie für die primären und sekundären ExpressRoute-Verknüpfungen besitzen.
• Überprüfen der Routenverteilung. Das Gateway lernt lokale IPv6-Präfixe über BGP unabhängig von jeder Einstellung der Routentabelle. Die Routenweitergabe steuert, ob Azure diese erlernten Präfixe in die Routingtabelle eines Subnetzes einträgt. Daher sollte sie im NVA-Subnetz sowie in den Spoke-Subnetzen, die eine Verbindung mit lokalen Standorten benötigen, aktiviert bleiben.

Diese Konfigurationen erweitern die IPv6-Konnektivität mit Ihren Azure-Diensten über einen ExpressRoute-Schaltkreis, sodass Sie Dual-Stack-Funktionen gleichzeitig weiterleiten können. Informationen zum Ändern von ExpressRoute finden Sie unter "Hinzufügen von IPv6-Unterstützung für privates Peering", das Anweisungen zur Verwendung des Azure-Portals, von PowerShell und des Azure CLI enthält.

Überprüfen Sie die folgenden Gateway- und Netzwerkanforderungen:

• Fügen Sie dem virtuellen Netzwerk und dem Gatewaysubnetz IPv6-Adressraum hinzu, bevor Sie das virtuelle ExpressRoute-Netzwerkgateway erstellen.
• IPv6-privates Peering wird von neu erstellten ExpressRoute-Gateways für virtuelle Netzwerke jeder SKU unterstützt, die eine öffentliche statische IP-Adresse vom Typ Standard verwenden.
• Vorhandene Gateways unterstützen IPv6 nur, wenn sie zonenredundant sind.
• Privates IPv6-Peering wird mit Virtual WAN nicht unterstützt, und ein Dual-Stack-Gateway kann keine Verbindung mit einer Leitung herstellen, für die nur IPv4 für privates Peering aktiviert ist.
• Außerdem müssen Sie IPv6 auf Ihrem lokalen Kundengerät konfigurieren.

Übergang von virtuellen Spoke-Netzwerken zu IPv6

Virtuelle Spoke-Netzwerke sind mit dem zentralen Hub verbunden. Wenn Sie IPv6 in den virtuellen Speichennetzwerken aktivieren, kann jedes Speichennetzwerk über das IPv6-Protokoll kommunizieren, und das Netzwerk erhält einen konsistenteren IPv6-Entwurf in der gesamten Topologie. Führen Sie die folgenden Schritte aus, um IPv6 in den virtuellen Speichennetzwerken zu aktivieren:

IPv6-Adressraum zu den Spoke-VNetzen und Spoke-Subnetzen hinzufügen

Wie beim virtuellen Hubnetzwerk müssen Sie IPv6-Adressbereiche zu jedem virtuellen Spoke-Netzwerk und dann ihren Subnetzen hinzufügen. Verwenden Sie den Adressblock /56 für die virtuellen Netzwerke und den Adressblock /64 für die Subnetze. Die folgende Tabelle zeigt ein Beispiel für IPv6-Adressbereiche von Spoke-virtuellen Netzwerken und deren Subnetzen.

Passen Sie für Ihr Setup die IPv6-Adressen entsprechend der Zuordnung und den Anforderungen Ihrer Organisation an.

Ändern der Ressourcen des virtuellen Spoke-Netzwerks

Jedes virtuelle Spoke-Netzwerk enthält mehrere virtuelle Maschinen und einen internen Load Balancer. Der interne Load Balancer ermöglicht es Ihnen, IPv4- und IPv6-Datenverkehr an die virtuellen Maschinen zu leiten. Sie müssen die virtuellen Computer und interne Lastenausgleichsgeräte so ändern, dass sie IPv6 unterstützen.

Fügen Sie für jeden virtuellen Computer eine IPv6-IP-Konfiguration zur Netzwerkschnittstelle hinzu, über die der virtuelle Computer bereits verfügt. Erstellen Sie keine separate IPv6-Schnittstelle. Die Schnittstelle behält ihre IPv4-Konfiguration bei und wird zu einer Dual-Stack-Schnittstelle, was für jede Netzwerkschnittstelle erforderlich ist, da Azure keine reinen IPv6-Schnittstellen unterstützt. Weitere Informationen finden Sie unter IPv6-Konfiguration zu einer virtuellen Maschine hinzufügen.

Wenn in jedem virtuellen Speichennetzwerk kein interner Lastenausgleich vorhanden ist, erstellen Sie einen internen Dual-Stack-Lastenausgleich. Weitere Informationen finden Sie unter Erstellen eines internen Dualstapel-Lastenausgleichs. Wenn ein interner Lastenausgleich vorhanden ist, können Sie PowerShell oder die Azure CLI verwenden, um IPv6-Unterstützung hinzuzufügen.

Konfigurieren von UDRs für jedes Speichensubnetz

Verwenden Sie zum Konfigurieren von UDRs dieselbe Konfiguration für virtuelle Speichennetzwerke wie für virtuelle Hubnetzwerke. Wenn Sie IPv6-Unterstützung zu einem virtuellen Speichennetzwerk hinzufügen, müssen Sie:

• IPv6-Routen hinzufügen. Vorhandene IPv4-Routen gelten nicht für IPv6-Datenverkehr, da jede Route über ein einzelnes Zieladressenpräfix verfügt. Erstellen Sie separate Routen, die die IPv6-Zielpräfixe und die nächsten erforderlichen Hops angeben.
• Verknüpfen Sie die Routentabelle mit Subnetzen Nachdem Sie die Routen definiert haben, ordnen Sie die Routentabelle den relevanten Subnetzen innerhalb des virtuellen Netzwerks zu. Diese Zuordnung bestimmt, welche Subnetze die von Ihnen definierten Routen verwenden.

Die folgende Tabelle zeigt Beispiel-IPv6-UDRs für jedes Subnetz in einem virtuellen Speichennetzwerk. Internetgebundener IPv6-Datenverkehr wechselt in den IPv6-NVA-Pool im Hub und nicht zu Azure Firewall, wodurch diese Architektur IPv4-only behält. Wie im Hub ist die nächste Hopadresse die IPv6-Front-End-Adresse des Lastenausgleichs, nicht die Adresse einer einzelnen Appliance.

Spokes erhalten über BGP vom ExpressRoute-Gateway lokale IPv6-Präfixe, wenn Sie im Peering Gateway oder Route Server des virtuellen Remotenetzwerks verwenden aktivieren. Fügen Sie eine lokale UDR nur hinzu, wenn Sie diese gelernten Routen außer Kraft setzen möchten, z. B. wenn Sie den Datenverkehr zur Überprüfung an die NVA senden. Wie im Hub sollten Sie nicht den Next-Hop-Typ Virtual network gateway verwenden, um lokale Netzwerke über ExpressRoute zu erreichen.

Für Ihre Einrichtung müssen Sie die UDRs an den Netzwerkrichtlinien Ihrer Organisation und der Architektur Ihrer Azure-Bereitstellung ausrichten.

Contributors

Microsoft verwaltet diesen Artikel. Dieser Artikel wurde ursprünglich von folgenden Mitwirkenden verfasst.

Hauptautor:

• Werner Rall | Senior Cloud Solutions Architect

Andere Mitwirkende:

• Sherri Babylon | Leitender technischer Programmmanager
• Dawn Bedard | Leitender technischer Programmmanager
• Brandon Stephenson | Leitender Kundeningenieur

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

Nächste Schritte

• Erstellen eines virtuellen Computers mit einem IPv6-Dual-Stack-Netzwerk
• Verwalten von IP-Adressbereichen
• Cloud Adoption Framework: Planung der IP-Adressierung
• IPv6 für Azure Virtual Network
• Hinzufügen der IPv6-Unterstützung für private ExpressRoute-Peering
• Übersicht über Reverse DNS in Azure DNS
• Azure NAT Gateway SKUs

Verwandte Ressourcen

• Übergang zu IPv6
• Optionen für virtuelle Netzwerkkonnektivität und Sprach-zu-Speichen-Kommunikation
• Firewall und Anwendungsgateway für virtuelle Netzwerke
• Deploy AD DS in einem Azure virtuellen Netzwerk