Kierowanie topologii z wieloma piastami i szprychami przy użyciu usługi Azure Firewall

Topologia piasty i szprych jest typowym wzorcem architektury sieci na platformie Azure, który konsoliduje zasoby sieciowe i centralizuje usługi sieciowe. Ta topologia zapewnia łączność sieciową i bezpieczeństwo sieci wirtualnych wdrożonych w różnych subskrypcjach lub tenantach.

Architekturę typu hub-and-spoke da się zaimplementować na dwa sposoby:

• Samodzielnie zarządzany schemat hub-and-spoke (tradycyjny): Zachowujesz pełną kontrolę nad sieciami wirtualnymi i konfiguracją routingu koncentratora.
• Wirtualna sieć WAN: firma Microsoft zarządza sieciami wirtualnymi centrum i upraszcza administrację za pośrednictwem funkcji, takich jak intencja routingu i zasady routingu.

Ten artykuł koncentruje się na samodzielnie zarządzanych topologiach typu hub-and-spoke, w których masz pełną widoczność i kontrolę nad siecią wirtualną piasty oraz wdrażaniem Azure Firewall.

Możesz zmniejszyć koszty administracyjne związane z samodzielną implementacją piasty i szprych przy użyciu usługi Azure Virtual Network Manager (AVNM). AVNM może automatyzować konfigurację tabel tras, ale ogólny projekt i techniki nie zmieniają się w porównaniu do podejścia ręcznego. Zawartość tego artykułu ma zastosowanie w przypadku, gdy używasz AVNM lub ręcznie konfigurujesz topologię sieciową typu hub-and-spoke.

Alternatywą dla tablic tras w sieciach wirtualnych typu spoke jest wstrzykiwanie tras do podsieci przy użyciu usługi Azure Route Server, jak opisano w Domyślne wstrzykiwanie tras w sieciach wirtualnych typu spoke. Jednak ten wzorzec nie jest powszechnie stosowany ze względu na złożoność, jaka może wynikać z interakcji między Azure Route Server a bramami sieci VPN lub ExpressRoute.

W samodzielnie zarządzanym systemie piasta-szprycha:

• Hub: Wirtualna sieć, która służy jako centralny punkt połączenia z siecią lokalną za pośrednictwem VPN, ExpressRoute lub szerokopasmowej sieci definiowanej programowo (SD-WAN). Wdrażasz urządzenia zabezpieczające sieci, takie jak zapory sieciowe, w wirtualnej sieci hub.
• Szprychy: sieci wirtualne połączone z koncentratorem i hostujące obciążenia.

W przypadku obciążeń rozmieszczonych w wielu regionach zwykle wdraża się jeden koncentrator na region w celu agregowania ruchu ze szprych w tym regionie. Na poniższym diagramie przedstawiono dwuregionową, samodzielnie zarządzaną architekturę z centralnym węzłem (hub) i odgałęzieniami (spokes) z dwiema wirtualnymi sieciami szprych w każdym regionie.

Diagram topologii sieci typu hub-and-spoke z dwoma regionami, z których każdy zawiera sieć wirtualną typu hub z usługą Azure Firewall i dwiema sieciami wirtualnymi typu spoke.

Architektura hub-and-spoke dla pojedynczego regionu

Aby zrozumieć projekt obejmujący wiele regionów, należy najpierw zrozumieć pojęcia dotyczące jednego regionu. Na poniższym diagramie przedstawiono konfigurację tabeli routingu dla pierwszego regionu:

Należy wziąć pod uwagę wymagania dotyczące routingu dla każdego potencjalnego przepływu ruchu w projekcie pojedynczego regionu, aby zrozumieć konfigurację trasy zdefiniowanej przez użytkownika:

• Ruch typu spoke-to-spoke: Szprychy nie są połączone bezpośrednio ze sobą, a peering sieci wirtualnych nie jest przechodni. Każdy spoke domyślnie wie, jak routować do hub sieci wirtualnej, ale nie do innych spike'ów. Trasa 0.0.0.0/0 stosowana do wszystkich podsieci szprych obejmuje ruch szprychy do szprych.
• Ruch ze szprychy do Internetu: Trasa 0.0.0.0/0 w tabeli tras szprychy kieruje ruch do publicznego Internetu do usługi Azure Firewall. W podsieci nieprywatnej, która ma domyślny dostęp wychodzący, trasa zdefiniowana przez użytkownika nadpisuje domyślną trasę systemu internetowego. Nowe sieci wirtualne stworzone przy użyciu wersji API wydane po 31 marca 2026 roku domyślnie wykorzystują prywatne podsieci i wymagają wyraźnej metody wychodzącej (outbound). W tym modelu Azure Firewall zapewnia jawną łączność wychodzącą. Aby uzyskać więcej informacji, zobacz Domyślny dostęp wychodzący na platformie Azure.
• Ruch internetowy do węzła: Ruch z internetu do węzła zwykle najpierw przechodzi przez Azure Firewall. Usługa Azure Firewall ma skonfigurowane reguły translacji docelowych adresów sieciowych (DNAT), które również tłumaczą źródłowy adres IP (źródłowy translator adresów sieciowych lub SNAT). Obciążenia robocze w sieci szprychowej traktują ruch jako pochodzący z podsieci usługi Azure Firewall. Komunikacja równorzędna sieci wirtualnych tworzy trasy systemowe do koncentratora (10.1.0.0/24), dzięki czemu szprychy wiedzą, jak kierować ruch powrotny.
• Ruch z lokalnej do szprychy i ze szprychy do lokalnej: Rozważ oddzielnie każdy kierunek:
  • Ruch z lokalnego do odgałęźnego: ruch dociera z sieci lokalnej do bramek sieci VPN lub ExpressRoute. W przypadku domyślnego routingu w Azure, w GatewaySubnet (i innych podsieciach wirtualnej sieci centralnej) dla każdego połączenia tworzona jest trasa systemowa. Należy zastąpić te trasy systemowe i ustawić następny przeskok na prywatny adres IP usługi Azure Firewall. W tym przykładzie potrzebne są dwie trasy w tabeli tras przypisanej do podsieci bramy, po jednej dla każdej odnogi (10.1.1.0/24 i 10.1.2.0/24). Użycie podsumowania, takiego jak 10.1.0.0/16, które obejmuje wszystkie sieci wirtualne typu 'spoke', nie działa, ponieważ trasy routingu systemowego, które są wprowadzane przez połączenia równorzędne sieci wirtualnych w podsieci bramy, są bardziej szczegółowe (/24 w porównaniu z podsumowaniem /16). W tej tabeli tras musi być włączona opcja propagacja tras bramy (ustawiona na Tak), w przeciwnym razie routing bramy może stać się nieprzewidywalny.
  • Ruch między sieć lokalną a oddziałami: Peerowania sieci wirtualnej między centralą a oddziałami muszą mieć włączoną opcję Zezwalaj na tranzyt bramy po stronie centrali i Użyj zdalnych bram po stronie oddziału. Te ustawienia są wymagane, aby bramy sieci VPN i usługi ExpressRoute anonsować prefiksy szprych za pośrednictwem protokołu BGP (Border Gateway Protocol) do sieci lokalnych. Te ustawienia powodują również, że szprychy domyślnie uczą się prefiksów anonsowanych ze środowiska lokalnego na platformę Azure. Ponieważ prefiksy sieci lokalnej są bardziej szczegółowe niż trasa zdefiniowana przez użytkownika 0.0.0.0/0 w tabeli tras spoke, ruch ze spoke do sieci lokalnej domyślnie omija zaporę. Aby temu zapobiec, ustaw przełącznik Propagate gateway routes na Nie w tabeli tras sieci typu spoke, aby prefiksy sieci lokalnej nie były pobierane i aby do ruchu do sieci lokalnej była używana trasa 0.0.0.0/0.

Możesz zarządzać zarówno tabelą tras skojarzoną z podsieciami szprych, jak i tabelą tras skojarzoną z podsiecią bramy za pomocą Azure Virtual Network Manager, aby zmniejszyć obciążenie administracyjne. Aby uzyskać więcej informacji, zobacz Używanie usługi Azure Firewall jako następnego przeskoku.

Obciążenia sieci wirtualnej huba

Wdrażanie obciążeń w wirtualnej sieci hub, takich jak kontrolery domeny Active Directory, serwery DNS czy inna współdzielona infrastruktura, zwiększa złożoność projektu hub-and-spoke. Unikaj nakładania obciążeń w hubie. Zamiast tego wdroż je w odrębnej gałęzi przeznaczonej dla usług wspólnych.

W tej sekcji opisano konfigurację wymaganą dla obciążeń koncentratora, aby ocenić, czy ta złożoność jest akceptowalna dla Twoich wymagań. Opisano również typowy błąd, który może spowodować asymetryczny ruch i spadek pakietów.

Na poniższym diagramie przedstawiono projekt z pojedynczym regionem z podsiecią obciążeniową w sieci wirtualnej koncentratora.

Kluczowym szczegółem jest to, że definiowane przez użytkownika trasy skonfigurowane zarówno w podsieci bramy, jak i podsieciach odgałęzień są zdefiniowane dla określonej podsieci obciążenia , a nie dla całego prefiksu sieci wirtualnej hubu.

• Konfiguracja podsieci bramy: konfigurowanie trasy w podsieci bramy dla całej sieci wirtualnej koncentratora (10.1.0.0/24 w tym przykładzie) zastępuje trasę systemową dla sieci wirtualnej koncentratora. To powoduje, że ruch kontrolny wewnątrz podsieci między bramami VPN lub usługi ExpressRoute jest wysyłany do zapory, co może potencjalnie zakłócać działanie bramy.
• Konfiguracja podsieci spoke: Konfigurowanie trasy w podsieciach spoke dla całej sieci wirtualnej hub (10.1.0.0/24 w tym przykładzie) zastępuje systemową trasę utworzoną przez równoległe połączenie z siecią wirtualną hub. Cały ruch wysyłany do centrum zostanie wysłany do usługi Azure Firewall, w tym ruch pochodzący z samej usługi Azure Firewall, taki jak ruch internetowy do szprychy, który przechodzi przez translacja adresów sieciowych źródła (SNAT). Ta konfiguracja wprowadza asymetryczny ruch i powoduje spadek pakietów.

Inspekcja ruchu między podsieciami

W obecnym ustawieniu zapora obsługuje ruch między szprychami, ale ruch wewnątrz szprychów pozostaje w sieci wirtualnej, gdzie sterujesz nią za pomocą grup bezpieczeństwa sieci. Ten projekt uwzględnia sieci wirtualne jako granicę zabezpieczeń: zapora sprawdza tylko ruch, który wychodzi lub wchodzi do sieci wirtualnej.

Aby sprawdzić ruch między podsieciami w tej samej szprychowej sieci wirtualnej, zmodyfikuj tabelę tras skojarzoną z podsieciami szprychowej, zgodnie z poniższym diagramem.

Na poprzednim diagramie dwie podsieci szprych są wprowadzane w każdej sieci wirtualnej szprych, a tabele tras dla szprych w sieci wirtualnej A2 są opisane. Wysyłanie ruchu między podsieciami do zapory wymaga, aby każda podsieć miała odrębną tabelę routingu, ponieważ trasy do zainstalowania w każdej z nich są różne.

W przypadku podsieci A21 potrzebne są dwie dodatkowe trasy:

• Trasa do 10.1.2.0/24: zastępuje trasę systemową dla ruchu wewnątrz sieci wirtualnej. Bez innych tras cały ruch wewnątrz sieci wirtualnej jest wysyłany do usługi Azure Firewall, nawet ruchu między maszynami wirtualnymi w tej samej podsieci.
• Trasa do 10.1.2.0/26 do sieci wirtualnej w następnym przeskoku: wyjątek od poprzedniej trasy, więc ruch w tej konkretnej podsieci nie jest wysyłany do zapory, ale jest kierowany lokalnie w ramach sieci wirtualnej. Ta trasa jest specyficzna dla każdej podsieci, dlatego potrzebna jest oddzielna tabela tras dla każdej podsieci.

SD-WAN wirtualne urządzenia sieciowe

Jeśli używasz Wirtualnych Urządzeń Sieciowych SD-WAN (WUS) zamiast bram VPN lub bram usługi ExpressRoute, projekt jest podobny, co pokazuje poniższy diagram:

Możesz integrować urządzenia NVA SD-WAN na platformie Azure na różne sposoby. Aby uzyskać więcej informacji, zobacz integrowanie SD-WAN z topologiami sieci hub-and-spoke w platformie Azure. Ten artykuł pokazuje integrację wykorzystującą Azure Route Server, jedną z najczęściej stosowanych metod kierowania ruchu do SD-WAN sieci. Urządzenia NVA SD-WAN reklamują prefiksy lokalne do usługi Azure Route Server za pośrednictwem protokołu BGP. Usługa Azure Route Server wprowadza te prefiksy w podsieci usługi Azure Firewall, aby usługa Azure Firewall zawierała informacje o routingu dla sieci lokalnych. Szprychy nie uczą się lokalnych prefiksów, ponieważ opcja "Propaguj trasy bramy" jest wyłączona w tabeli tras szprych.

Jeśli nie chcesz konfigurować prefiksu każdej sieci wirtualnej typu 'spoke' w tabeli tras skojarzonej z podsiecią NVA, możesz umieścić urządzenia SD-WAN w ich dedykowanej sieci wirtualnej. Sieć wirtualna wykorzystująca urządzenie NVA nie uczy się prefiksów antenowych, ponieważ nie są bezpośrednio połączone, a można zastosować trasę sumaryczną, jak pokazano na poniższym diagramie.

Architektura wieloregionowa typu piasta-szprychy

Po zrozumieniu, jak ruch działa w jednym regionie piasty i szprych, rozszerzanie projektu na architekturę z wieloma regionami jest proste. Na poniższym diagramie przedstawiono zaktualizowany projekt sieci z koncentratorami w dwóch regionach (A i B):

Jedynym dodatkiem do konfiguracji są tabele tras skojarzone z podsieciami usługi Azure Firewall w każdym regionie. Każda sieć wirtualna koncentratora zna tylko prefiksy dla kolejnych bezpośrednio połączonych sieci wirtualnych, więc nie ma trasowania dla prefiksów zdalnych ramion. Dodaj trasy zdefiniowane przez użytkownika dla każdej podsieci usługi Azure Firewall, aby ruch dla każdego regionu był kierowany do odpowiedniej usługi Azure Firewall.

W tym przykładzie każdy region można łatwo podsumować:

• Region A zawiera prefiksy w 10.1.0.0/16
• Region B zawiera prefiksy w 10.2.0.0/16

Definiowanie adresów IP w każdym regionie, które można łatwo podsumować, sprawia, że konfiguracja routingu jest prostsza. W przeciwnym razie należy utworzyć jedną trasę dla każdego zdalnego węzła.

Włącz propagację tras bramy w tabeli tras podsieci usługi Azure Firewall, aby zapora mogła uczyć się tras lokalnych z bram sieci VPN i usługi ExpressRoute.

Aby uprościć zarządzanie trasami zdefiniowanymi przez użytkownika w środowisku obejmującym wiele regionów, możesz użyć usługi Azure Virtual Network Manager. Aby uzyskać więcej informacji, zobacz Manage user-defined routes across multiple hub-and-spoke topologies with AVNM (Zarządzanie trasami zdefiniowanymi przez użytkownika w wielu topologiach piasty i szprych za pomocą programu AVNM).

Następne kroki

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