Używanie Azure Firewall do kierowania 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ń. Piasta może służyć do izolowania i zabezpieczania ruchu między szprychami. Piasta może również służyć do kierowania ruchu między szprychami. Piasta 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 Azure Firewall i tras statycznych do kierowania ruchu między szprychami.

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

Architektura linii bazowej

Azure Firewall zabezpiecza i sprawdza ruch sieciowy, ale również kieruje ruchem 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ę Virtual Network. 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 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. W związku z tym koncentratory wiedzą o sobie nawzajem, a każda zapora lokalna zawiera tabelę tras każdego bezpośrednio połączonego koncentratora. Jednak lokalne koncentratory wiedzą tylko o swoich lokalnych szprychach. Ponadto te centra mogą znajdować się w tym samym regionie lub w innym regionie.

Routing w podsieci zapory

Każda zapora lokalna musi wiedzieć, jak uzyskać dostęp do innych zdalnych szprych, więc należy utworzyć trasy zdefiniowane przez użytkownika w podsieciach zapory. Aby to zrobić, należy najpierw utworzyć domyślną trasę 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 koncentratora:

Tabela tras Hub-01

Tabela tras Hub-02

Routing w podsieciach szprych

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

Jak pokazano na diagramie, lepiej umieścić trasę zdefiniowaną przez użytkownika w podsieciach szprych, które mają trasę 0/0 (brama domyślna) z zaporą lokalną jako następny przeskok. Powoduje to zablokowanie punktu wyjścia pojedynczego następnego przeskoku jako zapory lokalnej. Zmniejsza to również ryzyko routingu asymetrycznego, jeśli pozna 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 usługą Hub-01:

Następne kroki

• Dowiedz się, jak wdrożyć i skonfigurować Azure Firewall.