Ausführliche Informationen zu Virtual WAN-Routing
Azure Virtual WAN ist eine Netzwerklösung, mit der anspruchsvolle Netzwerktopologien einfach erstellt werden können: Sie umfasst das Routing zwischen Azure-VNets und lokalen Standorten über Point-to-Site-VPN, Site-to-Site-VPN, ExpressRoute und integrierte SDWAN-Appliances, einschließlich der Option zum Sichern des Datenverkehrs. In den meisten Szenarien ist es nicht erforderlich, dass Sie umfassende Kenntnisse darüber haben, wie internes Virtual WAN-Routing funktioniert. In bestimmten Situationen kann es aber nützlich sein, Virtual WAN-Routingkonzepte zu verstehen.
In diesem Dokument werden Virtual WAN-Beispielszenarien untersucht, die einige der Verhaltensweisen erläutern, die Organisationen bei der Verbindung ihrer VNets und Verzweigungen in komplexen Netzwerken antreffen können. Die in diesem Artikel gezeigten Szenarien sind keine Entwurfsempfehlungen, sie sind nur Beispieltopologien, die darauf ausgelegt sind, bestimmte Virtual WAN-Funktionen zu veranschaulichen.
Szenario 1: Topologie mit Standardroutingvoreinstellung
Im ersten Szenario in diesem Artikel wird eine Topologie mit zwei Virtual WAN Hubs analysiert: ExpressRoute, VPN und SDWAN-Konnektivität. In jedem Hub sind VNets direkt (VNets 11 und 21) und indirekt über eine NVA (VNets 121, 122, 221 und 222) verbunden. VNet 12 tauscht Routinginformationen mit Hub 1 über BGP aus (siehe BGP-Peering mit einem virtuellen Hub), und für VNet 22 sind statische Routen konfiguriert, sodass Unterschiede zwischen beiden Optionen angezeigt werden können.
In jedem Hub erfüllen VPN und SDWAN-Appliances einen zweifachen Zweck: Auf einer Seite kündigen sie ihre eigenen individuellen Präfixe an (10.4.1.0/24 über VPN in Hub 1 und 10.5.3.0/24 über SDWAN in Hub 2), auf der anderen Seite kündigen sie dieselben Präfixe wie die ExpressRoute-Verbindungen in derselben Region an (10.4.2.0/24 in Hub 1 und 10.5.2.0/24 in Hub 2). Dieser Unterschied wird verwendet, um zu veranschaulichen, wie die Virtual WAN-Hubroutingeinstellung funktioniert.
Alle VNet- und Verzweigungsverbindungen werden der Standardroutingtabelle zugeordnet und an diese weitergegeben. Obwohl die Hubs gesichert sind (in jedem Hub ist eine Azure Firewall bereitgestellt), sind sie nicht so konfiguriert, privaten oder Internetdatenverkehr zu sichern. Dies würde dazu führen, dass alle Verbindungen, die an die None Routingtabelle weitergegeben werden, alle nicht statischen Routen aus der Default Routingtabelle entfernen und den Zweck dieses Artikels verfehlen würden, da das effektive Routenblatt im Portal fast leer wäre (mit Ausnahme der statischen Routen, um Datenverkehr an die Azure Firewall zu senden).
Wichtig
Die Abbildung oben zeigt zwei geschützte virtuelle Hubs, aber diese Topologie wird mit Routingabsicht noch nicht unterstützt. Weitere Informationen finden Sie unter Konfigurieren von Routingabsichten und Routingrichtlinien für den Virtual WAN-Hub.
Vorkonfiguriert tauschen die Virtual WAN Hubs Informationen untereinander aus, sodass die Kommunikation über Regionen hinweg aktiviert ist. Sie können die effektiven Routen in Virtual WAN Routingtabelle überprüfen: Beispielsweise zeigt die folgende Abbildung die effektiven Routen in Hub 1:
Diese effektiven Routen werden dann von Virtual WAN für Verzweigungen angekündigt und in die VNets eingefügt, die mit den virtuellen Hubs verbunden sind. Dadurch müssen keine benutzerdefinierten Routen mehr verwendet werden. Wenn Sie die effektiven Routen in einem virtuellen Hub überprüfen, geben die Felder "Nächster Hoptyp" und "Ursprung" an, woher die Routen kommen. Beispielsweise gibt ein nächster Hoptyp von "Virtual Network-Verbindung" an, dass das Präfix in einem VNet definiert ist, das direkt mit dem Virtual WAN verbunden ist (VNets 11 und 12 im vorherigen Screenshot)
Das NVA in VNet 12 fügt die Route 10.1.20.0/22 über BGP ein, wie der Next Hop-Typ „HubBgpConnection“ impliziert (siehe BGP-Peering mit einem virtuellen Hub). Diese Zusammenfassungsroute deckt sowohl indirekte Spokes VNET 121 (10.1.21.0/24) als auch VNet 122 (10.1.22.0/24) ab. VNets und Verzweigungen im Remotehub sind mit einem nächsten Hop von hub2 sichtbar, und es kann im AS-Pfad gesehen werden, dass die autonome Systemnummer 65520 diesen Interhub-Routen zwei Mal vorangestellt wurde.
In Hub 2 ist eine integrierte SDWAN Network Virtual Appliance (NVA) vorhanden. Weitere Einzelheiten zu den unterstützten NVAs für diese Integration finden Sie unter NVAs in einem Virtual WAN-Hub. Beachten Sie, dass die Route zur SDWAN Verzweigung 10.5.3.0/24 einen nächsten Hop von VPN_S2S_Gateway hat. Diese Art des nächsten Hops kann heute entweder Routen anzeigen, die von einem Azure Virtual Network Gateway oder von in den Hub integrierten NVAs stammen.
In Hub 2 wird die Route für 10.2.20.0/22 zu den indirekten Speichen VNet 221 (10.2.21.0/24) und VNet 222 (10.2.22.0/24) als statische Route installiert, was durch den Ursprung defaultRouteTable angezeigt wird. Wenn Sie die effektiven Routen für Hub 1 einchecken, gibt es diese Route nicht. Der Grund ist, dass statische Routen nicht über BGP propagiert werden, sondern in jedem Hub konfiguriert werden müssen. Daher ist eine statische Route in Hub 1 erforderlich, um die Konnektivität zwischen den VNets und Zweigstellen in Hub 1 zu den indirekten Speichen in Hub 2 (VNets 221 und 222) bereitzustellen:
Nach dem Hinzufügen der statischen Route enthält Hub 1 auch die Route 10.2.20.0/22:
Szenario 2: Global Reach- und Hubroutingvoreinstellung
Selbst wenn Hub 1 das ExpressRoute-Präfix von Verbindung 2 (10.5.2.0/24) und Hub 2 das ExpressRoute-Präfix von Verbindung 1 kennt (10.4.2.0/24), werden ExpressRoute-Routen aus Remote-Regionen nicht an die lokalen ExpressRoute-Links zurückgemeldet. Daher ist ExpressRoute Global Reach erforderlich, damit die ExpressRoute-Standorte miteinander kommunizieren können:
Wichtig
Die Abbildung oben zeigt zwei geschützte virtuelle Hubs, aber diese Topologie wird mit Routingabsicht noch nicht unterstützt. Weitere Informationen finden Sie unter Konfigurieren von Routingabsichten und Routingrichtlinien für den Virtual WAN-Hub.
Wie unter Virtual WAN-Hubroutingpräferenz erläutert, bevorzugt Virtual WAN standardmäßig Routen, die von ExpressRoute stammen. Da Routen von Hub 1 zur ExpressRoute-Leitung 1, von der ExpressRoute-Leitung 1 zur Leitung 2 und von der ExpressRoute-Leitung 2 bis Hub 2 (und umgekehrt) angekündigt werden, bevorzugen virtuelle Hubs jetzt diesen Weg gegenüber der direkteren Inter-Hub-Verbindung. Die effektiven Routen in Hub 1 zeigen dies:
Wie Sie in den Routen sehen können, wird ExpressRoute Global Reach mehrfach die ExpressRoute Autonomous System Number (12076) vorgestellt, bevor die Routen zurück an Azure gesendet werden, um diese Routen weniger bevorzugt zu machen. Die standardmäßige Hub-Routing-Präferenz von Virtual WAN von ExpressRoute ignoriert jedoch die AS-Pfadlänge bei der Routing-Entscheidung.
Die effektiven Routen in Hub 2 sind ähnlich:
Die Routingpräferenz kann in „VPN“ oder „AS-Pfad“ geändert werden, wie in Virtual WAN-Hubroutingpräferenz erläutert. Sie können z. B. die Voreinstellung auf VPN festlegen.
Mit einer Hubroutingvoreinstellung von VPN sehen die effektiven Routen in Hub 1 folgendermaßen aus:
Die vorherige Abbildung zeigt, dass die Route zu 10.4.2.0/24 nun einen nächsten Hop von VPN_S2S_Gateway hat, während sie bei der Standardroutingvoreinstellung von ExpressRoute ExpressRouteGateway war. In Hub 2 wird die Route zu 10.5.2.0/24 jedoch weiterhin mit einem nächsten Hop von ExpressRouteangezeigt, da in diesem Fall die alternative Route nicht von einer VPN Gateway, sondern von einem in den Hub integrierten NVA stammt:
Der Datenverkehr zwischen Hubs bevorzugt jedoch weiterhin die Routen, die über ExpressRoute kommen. Um die effizientere direkte Verbindung zwischen den virtuellen Hubs zu verwenden, kann die Routenvoreinstellung auf beiden Hubs auf „AS Path“ festgelegt werden.
Nun haben die Routen für remote Speichen und Verzweigungen in Hub 1 wie vorgesehen einen nächsten Hop von Remote Hub:
Sie können sehen, dass das IP-Präfix für Hub 2 (192.168.2.0/23) weiterhin über den Global Reach-Link erreichbar erscheint, aber dies sollte keine Auswirkungen auf den Datenverkehr haben, da es keinen Datenverkehr geben sollte, der an Geräte in Hub 2 gerichtet ist. Dies Route kann jedoch problematisch sein, wenn in beiden Hubs NVAs vorhanden sind, die untereinander SDWAN-Tunnel aufbauen.
Beachten Sie jedoch, dass 10.4.2.0/24 jetzt gegenüber dem VPN Gateway bevorzugt wird. Dies kann passieren, wenn die über VPN angekündigten Routen einen kürzeren AS-Pfad aufweisen als die über ExpressRoute angekündigten Routen. Nachdem das lokale VPN-Gerät so konfiguriert wurde, dass es seine autonome Systemnummer (65501) den VPN-Routen vorangestellt hat, um diese weniger bevorzugten zu machen, wählt Hub 1 nun ExpressRoute als nächsten Hop für 10.4.2.0/24:
Hub 2 zeigt eine ähnliche Tabelle für die effektiven Routen an, wobei die VNets und Verzweigungen im anderen Hub nun mit Remote Hub als nächstem Hop erscheinen:
Szenario 3: Querverbindungen der ExpressRoute-Leitungen zu beiden Hubs
Um direkte Verbindungen zwischen den Azure-Regionen und den lokalen Standorten hinzuzufügen, die über ExpressRoute verbunden sind, ist es oft wünschenswert, eine einzelne ExpressRoute-Verbindung mit mehreren Virtual WAN-Hubs in einer Topologie zu verbinden, die manchmal als „Fliege“ bezeichnet wird, wie die folgende Topologie zeigt:
Wichtig
Die Abbildung oben zeigt zwei geschützte virtuelle Hubs, aber diese Topologie wird mit Routingabsicht noch nicht unterstützt. Weitere Informationen finden Sie unter Konfigurieren von Routingabsichten und Routingrichtlinien für den Virtual WAN-Hub.
Virtual WAN zeigt an, dass beide Leitungen mit beiden Hubs verbunden sind:
Wenn Sie zur Standardvoreinstellung für das Hubrouting von ExpressRoute zurückkehren, zeigen die Routen zu Remoteverzweigungen und VNets in Hub 1 erneut ExpressRoute als nächster Hop an. Diesmal ist der Grund allerdings nicht Global Reach, sondern die Tatsache, dass die ExpressRoute-Verbindungen die Routenankündigungen, die sie von einem Hub zum anderen erhalten, zurückschicken. Die effektiven Routen von Hub 1 mit der Hub-Routingvoreinstellung von ExpressRoute sind beispielsweise folgende:
Wenn Sie die Hub-Routingvoreinstellung wieder in „AS Path“ ändern, werden die Inter-Hub-Routen mithilfe der direkten Verbindung zwischen den Hubs 1 und 2 an den optimalen Pfad zurückgegeben:
Nächste Schritte
Weitere Informationen zu Virtual WAN finden Sie unter:
- Häufig gestellte Fragen zu Virtual WAN