Bereitstellen von hoch verfügbaren NVAs

In diesem Artikel lernen Sie die typischen Methoden zum Bereitstellen mehrerer hochverfügbarer virtueller Netzwerkgeräte (Network Virtual Appliances, NVAs) in Azure kennen. Ein NVA wird meist verwendet, um den Fluss des Datenverkehrs zwischen Netzwerksegmenten zu steuern, die mit unterschiedlichen Sicherheitsstufen klassifiziert sind, z. B. zwischen einem virtuellen De-Militarized Zone(DMZ)-Netzwerk und dem öffentlichen Internet.

Es gibt eine Reihe von Entwurfsmustern, bei denen NVAs zum Überprüfen des Datenverkehrs zwischen verschiedenen Sicherheitszonen verwendet werden, z. B.:

• Um ausgehenden Datenverkehr von VMs in das Internet zu untersuchen und Datenexfiltration zu verhindern.
• So untersuchen Sie den eingehenden Datenverkehr aus dem Internet zu VMs und verhindern Angriffe.
• Zum Filtern des Datenverkehrs zwischen VMs in Azure, um die laterale Ausbreitung von Bedrohungen aus kompromittierten Systemen zu verhindern.
• Filtern des Datenverkehrs zwischen lokalen Systemen und Azure-VMs, wenn diese unterschiedlichen Sicherheitsstufen haben. (Beispiel: Azure hostet die DMZ und die internen Anwendungen werden lokal gehostet.)

Es gibt viele Beispiele für NVAs, z. B. Netzwerkfirewalls, Layer-4-Reverseproxys, IPsec-VPN-Endpunkte, webbasierte Reverseproxys mit Web Application Firewall-Funktionalität, Internetproxys zum Einschränken der von Azure aus zugänglichen Internetseiten oder Layer-7-Lastenausgleich. Alle können mit den in diesem Artikel beschriebenen Mustern in einem Azure-Design implementiert werden. Selbst virtuelle Netzwerkgeräte von Microsoft wie Azure Firewall und Azure Application Gateway verwenden die später in diesem Artikel erläuterten Entwürfe. Diese Optionen zu verstehen ist essenziell beim Umgebungsdesign und der Behebung von Netzwerkproblemen.

Die erste zu beantwortende Frage ist, warum Hochverfügbarkeit für virtuelle Netzwerkgeräte erforderlich ist. Der Grund dafür ist, dass diese Geräte die Kommunikation zwischen Netzwerksegmenten steuern. Wenn sie nicht verfügbar sind, kann der Netzwerkdatenverkehr nicht fließen, und Anwendungen funktionieren nicht mehr. Geplante und ungeplante Ausfälle können und werden gelegentlich NVA-Instanzen zum Ausfall bringen, wie es auch bei allen anderen VMs in Cloud-Diensten wie Azure der Fall ist. Die Instanzen werden auch dann abstürzen, wenn diese NVAs mit Premium Managed Disks konfiguriert sind, um eine Einzelinstanz-SLA in Azure zu bieten. Daher benötigen hoch verfügbare Anwendungen mindestens ein zweites NVA, das die Konnektivität sicherstellt.

Voraussetzungen: In diesem Artikel werden grundlegende Kenntnisse von Azure-Netzwerken, Azure-Lastenausgleichsmodulen und Routing von virtuellem Netzwerkdatenverkehr vorausgesetzt.

Bei der Auswahl der besten Option zum Bereitstellen eines virtuellen Netzwerkgeräts in einem Azure-VNet ist der wichtigste zu berücksichtigende Aspekt, ob der NVA-Anbieter dieses spezifische Design überprüft und validiert hat. Der Anbieter muss auch die erforderliche NVA-Konfiguration bereitstellen, die für die Integration des NVA in Azure erforderlich ist. Wenn der NVA-Anbieter verschiedene Alternativen als unterstützte Designoptionen für ein NVA anbietet, können folgende Faktoren die Entscheidung beeinflussen:

• Konvergenzzeit: Wie lange dauert es in jedem Design, bis der Datenverkehr von ausgefallenen NVA-Instanzen weggelenkt wird?
• Topologieunterstützung: Welche NVA-Konfigurationen werden von der jeweiligen Designoption unterstützt? Aktiv/Aktiv, Aktiv/Standby, horizontal skalierende NVA-Cluster mit n+1-Redundanz?
• Datenverkehrssymmetrie: Wird das NVA durch ein bestimmtes Design dazu gezwungen, die Quellnetzwerk-Adressenübersetzung (Source Network Address Translation, SNAT) für die Pakete durchzuführen, um asymmetrisches Routing zu vermeiden? Oder wird die Datenverkehrssymmetrie auf andere Weise durchgesetzt?

In den folgenden Abschnitten werden die gängigsten Architekturen zum Integrieren von NVAs in ein Hub-and-Spoke-Netzwerk beschrieben.

Übersicht über Hochverfügbarkeitsarchitekturen

In den folgenden Architekturen sind die für hochverfügbare NVAs erforderlichen Ressourcen und die Konfiguration angegeben:

Load Balancer-Design

Bei diesem Design werden zwei Azure Load Balancer (ALBs) verwendet, um einen Cluster von NVAs für den Rest des Netzwerks verfügbar zu machen:

• Ein interner Load Balancer wird verwendet, um internen Datenverkehr von Azure und der lokalen Umgebung an die NVAs umzuleiten. Dieser interne Lastenausgleich ist mit Hochverfügbarkeits-Portregeln konfiguriert, sodass jeder TCP/UDP-Port an die NVA-Instanzen umgeleitet wird.
• Ein öffentlicher Load Balancer verbindet die NVAs mit dem Internet. Da Hochverfügbarkeitsports für eingehenden Datenverkehr verwendet werden, muss jeder einzelne TCP/UDP-Port in einer dedizierten Lastenausgleichsregel geöffnet werden.

Das folgende Diagramm beschreibt die Sequenz von Hops, von Paketen aus dem Internet an einen Anwendungsserver in einem Spoke-VNet:

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenverkehr wird von Spokes mittels einer benutzerdefinierten Route für 0.0.0.0/0 über die NVAs an das öffentliche Internet gesendet, wobei „next-hop“ die IP-Adresse des internen Load Balancers ist.

Für den Datenverkehr zwischen Azure und dem öffentlichen Internet durchquert jede Richtung des Datenverkehrsflusses einen anderen Azure Load Balancer (das eingehende Paket über den öffentlichen ALB und das ausgehende Paket über den internen ALB). Wenn Datenverkehrssymmetrie erforderlich ist, muss daher die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) von den NVA-Instanzen durchgeführt werden, um den Rückgabedatenverkehr zu erhalten und asymmetrischen Datenverkehr zu vermeiden.

Dieses Design kann auch verwendet werden, um den Datenverkehr zwischen Azure und lokalen Netzwerken zu überprüfen:

Zwischen Spokes wird der Datenverkehr auf die gleiche Weise über NVAs gesendet, sodass kein zusätzliches Diagramm bereitgestellt wird. Da spoke1 in den obigen Beispieldiagrammen den Bereich von spoke2 nicht kennt, sendet die UDR 0.0.0.0/0 Datenverkehr, der an spoke2 adressiert ist, an den internen Azure Load Balancer.

Für den Datenverkehr zwischen lokalen Netzwerken und Azure oder zwischen Azure-VMs wird die Symmetrie des Datenverkehrs durch den internen Azure Load Balancer gewährleistet: Wenn beide Richtungen eines Datenverkehrsflusses denselben Azure Load Balancer durchlaufen, wird dieselbe NVA-Instanz ausgewählt.

Der Azure Load Balancer hat eine sehr gute Konvergenzzeit bei Ausfällen einzelner NVAs. Da Integritätstests alle 5 Sekunden gesendet werden können und es drei fehlgeschlagener Tests bedarf, um eine Back-End-Instanz als ausgefallen zu deklarieren, dauert es in der Regel 10 bis 15 Sekunden, bis der Azure Load Balancer Datenverkehr zu einer anderen NVA-Instanz konvergiert.

Dieses Setup unterstützt sowohl Aktiv/Aktiv- als auch Aktiv-/Standby-Konfigurationen. Für Aktiv/Standby-Konfigurationen müssen die NVA-Instanzen jedoch einen TCP/UDP-Port oder HTTP-Endpunkt anbieten, der nicht auf die Load Balancer-Integritätstests antwortet, es sei denn, die Instanz befindet sich in der aktiven Rolle.

Verwenden von L7-Lastenausgleichen

Ein bestimmter Fall dieses Designs ist das Ersetzen des öffentlichen Azure Load Balancer durch einen Layer-7-Lastenausgleich wie den Azure Application Gateway (der als eigenständiger NVA betrachtet werden kann). In diesem Fall benötigen die NVAs nur einen vorgeschalteten internen Load Balancer, da Datenverkehr aus der Application Gateway aus dem VNet stammt und asymmetrischer Datenverkehr kein Problem ist.

Das NVA sollte eingehenden Datenverkehr für Protokolle, die nicht von Ihrem Layer-7-Lastenausgleich unterstützt werden, sowie potenziell den sämtlichen ausgehenden Datenverkehr annehmen. Weitere Informationen zu dieser Konfiguration bei Verwendung von Azure Firewall als NVA und Azure Application Gateway als Layer-7-Web-Reverseproxy finden Sie unter Firewall und Application Gateway für virtuelle Netzwerke.

Azure Route Server

Azure Route Server ist ein Dienst, mit dem NVAs über das Border Gateway Protocol (BGP) mit Azure SDN interagieren können. Nicht nur erfahren die NVAs, welche IP-Präfixe in den Azure-VNets vorhanden sind, sondern sie können Routen in die effektiven Routentabellen der Azure-VMs injizieren.

Im obigen Diagramm wird für jede NVA-Instanz ein Peering über BGP mit dem Azure Route Server ausgeführt. In den Spokesubnetzen ist keine Routingtabelle erforderlich, da der Azure Route Server die von den NVAs angekündigten Routen programmiert. Wenn mindestens zwei Routen auf den Azure-VMs programmiert sind, wählen diese die NVA-Instanz für jeden Datenverkehrsfluss per Equal Cost MultiPathing (ECMP) aus. Daher ist SNAT in diesem Design ein Muss, wenn symmetrischer Datenverkehr erforderlich ist.

Diese Einfügemethode unterstützt sowohl Aktiv/Aktiv (alle NVAs kündigen die gleichen Routen zum Azure Route Server an) als auch Aktiv/Standby (eine NVA kündigt Routen mit einem kürzeren AS-Pfad als die andere an). Der Azure Route Server unterstützt maximal 8 BGP-Adjazenzen. Wenn Sie also einen horizontal skalierenden Cluster mit aktiven NVAs verwenden, unterstützt dieses Design maximal 8 NVA-Instanzen.

Die Konvergenzzeit ist bei dieser Konfiguration ziemlich schnell und wird durch die Keepalive- und Holdtime-Timer der BGP-Adjakenz beeinflusst. Während der Azure Route Server standardmäßig über Keepalive- und Holdtime-Timer verfügt (60 Sekunden bzw. 180 Sekunden), können die NVAs während der Einrichtung der BGP-Adjazienz niedrigere Timer aushandeln. Wenn diese Timer zu niedrig sind, kann dies zu BGP-Instabilitäten führen.

Dieses Design ist die gängigste Option für NVAs, die mit dem Azure-Routing interagieren müssen, z. B. NVAs für die VPN-Beendigung, die die in Azure-VNets konfigurierten Präfixe erlernen oder bestimmte Routen über private ExpressRoute-Peerings ankündigungen müssen.

Gateway Load Balancer

Azure Gateway Load Balancer ist eine neue Möglichkeit zum Einfügen von NVAs in den Datenpfad, ohne den Datenverkehr mit benutzerdefinierten Routen steuern zu müssen. Für VMs, die ihre Workloads über einen Azure Load Balancer oder eine öffentliche IP-Adresse verfügbar machen, kann ein- und ausgehender Datenverkehr transparent an einen Cluster von NVAs in einem anderen VNet umgeleitet werden. Das folgende Diagramm beschreibt den Pfad eingehender Pakete aus dem öffentlichen Internet, falls die Workloads die Anwendung über eine Azure Load Balancer verfügbar machen:

Einer der Hauptvorteile dieser NVA-Injektionsmethode ist, dass die Übersetzung von Quellnetzwerkadressen (Source Network Address Translation, SNAT) nicht für Datenverkehrssymmetrie erforderlich ist. Als weiterer Vorteil dieses Designs können dieselben NVAs verwendet werden, um den Datenverkehr an bzw. aus verschiedenen VNets zu überprüfen und somit Mehrinstanzenfähigkeit bieten. Zwischen dem NVA-VNet und den Workload-VNets ist kein VNet-Peering erforderlich, und im Workload-VNet sind keine benutzerdefinierten Routen erforderlich, was die Konfiguration erheblich vereinfacht.

Die Dienstinjektion mit dem Gateway Load Balancer kann für in öffentlichen Azure Load Balancers eingehende Datenflüsse (und deren Rückgabedatenverkehr) verwendet werden, sowie für ausgehende Datenflüsse, die aus Azure stammen. East-West Datenverkehr zwischen Azure-VMs kann die Gateway-Load Balancer nicht für NVA-Injektion nutzen.

Im NVA-Cluster werden Azure Load Balancer-Integritätsprüfungen verwendet, um einzelne NVA-Instanzfehler zu erkennen und so eine sehr schnelle Konvergenzzeit (10-15 Sekunden) zu erreichen.

Ändern der öffentlichen IP der benutzerdefinierten Route

Systeme mit diesem Design kommen ohne redundante NVAs aus und werden stattdessen geändert, wenn ein NVA ausfällt. Das folgende Diagramm zeigt, wie eine öffentliche Azure-IP-Adresse der aktiven NVA (NVA1) zugeordnet ist, und die IP-Adresse des aktiven virtuellen Netzwerks der nächste Hop (10.0.0.37) der benutzerdefinierten Routen ist.

Wenn das aktive NVA nicht mehr verfügbar ist, ruft das Standby-NVA die Azure-API auf, um die öffentliche IP-Adresse und die benutzerdefinierten Routen des Spoke sich selbst zuzuordnen (oder auch die private IP-Adresse zu verschieben). Es kann einige Minuten dauern, bis diese API-Aufrufe wirksam sind. Aus diesem Grund bietet dieses Design die schlechteste Konvergenzzeit aller Optionen in diesem Dokument.

Eine weitere Einschränkung dieses Designs ist, dass nur Aktiv/Standby-Konfigurationen unterstützt werden, was zu Skalierbarkeitsproblemen führen kann: Wenn Sie die Bandbreite erhöhen müssen, die von Ihren NVAs unterstützt wird, ist die einzige Option bei diesem Design das Hochskalieren beider Instanzen.

Ein Vorteil dieses Designs ist, dass keine Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) erforderlich ist, um die Symmetrie des Datenverkehrs zu gewährleisten, da immer nur ein NVA aktiv ist.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Keith Mayer | Principal Cloud Solution Architect
• Telmo Sampaio | Principal Service Engineering Manager

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Erfahren Sie, wie Sie mit der Azure Firewall ein sicheres Hybridnetzwerk implementieren.
• Umkreisnetzwerke – Cloud Adoption Framework
• Cloud-DMZ – Cloud Adoption Framework