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). Narzędzie AVNM może zautomatyzować konfigurację tabel tras platformy Azure, ale ogólna konstrukcja i techniki nie zmieniają się w porównaniu z podejściem ręcznym. Zawartość tego artykułu ma zastosowanie w przypadku, gdy używasz AVNM lub ręcznie konfigurujesz topologię sieciową typu hub-and-spoke.

Alternatywą dla tabel tras platformy Azure w sieciach wirtualnych spokes jest wstrzykiwanie tras do podsieci za pomocą usługi Azure Route Server, jak udokumentowano w artykule Domyślna iniekcja trasy w sieciach wirtualnych spokes. Jednak ten wzorzec nie jest często używany ze względu na złożoność, która może wynikać z interakcji między usługą Azure Route Server i siecią VPN lub bramami sieci wirtualnej usługi 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). Urządzenia zabezpieczeń sieci, takie jak zapory, są wdrażane w wirtualnej sieci szkieletowej.
• 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 z sieci szprychy do Internetu: Trasa 0.0.0.0/0 w tabeli tras szprych obejmuje również ruch wysyłany do publicznego Internetu. Ta trasa domyślnie zastępuje trasę systemową zawartą w podsieciach publicznych. 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ż lokalne prefiksy są bardziej szczegółowe niż trasa 0.0.0.0/0 zdefiniowana przez użytkownika w tabeli tras szprych, ruch ze szprych do środowiska lokalnego domyślnie pomija zaporę. Aby zapobiec takiej sytuacji, ustaw przełącznik Rozpowszechnianie tras bramy na Nie w tabeli tras szprychy, tak aby prefiksy lokalne nie były propagowane i wykorzystywana była trasa 0.0.0.0/0 dla ruchu do środowiska lokalnego.

Możesz zarządzać zarówno tabelą tras skojarzoną z podsieciami szprych, jak i tabelą tras skojarzoną z podsiecią bramy przy użyciu usługi 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

Jeśli wdrażasz obciążenia w sieci wirtualnej koncentratora (na przykład kontrolerów domeny usługi Active Directory, serwerów DNS lub innej udostępnionej infrastruktury), powoduje to zwiększenie złożoności architektury hub-and-spoke. Zalecamy unikanie umieszczania obciążeń w centrum (hub) i wdrażanie ich w dedykowanej szprze dla usług udostępnionych.

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 bieżącej konfiguracji ruch między szprychami jest wysyłany do zapory, ale ruch wewnątrz szprych pozostaje w sieci wirtualnej będącej szprychą i jest kontrolowany przy użyciu sieciowych grup zabezpieczeń. 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:

Istnieją różne sposoby integrowania wirtualnych urządzeń sieciowych SD-WAN na platformie Azure. Aby uzyskać więcej informacji, zobacz integrowanie SD-WAN z topologiami sieci hub-and-spoke w platformie Azure. W tym artykule przedstawiono integrację przy użyciu usługi Azure Route Server, jednej z najbardziej typowych metod kierowania ruchu do sieci SD-WAN. Urządzenia SD-WAN NVAs ogłaszają lokalne wewnętrzne prefiksy 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.