Standardeinfügung von Routen in virtuellen Spoke-Netzwerken

Eine der gängigsten Architekturen in Azure ist der Hub-and-Spoke-Entwurf, bei dem in einem virtuellen Spoke-Netzwerk (VNet) bereitgestellte Workloads Datenverkehr über gemeinsame Netzwerkgeräte senden, die im Hub-VNet vorhanden sind. In der Regel müssen benutzerdefinierte Routen (User Defined Routes, UDR) in den Spoke-VNets konfiguriert werden, um den Datenverkehr zu Sicherheitsgeräten im Hub zu leiten. Dieses Design setzt jedoch voraus, dass Administratoren diese Routen über viele Spokes hinweg verwalten.

Azure Route Server bietet einen zentralen Punkt, an dem virtuelle Netzwerkgeräte (NVAs) Routen ankündigen können, die in die Spoke-VNets eingefügt werden. Somit müssen Administratoren keine Routingtabellen in Spoke-Vnets erstellen und aktualisieren.

Topologie

Das folgende Diagramm zeigt einen einfachen Hub-and-Spoke-Entwurf mit einem Hub-VNet und zwei Spoke-VNets. Im Hub wurden eine virtuelle Netzwerkappliance und ein Route Server bereitgestellt. Ohne den Route Server müssten benutzerdefinierte Routen in jedem Spoke konfiguriert werden. Diese UDRs enthalten normalerweise eine Standardroute für 0.0.0.0/0, die den gesamten Datenverkehr von den Spoke-VNets über die NVA sendet. Dieses Szenario kann beispielsweise verwendet werden, um den Datenverkehr zu Sicherheitszwecken zu überprüfen.

In diesem Szenario mit dem Route Server im Hub-VNet müssen keine benutzerdefinierten Routen verwendet werden. Wenn die NVA Netzwerkpräfixe für Route Server ankündigt, werden sie so eingefügt, dass sie als effektive Routen auf jeder VM erscheinen, die im Hub-VNet oder in den Spoke-VNets, die über die Einstellung Gateway des virtuellen Remotenetzwerks oder Route Server verwenden per Peering mit dem Hub-VNet verknüpft sind, bereitgestellt werden.

Konnektivität mit der lokalen Umgebung über das NVA

Wenn das NVA verwendet wird, um Konnektivität mit dem lokalen Netzwerk über IPsec-VPNs oder SD-WAN-Technologien bereitzustellen, kann derselbe Mechanismus verwendet werden, um Datenverkehr von den Spokes zum NVA anzuziehen. Darüber hinaus kann das NVA die Azure-Präfixe vom Azure Route Server dynamisch lernen und sie mit einem dynamischen Routingprotokoll für die lokale Umgebung ankündigen. Im folgenden Diagramm wird dieses Setup beschrieben:

Untersuchen des privaten Datenverkehrs über die NVA

In den vorherigen Abschnitten wurde gezeigt, wie Datenverkehr von der virtuellen Netzwerkappliance (NVA) überprüft wird, indem eine Standardroute (0.0.0.0/0) von der NVA zu Route Server eingefügt wird. Wenn Sie jedoch nur den Datenverkehr zwischen Spokes und den Datenverkehr zwischen Spoke und lokaler Umgebung über die NVA überprüfen möchten, beachten Sie, dass der Azure Route Server keine Route ankündigt, die dem Präfix des Adressraums für das virtuelle Netzwerk, der über die NVA ermittelt wurde, entspricht oder länger ist. Mit anderen Worten: Der Azure Route Server fügt diese Präfixe nicht in das virtuelle Network ein und wird nicht in den NICs der VMs in die Hub- oder Spoke-VNets programmiert.

Der Azure Route Server kündigt jedoch ein Subnetz an, das größer ist als der VNet-Adressraum, der über die NVA ermittelt wird. Es ist möglich, über die NVA ein Supernet dessen anzukündigen, was in Ihrem virtuellen Netzwerk vorhanden ist. Wenn Ihr virtuelles Netzwerk beispielsweise den RFC 1918-Adressraum 10.0.0.0/16verwendet, kann Ihre NVA 10.0.0.0/8 beim Azure Route Server ankündigen, und diese Präfixe werden in die Hub- und Spoke-VNnets eingefügt. Auf dieses VNet-Verhalten wird in Informationen über BGP mit Azure VPN Gateway Bezug genommen.

Wichtig

Wenn Sie über ein Szenario verfügen, in dem Präfixe gleicher Länge von ExpressRoute und der NVA angekündigt werden, werden von Azure die aus ExpressRoute ermittelten Routen bevorzugt und programmiert. Weitere Informationen finden Sie unter Routingpräferenz.

Konnektivität mit der lokalen Umgebung über virtuelle Netzwerkgateways

Wenn sich ein VPN- oder ein ExpressRoute-Gateway im gleichen virtuellen Netzwerk befindet wie der Route Server und die NVA, um Konnektivität mit lokalen Netzwerken zu ermöglichen, werden die von diesen Gateways ermittelten Routen ebenfalls in den Spoke-VNets programmiert. Diese Routen setzen die vom Routenserver eingefügte Standardroute (0.0.0.0/0) außer Kraft, da sie spezifischer sind (längere Netzwerkmasken). Das folgende Diagramm beschreibt den vorherigen Entwurf, bei dem ein ExpressRoute-Gateway hinzugefügt wurde.

Um zu verhindern, dass Ihre Speichen-VNets mit den lokalen Präfixen programmiert werden, die vom VPN- und ExpressRoute-Gateway gelernt werden, können Sie "Verteilungsgatewayrouten" in den Routingtabellen der Speichensubnetze deaktivieren. Um sicherzustellen, dass VNet zu lokalem Datenverkehr vom NVA überprüft wird, können Sie eine 0.0.0.0/0 UDR (benutzerdefinierte Route) in den Routingtabellen der Speichensubnetze konfigurieren, wobei der nächste Hop als NVA/Firewall im Hub-VNet verwendet wird. Beachten Sie, dass das Deaktivieren der Funktion "Weiterleitung von Gateway-Routen" verhindert, dass diese Speichen-Subnetzwerke dynamisch Routen vom Route Server lernen.

Standardmäßig werden vom Route Server alle Präfixe, die von der NVA gelernt wurden, auch in ExpressRoute angekündigt. Dies kann z. B. aufgrund der Routenbeschränkungen von ExpressRoute nicht gewünscht werden. In diesem Fall kann der NVA seine Routen an den Route Server einschließlich der BGP-Community no-advertise (mit Wert 65535:65282) ankündigen. Wenn der Route Server Routen mit dieser BGP-Community empfängt, werden sie in die Subnetze eingefügt, aber sie werden nicht an andere BGP-Peers (z. B. ExpressRoute oder VPN-Gateways oder andere NVAs) angekündigt.

SDWAN-Koexistenz mit ExpressRoute und Azure Firewall

Ein besonderer Fall des vorherigen Designs besteht darin, dass Kunden die Azure Firewall im Datenverkehrsfluss einfügen, um den gesamten Datenverkehr, der in lokale Netzwerke fließt, zu überprüfen, entweder über ExpressRoute oder über SD-WAN/VPN-Geräte. In dieser Situation verfügen alle Spoke-Subnetze über Routentabellen, die verhindern, dass die Spokes eine beliebige Route von ExpressRoute oder dem Route Server lernen und Standardrouten (0.0.0.0/0) mit dem Azure Firewall als nächsten Hop verwenden, wie das folgende Diagramm zeigt:

Das Azure Firewall Subnetz lernt die Routen, die sowohl von ExpressRoute als auch vom VPN/SDWAN NVA stammen, und entscheidet, ob Datenverkehr auf die eine oder andere Weise gesendet wird. Wie im vorherigen Abschnitt beschrieben, sollte die NVA-Appliance ihre BGP-Routen mit der BGP-Community no-advertise kennzeichnen, wenn sie mehr als 1000 Routen an den Route Server ankündigt. Dadurch werden die SDWAN-Präfixe nicht über ExpressRoute wieder in die lokale Umgebung eingefügt.

Hinweis

Für jeglichen Datenverkehr, der von lokalen zu privaten Endpunkten geleitet wird, wird dieser Datenverkehr die Firewall NVA oder Azure Firewall im Hub umgehen. Dies führt jedoch zu einem asymmetrischen Routing (was zu Konnektivitätsverlusten zwischen lokalen und privaten Endpunkten führen kann), da private Endpunkte lokalen Datenverkehr an die Firewall weiterleiten. Um die Routingsymmetrie sicherzustellen, aktivieren Sie Routingtabellen-Netzwerkrichtlinien für private Endpunkte in den Subnetzen, in denen private Endpunkte bereitgestellt werden.

Symmetrie des Datenverkehrs

Wenn mehrere NVA-Instanzen in einem Aktiv/Aktiv-Szenario für eine bessere Ausfallsicherheit oder Skalierbarkeit verwendet werden, ist die Symmetrie des Datenverkehrs eine Voraussetzung, wenn die NVAs den Status der Verbindungen behalten müssen. Dies ist etwa bei Firewalls der nächsten Generation der Fall.

• Für die Konnektivität zwischen den virtuellen Azure-Computern und dem öffentlichen Internet verwendet das virtuelle Netzwerkgerät die Quellnetzwerk-Adressenübersetzung (Source Network Address Translation, SNAT), sodass der ausgehende Datenverkehr von der öffentlichen IP-Adresse des virtuellen Netzwerkgeräts stammt und die Symmetrie des Datenverkehrs so erreicht wird.
• Für eingehenden Datenverkehr aus dem Internet zu Workloads, die auf virtuellen Computern ausgeführt werden, müssen die NVAs zusätzlich zur Zielnetzwerk-Adressenübersetzung (Destination Network Address Translation, DNAT) SNAT (Source Network Address Translation) ausführen, um sicherzustellen, dass der Rückdatenverkehr von den virtuellen Computern auf derselben NVA-Instanz landet, die das erste Paket verarbeitet hat.
• Da der virtuelle Quellcomputer die Routingentscheidung unabhängig vom Ziel trifft, ist für die Azure-zu-Azure-Konnektivität derzeit SNAT erforderlich, um die Symmetrie des Datenverkehrs zu erreichen.

Mehrere NVA-Instanzen können auch in einem Aktiv/Passiv-Setup bereitgestellt werden, z. B. wenn eine davon schlechtere Routen (mit einem längeren AS-Pfad) ankündigt als die andere. In diesem Fall fügt der Azure Route Server nur die bevorzugte Route in die virtuellen VNet-Computer ein, und die weniger bevorzugte Route wird nur verwendet, wenn die primäre NVA-Instanz keine Ankündigungen mehr über BGP veröffentlicht.

Es ist auch wichtig zu beachten, dass Route Server den Datenpfad-Verkehr nicht unterstützt. Beim Anzeigen von Routen zum Route Server muss die NVA Routen mit dem nächsten Hop als sich selbst, einem Lastenausgleich vor dem NVA oder einer NVA/Firewall im selben VNet wie der NVA bewerben.

Zugehöriger Inhalt

• Erfahren Sie mehr über die Unterstützung von Azure Route Server für ExpressRoute und Azure VPN.
• Erfahren Sie, wie Sie das Peering zwischen Azure Route Server und Network Virtual Appliance konfigurieren.