Udostępnij za pośrednictwem


Używanie usługi Azure Firewall do wyznaczania tras w topologii z wieloma piastami i szprychami

Topologia piasty i szprych jest typowym wzorcem architektury sieci na platformie Azure. Piasta to sieć wirtualna (VNet) na platformie Azure, która działa jako punkt centralny łączności z Twoją siecią lokalną. Szprychy są sieciami wirtualnymi równorzędnymi z piastą i mogą być używane do izolowania obciążeń. Koncentrator może służyć do izolowania i zabezpieczania ruchu między szprychami. Koncentrator może również służyć do kierowania ruchu między szprychami. Koncentrator może służyć do kierowania ruchu między szprychami przy użyciu różnych metod.

Na przykład można użyć usługi Azure Route Server z dynamicznym routingiem i wirtualnymi urządzeniami sieciowymi (WUS), aby kierować ruch między szprychami. Może to być dość złożone wdrożenie. Mniej złożona metoda używa usługi Azure Firewall i tras statycznych do kierowania ruchu między szprychami.

W tym artykule pokazano, jak za pomocą usługi Azure Firewall ze statycznymi trasami zdefiniowanymi przez użytkownika (UDR) kierować topologię z wieloma piastami i szprychami. Na poniższym diagramie przedstawiono topologię:

Diagram koncepcyjny przedstawiający architekturę piasty i szprych.

Architektura linii bazowej

Usługa Azure Firewall zabezpiecza i sprawdza ruch sieciowy, ale również kieruje ruch między sieciami wirtualnymi. Jest to zasób zarządzany, który automatycznie tworzy trasy systemowe do lokalnych szprych, piasty i prefiksów lokalnych poznanych przez lokalną bramę sieci wirtualnej. Umieszczenie urządzenia WUS w centrum i wykonywanie zapytań dotyczących obowiązujących tras spowodowałoby utworzenie tabeli tras podobnej do tego, co można znaleźć w usłudze Azure Firewall.

Ponieważ jest to architektura routingu statycznego, najkrótszą ścieżką do innego koncentratora można wykonać przy użyciu globalnej komunikacji równorzędnej sieci wirtualnych między koncentratorami. Koncentratory znają się nawzajem, a każda lokalna zapora zawiera tabelę tras każdego bezpośrednio połączonego koncentratora. Jednak lokalne koncentratory wiedzą tylko o swoich lokalnych szprychach. Ponadto te koncentratory mogą znajdować się w tym samym regionie lub w innym regionie.

Routing w podsieci zapory

Każda lokalna zapora musi wiedzieć, jak uzyskać dostęp do innych zdalnych szprych, więc należy utworzyć trasy zdefiniowane przez użytkownika w podsieciach zapory. W tym celu należy najpierw utworzyć trasę domyślną dowolnego typu, która następnie umożliwia tworzenie bardziej szczegółowych tras do innych szprych. Na przykład na poniższych zrzutach ekranu przedstawiono tabelę tras dla dwóch sieci wirtualnych piasty:

Tabela tras Hub-01Zrzut ekranu przedstawiający tabelę tras dla węzła Hub-01.

Tabela tras Hub-02Zrzut ekranu przedstawiający tabelę tras dla centrum-02.

Routing w podsieciach szprych

Zaletą implementacji tej topologii jest to, że z ruchem przechodzącym z jednego koncentratora do drugiego można uzyskać następny przeskok połączony bezpośrednio za pośrednictwem globalnej komunikacji równorzędnej.

Jak pokazano na diagramie, lepiej jest umieścić trasę zdefiniowaną przez użytkownika w podsieciach szprych, które mają trasę 0/0 (bramę domyślną) z zaporą lokalną jako następny przeskok. Spowoduje to zablokowanie punktu wyjścia następnego przeskoku jako zapory lokalnej. Zmniejsza to również ryzyko routingu asymetrycznego, jeśli dowiesz się bardziej szczegółowe prefiksy ze środowiska lokalnego, które mogą spowodować obejście ruchu przez zaporę. Aby uzyskać więcej informacji, zobacz Nie pozwól na ugryzienie tras platformy Azure.

Oto przykładowa tabela tras dla podsieci szprych połączonych z hub-01:

Zrzut ekranu przedstawiający tabelę tras dla podsieci szprych.

Następne kroki