Freigeben über

Standardeinfügung von Routen in virtuellen Spoke-Netzwerken

  • Artikel

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.

Diagramm mit grundlegender Hub- und Spoke-Topologie.

Wenn der Route Server im Hub VNet eingerichtet ist, müssen Sie keine benutzerdefinierten Routen verwenden. 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:

Diagramm mit einer grundlegenden Hub- und Spoke-Topologie mit lokaler Konnektivität über eine NVA.

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.

Diagramm der Einfügung privater Präfixe über Azure Route Server und NVA.

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 im nächsten Abschnitt.

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.

Diagramm mit einer grundlegenden Hub- und Spoke-Topologie mit lokaler Konnektivität über eine NVA und ExpressRoute.

Sie können die Subnetze in den Spoke-VNets nicht so konfigurieren, dass nur die Routen vom Azure Route Server ermittelt werden. Das Deaktivieren von „Gatewayrouten verteilen“ in einer einem Subnetz zugeordneten Routentabelle würde für beide Routentypen (Routen vom Gateway für virtuelle Netzwerke und Routen vom Azure Route Server) verhindern, dass sie auf NICs in diesem Subnetz eingefügt werden.

Standardmäßig werden vom Route Server alle Präfixe, die von der NVA gelernt wurden, auch in ExpressRoute angekündigt. Dies ist möglicherweise nicht gewünscht, z. B. aufgrund der Routenbeschränkungen von ExpressRoute oder dem Route Server selbst. 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:

Diagramm der Hub- und Spoke-Topologie mit lokaler Konnektivität über NVA für VPN und ExpressRoute, wobei Azure Firewall das Routing steuert.

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 200 Routen an den Route Server ankündigt. Dadurch werden die SDWAN-Präfixe nicht über ExpressRoute wieder in die lokale Umgebung eingefügt.

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.

Verschiedene Routenserver zum Ankündigen von Routen zu Gateways für virtuelle Netzwerke und VNets

Wie die vorherigen Abschnitte gezeigt haben, übernimmt Azure Route Server eine Doppelrolle:

  • Lernen und Ankündigen von Routen zu/von Gateways für virtuelle Netzwerke (VPN und ExpressRoute)
  • Konfigurieren der ermittelten Routen im eigenen VNet und in direkt mittels Peering verknüpften VNets

Diese Doppelfunktion ist oft gewünscht, kann aber manchmal für bestimmte Anforderungen nachteilig sein. Wenn sich der Routenserver beispielsweise in einem VNet mit einer NVA, die eine 0.0.0.0/0-Route ankündigt, und einem ExpressRoute-Gateway, das lokale Präfixe ankündigt, befindet, werden alle Routen (sowohl die 0.0.0.0/0-Route der NVA als auch die lokalen Präfixe) auf den virtuellen Computern in seinem VNet und direkt mittels Peering verknüpften VNets konfiguriert. Da die lokalen Präfixe spezifischer als 0.0.0.0/0 sind, umgeht der Datenverkehr zwischen der lokalen Umgebung und Azure die NVA. Wenn dies nicht gewünscht ist, finden Sie in den vorherigen Abschnitten dieses Artikels Informationen dazu, wie die BGP-Weitergabe in den VM-Subnetzen deaktiviert wird und wie UDRs konfiguriert werden.

Es gibt jedoch eine dynamischere Alternative. Es ist möglich, verschiedene Azure Route Server-Instanzen für unterschiedliche Funktionen zu verwenden: eine verantwortliche Instanz für die Interaktion mit den Gateways für virtuelle Netzwerke und eine verantwortliche Instanz für die Interaktion mit dem Routing für virtuelle Netzwerke. Das folgende Diagramm veranschaulicht einen möglichen Entwurf dafür:

Diagramm einer grundlegenden Hub- und Spoke-Topologie mit lokaler Konnektivität über ExpressRoute und zwei Route Server.

Route Server 1 wird im Hub verwendet, um die Präfixe aus dem SDWAN in ExpressRoute einzufügen. Da die Spoke-VNETs mit dem Hub-VNET per Peering ohne die Optionen Gateway des virtuellen Remotenetzwerks oder Route Server verwenden (im Spoke-VNET-Peering) und Gateway oder Route Server dieses virtuellen Netzwerks verwenden (Gatewaytransit im Hub-VNET-Peering) verbunden sind, kennen die Spoke-VNETs diese Routen nicht (weder die SDWAN-Präfixe noch die ExpressRoute-Präfixe).

Um Routen an die Spoke-VNets zu verteilen, nutzt die NVA einen Route Server 2, der in einem neuen unterstützenden VNet bereitgestellt wird. Die NVA verteilt nur eine einzelne 0.0.0.0/0-Route an Route Server 2. Da die Spoke-VNETs mit diesem zusätzlichen VNET mit den Optionen Gateway des virtuellen Remotenetzwerks oder Route Servers verwenden (im Spoke-VNET-Peering) und Gateway oder Route Server dieses virtuellen Netzwerks verwenden (Gatewaytransit im Hub-VNET-Peering) per Peering verbunden sind, lernen alle VMs in den Spokes die 0.0.0.0/0-Route.

Der nächste Hop für die Route 0.0.0.0/0 ist die NVA, sodass die Spoke-VNets weiterhin per Peering mit dem Hub-VNet verknüpft sein müssen. Ein weiterer wichtiger Aspekt ist, dass das Hub-VNet per Peering mit dem VNet mit dem Route Server 2 verknüpft werden muss, da andernfalls keine BGP-Adjazenz entstehen kann.

Wenn Datenverkehr von ExpressRoute an die Spoke-VNets zur Überprüfung an ein Firewall-NVA gesendet werden soll, ist weiterhin eine Routingtabelle in „GatewaySubnet“ erforderlich. Andernfalls sendet das ExpressRoute-Gateway für virtuelle Netzwerke Pakete über die vom VNET-Peering ermittelten Routen an VMs. Die Routen in dieser Routingtabelle müssen mit den Spokepräfixen übereinstimmen, und der nächste Hop muss der IP-Adresse des Firewall-NVA (oder aus Gründen der Redundanz dem Lastenausgleich vor den Firewall-NVAs) entsprechen. Das Firewall-NVA kann mit dem SDWAN-NVA im obigen Diagramm identisch sein, oder es kann sich um ein anderes Gerät wie Azure Firewall handeln, da das SDWAN-NVA Routen mit dem nächsten Hop ankündigen kann, der auf andere IP-Adressen verweist. Das folgende Diagramm zeigt diesen Entwurf zusätzlich mit Azure Firewall:

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.

Abbildung mit grundlegender Hub- und Spoke-Topologie mit lokaler Konnektivität über ExpressRoute, einer Azure Firewall und zwei Route Servern.

Dieser Entwurf ermöglicht das automatische Einfügen von Routen in Spoke-VNets ohne Störung durch andere Routen, die aus ExpressRoute, aus dem VPN oder aus einer SDWAN-Umgebung ermittelt wurden. Außerdem wurden Firewall-NVAs zur Untersuchung von Datenverkehr hinzugefügt.

Zugehöriger Inhalt