Bereitstellen von hoch verfügbaren NVAs

In diesem Artikel werden die am häufigsten verwendeten Optionen zum Bereitstellen einer Reihe von Netzwerk virtual Appliances (NVAs) für hohe Verfügbarkeit in Azure erläutert. Eine NVA wird in der Regel verwendet, um den Datenverkehr zwischen Netzwerksegmenten zu steuern, die mit verschiedenen Sicherheitsstufen klassifiziert wurden, z. B. zwischen einem virtuellen De-Militarized Zone (DMZ) und dem öffentlichen Internet oder zum Verbinden externer Standorte mit Azure, z. B. VPN- oder SDWAN (Software-Defined WAN)-Appliances.

Es gibt viele Entwurfsmuster, in denen NVAs verwendet werden, um den Datenverkehr zwischen verschiedenen Sicherheitszonen zu prüfen, z. B.:

• Um Datenverkehr von virtuellen Computern ins Internet zu prüfen und Datenexfiltration zu verhindern.
• Um den Datenverkehr aus dem Internet auf virtuelle Computer zu prüfen und Angriffe zu verhindern.
• Um den Datenverkehr zwischen virtuellen Computern in Azure zu filtern, um laterale Verschiebungen kompromittierter Systeme zu verhindern.
• Zum Filtern des Datenverkehrs zwischen lokalen Systemen und virtuellen Azure-Computern, wenn sie als unterschiedliche Sicherheitsstufen angesehen werden. (Wenn Azure z. B. die DMZ hostet und die internen Anwendungen lokal.)
• Um VPN- oder SDWAN-Tunnel von externen Standorten wie lokalen Netzwerken oder anderen öffentlichen Clouds zu beenden.

Es gibt viele Beispiele für NVAs, einschließlich der folgenden, unter anderem:

• Netzwerkfirewalls
• Layer-4-Reverseproxys
• IPsec VPN-Endpunkte
• SDWAN-Appliances
• Webbasierte Reverseproxys mit Webanwendungsfirewallfunktionen
• Internetproxys, um einzuschränken, auf welche Internetseiten über Azure zugegriffen werden kann
• Layer-7-Lastenausgleichsgeräte

Alle diese NVAs können in ein Azure-Design mit den in diesem Artikel beschriebenen Mustern eingefügt werden. Selbst azure first-party Network Virtual Appliances wie Azure Firewall und Azure Application Gateway verwenden die weiter unten in diesem Artikel erläuterten Designs. Das Verständnis dieser Optionen ist sowohl aus Entwurfssicht als auch bei der Problembehandlung von Netzwerkproblemen von entscheidender Bedeutung.

Die erste Frage, die beantwortet werden soll, ist, warum hohe Verfü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 führen gelegentlich zu NVA-Instanzen (wie jeder andere virtuelle Computer in Azure oder einer anderen Cloud). Die Instanzen werden heruntergestuft, auch wenn diese NVAs mit Premium Managed Disks konfiguriert sind, um eine SLA mit einer einzigen Instanz in Azure bereitzustellen. Daher erfordern hoch verfügbare Anwendungen mindestens eine zweite NVA, die die Konnektivität gewährleisten kann.

Voraussetzungen: In diesem Artikel wird ein grundlegendes Verständnis von Azure-Netzwerken, Azure Load Balancersund Virtual Network Traffic Routing (UDRs) vorausgesetzt.

Wenn Sie die beste Option für die Bereitstellung einer virtuellen Netzwerk-Appliance in einem Azure VNet auswählen, ist der wichtigste Aspekt, den Sie berücksichtigen sollten, ob der NVA-Anbieter dieses spezifische Design überprüft und überprüft hat. Der Anbieter muss auch die erforderliche NVA-Konfiguration bereitstellen, die erforderlich ist, um die NVA in Azure zu integrieren. Wenn der NVA-Anbieter verschiedene Alternativen als unterstützte Designoptionen für einen NVA anbietet, können diese Faktoren die Entscheidung beeinflussen:

• Konvergenzzeit: Wie lange dauert es in jedem Design, den Datenverkehr von einer fehlgeschlagenen NVA-Instanz zu lenken?
• Topologieunterstützung: Welche NVA-Konfigurationen unterstützt jede Designoption? Aktiv/aktiv, Aktiv/Standby, Scaleout-NVA-Cluster mit n+1 Redundanz?
• Datenverkehrssymmetrie: Erzwingt ein NVA, die Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) für die Pakete auszuführen, um asymmetrisches Routing zu vermeiden? Oder wird die Verkehrssymmetrie auf andere Wege erzwungen?

In den folgenden Abschnitten im Dokument werden die am häufigsten verwendeten Architekturen zum Integrieren von NVAs in ein Hub- und Spoke-Netzwerk beschrieben.

Übersicht über HA-Architekturen

Die folgenden Architekturen beschreiben die Ressourcen und Konfigurationen, die für hoch verfügbare NVAs erforderlich sind:

Lastenausgleichsdesign

Dieses Design verwendet zwei Azure Load Balancers, um einen Cluster von NVAs für den Rest des Netzwerks verfügbar zu machen. Der Ansatz wird häufig sowohl für zustands- als auch für zustandslose NVAs verwendet:

• Ein interner Lastenausgleich wird verwendet, um internen Datenverkehr von Azure und lokal an die NVAs umzuleiten. Dieser interne Lastenausgleich ist mit HA-Ports-Regelnkonfiguriert, sodass jeder TCP/UDP-Port an die NVA-Instanzen umgeleitet wird.
• Ein öffentlicher Lastenausgleich macht die NVAs für das Internet verfügbar. Da HA-Ports für eingehenden Datenverkehr bestimmt sind, muss jeder einzelne TCP/UDP-Port in einer dedizierten Lastenausgleichsregel geöffnet werden.

Das folgende Diagramm beschreibt die Abfolge von Hops, die pakete aus dem Internet auf einen Anwendungsserver in einem Speichen-VNet folgen würden, um den Datenverkehr zu/aus dem öffentlichen Internet (auch als Nord-/Süd-Datenverkehr bezeichnet) zu steuern:

Laden Sie eine Visio-Datei dieser Architektur herunter.

Der Mechanismus zum Senden von Datenverkehr von Speichen an das öffentliche Internet über die NVAs ist eine User-Defined Route für 0.0.0.0/0 mit dem nächsten Hop die IP-Adresse des internen Lastenausgleichs.

Für den Datenverkehr zwischen Azure und dem öffentlichen Internet überschreitet jede Richtung des Datenverkehrs einen anderen Azure Load Balancer. Dies tritt auch dann auf, wenn die Firewall-NVA über eine einzige NIC für die öffentlichen und internen Netzwerke verfügt, da das Eingangspaket die öffentliche ALB durchläuft und das Ausgangspaket die interne ALB durchläuft. Da beide Richtungen des Flusses durch verschiedene Lastenausgleichsgeräte geleitet werden, wenn die Datenverkehrssymmetrie erforderlich ist, wie in den meisten Firewalls der Fall ist, muss die Source Network Address Translation (SNAT) von den NVA-Instanzen ausgeführt werden, um den Rückgabedatenverkehr anzuziehen und die Datenverkehrsasymmetrie zu vermeiden.

Das gleiche Design mit Lastenausgleichsmodulen kann auch verwendet werden, um den Datenverkehr zwischen Azure und lokalen Netzwerken (Ost/West) zu prüfen, wobei nur ein interner Lastenausgleich beteiligt ist:

Der Mechanismus zum Senden von Datenverkehr zwischen Speichen über die NVAs ist identisch, sodass kein anderes Diagramm bereitgestellt wird. In den obigen Beispieldiagrammen, da "spoke1" nicht über den Bereich von Spoke2 weiß, sendet der 0.0.0.0/0 UDR Datenverkehr, der an "Spoke2" adressiert ist, an den internen Azure Load Balancer der NVA.

Für den Datenverkehr zwischen lokalen Netzwerken und Azure oder zwischen virtuellen Azure-Computern wird die Datenverkehrssymmetrie in single-NIC NVAs vom internen Azure Load Balancer garantiert: Wenn beide Richtungen eines Datenverkehrsflusses denselben Azure Load Balancer durchlaufen, wird dieselbe NVA-Instanz vom Lastenausgleich ausgewählt. Im Falle von Dual-NIC NVAs, bei denen es für jeden Kommunikationssinn einen internen Lastenausgleich gibt, muss die Verkehrssymmetrie über SNAT bereitgestellt werden, wie im obigen Beispiel "Nord/Süd".

Eine weitere Herausforderung, die dual-NIC NVAs in diesem Entwurf gegenüberstehen, ist das Senden der Antworten auf die Integritätsprüfungen des Lastenausgleichs. Azure Load Balancer verwendet immer dieselbe IP-Adresse wie quelle für die Integritätsprüfungen (168.63.129.16). Die NVA muss in der Lage sein, die Antwort an die von dieser IP-Adresse stammende Integritätsprüfung auf derselben Schnittstelle zu senden, die sie empfangen haben. Dies erfordert in der Regel mehrere Routingtabellen in einem Betriebssystem, da das zielbasierte Routing die Antwort immer über dieselbe NIC sendet.

Der Azure Load Balancer hat eine gute Konvergenzzeit in einzelnen NVA-Ausfällen. Da die Integritätssonden alle 5 Sekunden gesendet werden können und es 3 fehlgeschlagene Probes dauert, um eine Back-End-Instanz außerhalb des Diensts zu deklarieren, dauert es in der Regel 10-15 Sekunden, bis der Azure Load Balancer den Datenverkehr zu einer anderen NVA-Instanz konvergent.

Dieses Setup unterstützt sowohl aktive als auch aktive/Standby-Konfigurationen. Bei Active/Standby-Konfigurationen müssen die NVA-Instanzen einen TCP/UDP-Port oder HTTP-Endpunkt anbieten, der nur auf die Integritätssonden für den Lastenausgleich für die Instanz reagiert, die sich in der aktiven Rolle befindet.

Verwenden von L7-Lastenausgleichsmodulen

Ein besonderer Fall dieses Designs für Sicherheitsgeräte ist das Ersetzen des öffentlichen Lastenausgleichs von Azure durch einen Layer-7-Lastenausgleichsmodul wie das Azure-Anwendungsgateway (der als NVA eigenständig betrachtet werden kann). Für diesen Fall benötigen die NVAs nur einen internen Lastenausgleich für Datenverkehr, der von den Workloadsystemen stammt. Dieser Mechanismus wird manchmal von Dual-NIC-Geräten verwendet, um das Routingproblem mit den Im vorherigen Abschnitt beschriebenen Integritätsprüfungen des Azure Load Balancer zu vermeiden. Eine Einschränkung dieses Designs besteht darin, dass es nur die Layer-7-Protokolle unterstützt, die vom Layer-7-Lastenausgleich unterstützt werden, in der Regel HTTP(S).

Der NVA sollte eingehenden Datenverkehr für Protokolle übernehmen, die von Ihrem Layer-7-Lastenausgleich nicht unterstützt werden, sowie potenziell alle Ausgehenden Datenverkehr. Weitere Details 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, der es einer NVA ermöglicht, mit Azure SDN über das Border Gateway Protocol (BGP) zu interagieren. Die NVAs lernen nicht nur, welche IP-Präfixe in den Azure-VNets vorhanden sind, sondern sie können Routen in die effektiven Routentabellen der virtuellen Computer in Azure einfügen.

Im Diagramm oben wird jede NVA-Instanz über BGP mit dem Azure Route Server peered. In den Speichensubnetzen ist keine Routentabelle erforderlich, da Azure Route Server die von den NVAs angekündigten Routen programmiert. Wenn zwei oder mehr Routen auf den virtuellen Azure-Computern programmiert sind, verwenden sie Equal Cost MultiPathing (ECMP), um eine der NVA-Instanzen für jeden Datenverkehrsfluss auszuwählen. Daher ist SNAT ein Muss in diesem Design, wenn die Verkehrssymmetrie eine Anforderung ist.

Diese Einfügemethode unterstützt sowohl aktiv/aktiv (alle NVAs werben für die gleichen Routen an den Azure Route Server) als auch aktiv/standby (ein NVA kündigt Routen mit einem kürzeren AS-Pfad an als der andere). Der Azure Route-Server unterstützt maximal 8 BGP-Adjacencies. Daher unterstützt dieses Design bei Verwendung eines Scaleoutclusters aktiver NVAs maximal 8 NVA-Instanzen.

Die Konvergenzzeit ist in diesem Setup schnell und wird von den Keepalive- und Holdtime-Timern der BGP-Adjacency beeinflusst. Während der Azure Route Server Standardmäßige Keepalive- und Holdtime-Timer (60 Sekunden bzw. 180 Sekunden) aufweist, können die NVAs niedrigere Timer während der BGP-Adjacency-Einrichtung aushandeln. Das Festlegen dieser Zeitgeber zu niedrig könnte zu BGP-Instfähigkeiten führen.

Dieses Design ist die am häufigsten verwendete Option für NVAs, die mit Azure-Routing interagieren müssen, z. B. SDWAN oder IPsec NVAs, die normalerweise über eine gute BGP-Unterstützung verfügen und die in Azure VNets konfigurierten Präfixe erlernen oder bestimmte Routen über private ExpressRoute-Peerings bewerben müssen. Diese Art von Appliances ist in der Regel zustandslos, sodass die Verkehrssymmetrie kein Problem ist und SNAT nicht erforderlich ist.

Gateway Load Balancer

Azure Gateway Load Balancer ist eine neue Möglichkeit, NVAs in den Datenpfad einzufügen, ohne den Datenverkehr mit User-Defined Routen zu steuern. Für virtuelle Computer, die ihre Workloads über einen Azure Load Balancer oder eine öffentliche IP-Adresse verfügbar machen, können eingehende und ausgehende Datenverkehr transparent an einen Cluster von NVAs umgeleitet werden, die sich in einem anderen VNet befinden. Das folgende Diagramm beschreibt den Pfad, dem Pakete für eingehenden Datenverkehr aus dem öffentlichen Internet folgen, falls die Workloads die Anwendung über einen Azure Load Balancer verfügbar machen:

Einer der Hauptvorteile dieser NVA-Injektionsmethode besteht darin, dass die Source Network Address Translation (SNAT) nicht erforderlich ist, um die Datenverkehrssymmetrie zu gewährleisten. Ein weiterer Vorteil dieser Entwurfsoption besteht darin, dass die gleichen NVAs verwendet werden können, um datenverkehrs- und aus verschiedenen VNets zu prüfen und somit aus NVA-Sicht mehrinstanzenfähige Mandanten zu erreichen. Es ist kein VNet-Peering zwischen dem NVA-VNet und den Workload-VNets erforderlich, und es sind keine User-Defined Routen in der Workload-VNet erforderlich, wodurch die Konfiguration erheblich vereinfacht wird.

Die Diensteinfügung mit dem Gateway-Lastenausgleichsmodul kann für eingehende Flüsse verwendet werden, die auf einen öffentlichen Azure Load Balancer (und deren Rückgabedatenverkehr) und für ausgehende Flüsse, die in Azure stammen, getroffen werden. East-West Datenverkehr zwischen virtuellen Azure-Computern kann das Gateway load Balancer für die NVA-Einfügung nicht nutzen.

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

Ändern von PIP-UDR

Die Idee hinter diesem Design besteht darin, die Einrichtung zu haben, die ohne NVA-Redundanz erforderlich wäre, und es geändert zu haben, falls die NVA unter Ausfallzeiten leidet. Das folgende Diagramm zeigt, wie eine öffentliche Azure-IP-Adresse dem aktiven NVA (NVA1) zugeordnet ist, und die User-Defined Routen in den Speichen haben die IP-Adresse des aktiven NVA als nächsten Hop (10.0.0.37).

Wenn der aktive NVA nicht verfügbar wurde, ruft die Standby-NVA die Azure-API auf, um die öffentliche IP-Adresse neu zuzuordnen und die Speichen User-Defined Routes an sich selbst (oder verschieben Sie auch die private IP-Adresse). Diese API-Aufrufe können einige Minuten dauern, um effektiv zu sein. Deshalb bietet dieses Design die schlechteste Konvergenzzeit aller Optionen in diesem Dokument.

Eine weitere Einschränkung dieses Designs besteht darin, dass nur aktive/Standby-Konfigurationen unterstützt werden, was zu Skalierbarkeitsproblemen führen kann: Wenn Sie die von Ihren NVAs unterstützte Bandbreite erhöhen müssen, wird die einzige Option mit diesem Design beide Instanzen skaliert.

Ein Vorteil dieses Designs ist, dass keine Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) erforderlich ist, um die Datenverkehrssymmetrie zu gewährleisten, da zu einem bestimmten Zeitpunkt nur ein NVA aktiv ist.

Beitragende

Dieser Artikel wird von Microsoft verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.

Hauptautoren:

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

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

Nächste Schritte

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