Verwenden von Azure Firewall zum Weiterleiten einer Multi-Hub-and-Spoke-Topologie
Die Hub-and-Spoke-Topologie ist ein gängiges Netzwerkarchitekturmuster in Azure. Bei einem Hub handelt es sich um ein virtuelles Netzwerk (VNET) in Azure, das als zentraler Konnektivitätspunkt für Ihr lokales Netzwerk fungiert. Bei Speichen handelt es sich um VNETs, die eine Peerverbindung mit dem Hub herstellen und zur Isolierung von Workloads verwendet werden können. Der Hub kann verwendet werden, um Datenverkehr zwischen Spokes zu isolieren und zu schützen. Der Hub kann auch zum Weiterleiten von Datenverkehr zwischen Spokes verwendet werden. Der Hub kann verwendet werden, um Datenverkehr unter Verwendung verschiedener Methoden zwischen Spokes weiterzuleiten.
Sie können beispielsweise Azure Route Server mit dynamischem Routing und virtuellen Netzwerk-Appliances (NVAs) verwenden, um Datenverkehr zwischen Spokes weiterzuleiten. Dies kann eine recht komplexe Bereitstellung sein. Eine weniger komplexe Methode verwendet Azure Firewall und statische Routen, um Datenverkehr zwischen Spokes weiterzuleiten.
In diesem Artikel erfahren Sie, wie Sie Azure Firewall mit statischen benutzerdefinierten Routen (UDRs) verwenden können, um eine Multi-Hub-and-Spoke-Topologie weiterzuleiten. Diese Topologie wird im folgenden Diagramm veranschaulicht:
Baselinearchitektur
Azure Firewall schützt und untersucht den Netzwerkdatenverkehr, leitet aber auch Datenverkehr zwischen VNets weiter. Es handelt sich um eine verwaltete Ressource, die automatisch Systemrouten an die lokalen Spokes, den Hub und die lokalen vom lokalen Gateway des virtuellen Netzwerks gelernten Präfixe erstellt. Das Platzieren eines NVA auf dem Hub und das Abfragen der effektiven Routen würde zu einer Routingtabelle führen, die der Routentabelle in Azure Firewall ähnelt.
Da es sich um eine statische Routingarchitektur handelt, kann der kürzeste Weg zu einem anderen Hub mithilfe des globalen VNet-Peerings zwischen den Hubs erfolgen. Die Hubs wissen also voneinander, und jede lokale Firewall enthält die Routingtabelle aller direkt verbundenen Hubs. Die lokalen Hubs kennen jedoch nur ihre lokalen Spokes. Darüber hinaus können sich diese Hubs in derselben Region oder einer anderen Region befinden.
Routing im Firewallsubnetz
Jede lokale Firewall muss wissen, wie sie die anderen Remote-Spokes erreichen kann. Daher müssen Sie UDRs in den Firewallsubnetzen erstellen. Dazu müssen Sie zunächst eine Standardroute eines beliebigen Typs erstellen, um anschließend spezifischere Routen für die anderen Spokes erstellen zu können. Die folgenden Screenshots zeigen beispielsweise die Routingtabelle für die beiden Hub-VNets:
Hub-01-Routingtabelle
Hub-02-Routingtabelle
Routing für die Spoke-Subnetze
Der Vorteil der Implementierung dieser Topologie besteht darin, dass Sie bei Datenverkehr von einem Hub zum anderen den nächsten direkt über das globale Peering verbundenen Hop erreichen.
Wie im Diagramm dargestellt, ist es besser, eine UDR in den Spoke-Subnetzen zu platzieren, die eine 0/0-Route (Standardgateway) mit der lokalen Firewall als nächstem Hop aufweisen. Dadurch wird der einzelne Exitknoten des nächsten Hops als lokale Firewall festgelegt. Gleichermaßen wird das Risiko eines asymmetrischen Routings verringert, wenn spezifischere Präfixe aus Ihrer lokalen Umgebung gelernt werden, durch die der Datenverkehr die Firewall umgehen könnte. Weitere Informationen finden Sie unter Lassen Sie sich nicht von Azure Routes austricksen.
Hier sehen Sie eine Beispielroutingtabelle für die mit Hub-01 verbundenen Spoke-Subnetze:
Nächste Schritte
- Erfahren Sie, wie Sie eine Azure Firewall bereitstellen und konfigurieren.