Die Cloud verändert die Art und Weise, wie Infrastruktur entwickelt wird. Dazu zählt auch das Design von Firewalls, da das Netzwerk nicht mehr physisch ist und sich nicht mehr in virtuellen LANs befindet. Nicht alle Funktionen eines physischen Netzwerks sind in einem virtuellen Netzwerk (VNet) verfügbar. Dies schließt die Verwendung von Floating IP-Adressen oder Broadcastdatenverkehr ein, was sich auf die Implementierung von Hochverfügbarkeitsarchitekturen auswirkt. Lastenausgleichsmodule für virtuelle Netzwerkgeräte (Network Virtual Appliances, NVAs) können auf eine bestimmte Weise implementiert werden, um eine Hochverfügbarkeitsarchitektur in einem virtuellen Netzwerk zu erzielen. In diesem Leitfaden wird ein strukturierter Ansatz zum Entwerfen von Hochverfügbarkeitsfirewalls (FWs) in Azure mithilfe von virtuellen Geräten von Drittanbietern vorgestellt.
Optionen zum Entwerfen von hochverfügbaren NVAs
Beim Bereitstellen von Hochverfügbarkeitsarchitekturen gibt es einige Optionen für ein Failover:
- Von der Azure-API verwaltete Routingtabellen: Bei dieser Option werden zwei Routingtabellen verwendet: eine aktive und eine passive zum Umschalten der aktiven Gateway-IP-Adresse für alle Dienste, die in einem VNET/Subnetz ausgeführt werden.
- Von der Azure-API verwaltete Floating-IP: Bei dieser Option wird eine sekundäre IP-Adresse auf den Firewalls verwendet, die zwischen einer aktiven Firewall und einer Standbyfirewall verschoben werden kann.
- Vom Load Balancer verwaltet: Bei dieser Option wird ein Azure Load Balancer verwendet, der als Gateway-IP-Adresse für das Subnetz fungiert und anschließend den Datenverkehr an die aktive Firewall weiterleitet. Es ist auch eine Aktiv/Aktiv-Weiterleitung des Datenverkehrs möglich, um einen richtigen Lastenausgleich zu ermöglichen.
Das Problem bei den ersten beiden Optionen besteht darin, dass das Failover selbst langsam ist. Die Firewall muss das Failover „anweisen“. Dies ist im Prinzip eine Neukonfiguration der Azure-Dienste über eine neue Bereitstellung. Die Datenflüsse fallen für ein paar Minuten aus, je nachdem, wie schnell die Bereitstellung abgeschlossen ist. Außerdem ist keine Aktiv/Aktiv-Konfiguration möglich, bei der beide Firewalls gleichzeitig in Betrieb sind.
Die dritte Option ist daher die bevorzugte. Die Ausfallzeit wird minimiert, da der Lastenausgleich nahezu umgehend ein Failover auf die Standbyfirewall (Aktiv/Passiv) durchführen oder die Last von der fehlerhaften Firewall entfernen kann (Aktiv/Aktiv). Es ist jedoch nicht möglich, Lastenausgleichsmodule als „Standardgateways“ zu verwenden, da sie sich auf den Datenfluss auswirken und TCP-Pakete zustandsbehaftet sein müssen.
Zweibeinige Firewalls
Das folgende Bild beginnt mit zwei Firewalls (FW-1 und FW-2) mit einem externen Lastenausgleich und einem Back-End-Server S1.
Bei der Architektur handelt es sich um ein einfaches Setup, das für den eingehenden Datenverkehr verwendet wird. Ein Paket trifft auf den Lastenausgleich, der die Zielfirewall aus der Konfiguration auswählt. Die ausgewählte Firewall sendet den Datenverkehr anschließend an den Back-End-Server (Web). Wenn für FW-1 SNAT aktiviert ist, wird der eingehende Datenverkehr von der internen IP-Adresse von FW-1 auf Server S1 angezeigt, und die Antwort an das Paket wird daher an FW-1 gesendet. Das Failover kann in diesem Szenario schnell in FW-2 erfolgen. Für den ausgehenden Verkehr könnten wir einen weiteren Lastenausgleich auf der internen Seite hinzufügen. Wenn Server S1 Datenverkehr startet, gilt das gleiche Prinzip. Der Datenverkehr erreicht den internen Lastenausgleich (internal Load Balancer, iLB), der eine Firewall auswählt, die dann eine NAT-Übersetzung für die externe Auflösung ausführt:
Dreibeinige Firewalls
Probleme treten auf, wenn wir der Firewall eine weitere Schnittstelle hinzufügen und Sie die NAT-Übersetzung zwischen internen Zonen deaktivieren müssen. In diesem Fall finden Sie weitere Informationen unter Subnetz-B und Subnetz-C:
Für das L3-Routing zwischen den internen Zonen (Subnetz B und Subnetz C) wird ein Lastenausgleich ohne NAT ausgeführt. Dieses Setup wird deutlich bei Betrachtung der Datenströme mit den Lastenausgleichsmodulen in einer anderen Ansicht. Das folgende Diagramm zeigt eine Ansicht, in der die internen Lastenausgleichsmodule (internal Load Balancer, iLB) mit einer bestimmten NIC auf den Firewalls verknüpft sind:
Bei L3-Datenverkehr (ohne NAT) sieht S2 die IP-Adresse von S1 als Quelladresse. S2 sendet dann den Antwortdatenverkehr für Subnetz B (zu dem S1-IP gehört) an den iLB in Subnetz-C. Da die iLBs in Subnetz B und Subnetz C ihre Sitzungszustände nicht synchronisieren, kann der Datenverkehr je nach Lastenausgleichsalgorithmus zu FW-2 gelangen. FW-2 kennt das anfängliche (grüne) Paket standardmäßig nicht und löscht daher die Verbindung.
Einige Firewallhersteller versuchen, einen Verbindungsstatus zwischen den Firewalls beizubehalten, dabei ist jedoch eine fast unmittelbare Synchronisierung erforderlich, damit die Verbindungszustände aktuell sind. Wenden Sie sich an den Hersteller der Firewall, wenn dieser ein solches Setup empfiehlt.
Die beste Möglichkeit, um mit diesem Problem umzugehen, besteht darin, es zu beheben. Im obigen Beispiel bedeutet diese Lösung, dass Sie Subnetz C eliminieren, wodurch wir die Vorteile virtualisierter VNets erhalten.
Isolieren von Hosts in einem Subnetz mit Netzwerksicherheitsgruppen
Wenn sich zwei VMs in einem einzelnen Subnetz befinden, können Sie eine Netzwerksicherheitsgruppe (NSG) anwenden, die den Datenverkehr zwischen den beiden isoliert. Datenverkehr innerhalb eines VNet ist vollumfänglich zulässig. Durch das Hinzufügen einer Deny all-Regel (Alle ablehnen) in der NSG werden alle virtuellen Computer voneinander isoliert.
VNets verwenden dieselben (virtuellen) Back-End-Router
VNets/Subnetze verwenden ein einzelnes Back-End-Routersystem von Azure. Daher ist es nicht erforderlich, für jedes Subnetz eine Router-IP anzugeben. Das Routingziel kann sich an einer beliebigen Stelle im gleichen VNet oder sogar außerhalb befinden.
Mit den virtualisierten Netzwerken können Sie die Routen in jedem Subnetz kontrollieren. Diese Routen können auch auf eine einzelne IP-Adresse in einem anderen Subnetz verweisen. In der obigen Abbildung ist das der interne Lastenausgleich in Subnetz D, der einen Lastenausgleich für die beiden Firewalls ausführt. Da S1 den Datenverkehr startet (grün), wird der Lastenausgleich beispielsweise für FW-1 durchgeführt. FW-1 stellt anschließend eine Verbindung mit S2 her (immer noch grün). S2 sendet den Antwortdatenverkehr an die IP von S1 (da NAT deaktiviert ist). Aufgrund der Routingtabellen verwendet S2 die gleiche iLB-IP wie das Gateway. Der iLB stimmt möglicherweise mit dem Datenverkehr der ersten Sitzung überein, sodass dieser Datenverkehr immer wieder auf FW-1 verweist. FW-1 sendet ihn dann an S1 und richtet einen synchronen Datenverkehrsfluss ein.
Damit dieses Setup funktioniert, muss die FW über eine Routingtabelle (intern) verfügen, die Subnetz-B und Subnetz-C auf sein Standardsubnetz-GW verweist. Dieses Subnetz-GW ist die erste logisch verfügbare IP-Adresse im Subnetzbereich in diesem VNet.
Auswirkungen auf Reverseproxydienste
Wenn Sie einen Reverseproxydienst bereitstellen, würde er sich normalerweise hinter der FW befinden. Stattdessen können Sie ihn in einer Reihe mit der FW platzieren und den Datenverkehr tatsächlich durch die FW weiterleiten. Der Vorteil dieses Setups besteht darin, dass dem Reverseproxydienst die ursprüngliche IP-Adresse des Clients angezeigt wird, der die Verbindung herstellt:
Für diese Konfiguration müssen die Routingtabellen in Subnetz-E über den internen Lastenausgleich auf Subnetz-B und Subnetz-C verweisen. Einige Reverseproxydienste verfügen über integrierte Firewalls, die es Ihnen ermöglichen, die FW in diesem Netzwerkdatenfluss ganz zu entfernen. Die integrierten Firewalls verweisen direkt vom Reverseproxy auf Subnetz-B/C-Server.
In diesem Szenario ist SNAT auch auf den Reverseproxys erforderlich, um zu vermeiden, dass der Antwortdatenverkehr weitergeleitet und von den Firewalls an Subnetz A verweigert wird.
VPN/ER
Azure stellt über die Azure Virtual Network Gateways BGP-aktivierte/hochverfügbare VPN/ER-Dienste bereit. Die meisten Architekten behalten diese für Back-End-Verbindungen oder für Verbindungen ohne Internetzugriff bei. Dieses Setup bedeutet, dass Routingtabelle auch die Subnetze hinter diesen Verbindungen umfassen muss. Es gibt zwar keinen großen Unterschied bei der Konnektivität von Subnetz-B/C, beim Design des Antwortdatenverkehrs jedoch schon:
In dieser Architektur wird der Datenverkehr z. B. von Subnetz B an Subnetz X, der auf die Firewall trifft, an den internen Lastenausgleich gesendet, der ihn wiederum an die Firewalls sendet. Die interne Route in der Firewall sendet den Datenverkehr zurück an Subnetz GW (die erste verfügbare IP in Subnetz-D). Sie müssen den Datenverkehr nicht direkt an die Gateway-Appliance senden, da eine andere Route in Subnetz D über eine Route für Subnetz X verfügt, über die er an das Gateway des virtuellen Netzwerks verwiesen wird. Azure-Netzwerke kümmern sich um das Routing.
Der von Subnetz-X kommende Antwortdatenverkehr wird an den iLB in Subnetz-D weitergeleitet. Das GatewaySubnet verfügt auch über eine benutzerdefinierte Route, die Subnetz-B-C auf den iLB verweist. Subnetz-D läuft nicht über den iLB. Dies wird als reguläres Inter-VNET-Routing behandelt.
In der Zeichnung ist dies nicht abgebildet, aber es wäre ggf. sinnvoll, wenn Subnetz B/C/D/Gateway auch eine Route für Subnetz A umfasst, die es auf den iLB verweist. Durch diese Anordnung wird das „reguläre“ VNET-Routing vermieden, um die Firewalls zu umgehen. Dem Azure-Netzwerkstapel entsprechend ist Subnetz A nämlich nur ein weiteres Subnetz im VNET. Subnetz-A wird nicht anders behandelt, auch wenn Sie es als Umkreisnetzwerk/Internet/usw. behandeln.
Zusammenfassung
Kurz gesagt: Die Art und Weise, wie Sie Firewalls in Ihren lokalen Netzwerken (physisch/VLAN-basiert) mit so vielen Schnittstellen (virtuell oder physisch) behandeln, unterscheidet sich von der Herangehensweise in Azure. Bei Bedarf ist das zwar (bis zu einem gewissen Grad) möglich, aber es gibt bessere Möglichkeiten, wie Sie Ausfallzeiten minimieren können, wie etwa Aktiv/Aktiv-Implementierungen und bereinigte Routingtabellen.
Weitere Informationen zur Verwendung von Lastenausgleichsmodulen als Gateways für den gesamten Datenverkehr finden Sie unter Übersicht über Hochverfügbarkeitsports.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautor:
- Roelf Zomerman | Senior Cloud Solution Architect
Nächste Schritte
Erfahren Sie mehr über die Komponententechnologien:
Zugehörige Ressourcen
Erkunden Sie die verwandten Architekturen: