Maszyna wirtualna w spoke inicjuje połączenie z serwerem w sieci lokalnej. Żądanie przechodzi przez NVA w hubie, jest sprawdzane i dociera do miejsca przeznaczenia. Odpowiedź wróci, ale przez bramę ExpressRoute bezpośrednio do spoke, z całkowitym pominięciem NVA. Zapora widzi pakiet powrócony bez pasującego wpisu stanu sesji i po cichu go odrzuca. Połączenie zawiesza się. Żadnego błędu. Żadnego oczywistego wpisu w logach. Tylko limit czasu.
To jest asymetryczne routowanie. W topologiach hub-and-spoke nie jest to przypadek brzegowy ani błąd konfiguracji, którego można uniknąć z wystarczającą uwagą. Jest to strukturalna konsekwencja sposobu, w jaki Azure SDN, peering VNet, User-Defined Routes i stanowe urządzenia zabezpieczające współdziałają ze sobą. Pytanie nie brzmi, czy się na to natkniesz. Pytanie brzmi: czy zaprojektowałeś to z góry, czy będziesz debugował o 2 w nocy?
Ten artykuł omawia pięć najczęstszych scenariuszy asymetrii w hybrydowych topologiach Azure, narzędzia do ich wykrywania, zanim zrobią to użytkownicy, oraz zestaw praktycznych technik, których nie ma w standardowej dokumentacji.
Asymetryczne routowanie występuje, gdy ścieżka forward i ścieżka powrotna przepływu sieciowego przechodzą przez różne urządzenia lub segmenty sieci. W sieci bezstanowej jest to nieszkodliwe. W sieci ze stanową inspekcją (zapory, NVA, IDS/IPS) jest to fatalne: urządzenie stanowe widzi tylko jeden kierunek przepływu, nie ma wpisu sesji dla pakietów powróconych i odrzuca je jako nieprawidłowe.
Topologia hub-and-spoke stwarza warunki do asymetrii poprzez kilka wzajemnie wzmacniających się mechanizmów.
Peering VNet jest nietranzytywny. Spoke nie mogą komunikować się bezpośrednio ze sobą ani z sieciami lokalnymi. Cały ruch musi być routowany przez hub. Ale Azure automatycznie tworzy trasy systemowe w każdej VNet podczas ustanawiania peeringu, a te trasy systemowe mogą kierować ruch bezpośrednio między peerowanymi VNet, jeśli UDR nie nadpisują ich jawnie.
UDR muszą być konfigurowane ręcznie w każdej podsieci. W samodzielnie zarządzanym hub-and-spoke nie ma globalnej polityki routowania. Jeśli zapomnisz podsieci lub dodasz nową bez aktualizacji tablic tras, ta podsieć używa tras systemowych i ruch omija zaplanowaną ścieżkę.
Propagacja tras bramy jest domyślnie włączona. Gdy włączysz Allow Gateway Transit w peeringu hub i Use Remote Gateways po stronie spoke, spoke automatycznie uczy się prefiksów lokalnych z bramy. Te wyuczone trasy są bardziej szczegółowe niż UDR 0.0.0.0/0. Spoke wysyła ruch do sieci lokalnej bezpośrednio przez bramę, omijając zaporę.
Private Endpoints nadpisują routowanie zgodnie z projektem. Private Endpoint tworzy niejawne trasy hosta /32, które propagują się do wszystkich peerowanych VNet. Te trasy mają pierwszeństwo przed UDR, gdyż są bardziej szczegółowe. Network Policy dla Private Endpoints jest domyślnie wyłączona we wszystkich podsieciach, co oznacza, że NSG i UDR są ignorowane dla ruchu PE, o ile nie włączysz tego jawnie.
Poniższa tabela podsumowuje wszystkie pięć scenariuszów omówionych w tej sekcji. Każdy z nich jest szczegółowo omówiony poniżej.
| Przepływ ruchu | Przyczyna źródłowa | Objaw | Rozwiązanie |
|---|---|---|---|
| Z sieci lokalnej do spoke (przez bramę) | Brak UDR w GatewaySubnet dla prefiksów spoke | Ruch powrotny ze spoke trafia do zapory; ruch przychodzący ją omija. Stanowa zapora odrzuca pakiety powrotne. | Dodaj osobne UDR per-spoke do GatewaySubnet (dokładne /24, nie podsieć sumaryczna). Next hop: prywatny IP zapory. |
| Z zasobów hub do spoke | Podsieci hub nie mają tablic tras; używają tras systemowych z peeringu | Maszyna wirtualna hub dociera do spoke bezpośrednio. Spoke odpowiada przez zaporę. Sesja jest porzucana. | Podepnij tablicę tras do każdej podsieci z zasobami w hubie. UDR do prefiksów spoke przez zaporę. |
| Ze spoke do internetu/sieci lokalnej przez aktywne-aktywne NVA | ECMP przez instancje NVA; Azure SDN nie gwarantuje symetrii na poziomie przepływu | Ruch przychodzący i wychodzący trafia na różne instancje NVA. Stanowa zapora odrzuca pakiety. | SNAT na NVA lub ILB z portami HA i Floating IP, lub synchronizacja stanu sesji między NVA. |
| Z sieci lokalnej do Private Endpoint w spoke | Niejawna trasa /32 PE omija UDR; Network Policy domyślnie wyłączona | Ruch omija zaporę dla ruchu przychodzącego; podsieć PE odpowiada przez zaporę. Asymetria i brak inspekcji. | Włącz Route Table Network Policy w podsieci PE. Albo dodaj jawny /32 UDR do podsieci klienta. |
| ExpressRoute + współistnienie VPN | Wybór ścieżki BGP różni się po stronie Azure i po stronie lokalnej | Ruch wychodzi przez ER, wraca przez VPN (lub odwrotnie). Lokalna stanowa zapora odrzuca ruch powrotny. | Ustaw wyższy Local Preference dla ER na routerach lokalnych. AS path prepend po stronie VPN. |
Ruch przybywa z sieci lokalnej przez bramę ExpressRoute lub VPN do GatewaySubnet. Domyślnie Azure tworzy trasy systemowe w GatewaySubnet dla każdej peerowanej spoke VNet. Te trasy systemowe kierują ruch bezpośrednio do spoke, omijając zaporę. Ruch powrotny ze spoke przechodzi przez zaporę, ponieważ spoke ma UDR wskazujący w tamtym kierunku. Zapora widzi tylko pakiet powrócony i go odrzuca.
Rozwiązanie: Dodaj UDR do GatewaySubnet dla każdego prefiksu spoke z next hopem ustawionym na prywatny IP zapory.
| UWAGA: GatewaySubnet nie obsługuje UDR 0.0.0.0/0. Nie możesz dodać domyślnej trasy do GatewaySubnet. Musisz dodać jawne prefiksy per-spoke. Użycie trasy sumarycznej np. 10.1.0.0/16 obejmującej wszystkie spoke też nie zadziała: trasy systemowe wstrzyknięte przez peering VNet mają /24 (lub jakikolwiek prefiks spoke), który jest bardziej szczegółowy niż /16 i wygrywa. Oznacza to, że za każdym razem gdy dodajesz nowy spoke, musisz także dodać nowy wpis UDR do tablicy tras GatewaySubnet. Jeśli nie jest to częścią automatyzacji wdrażania spoke, będziesz tworzyć asymetrię przy każdym nowym wdrożeniu spoke. |
| WSKAZÓWKA: Skontroluj wszystkie GatewaySubnety w swoim środowisku jednym poleceniem: az network vnet subnet show –name GatewaySubnet –vnet-name <hub-vnet> –resource-group <rg> –query routeTable Jeśli routeTable ma wartość null, podsieć nie ma UDR i jest podatna na tę asymetrię. Uruchamiaj ten skrypt dla wszystkich VNet hubów jako element kontroli stanu sieci. |
Podsieci hub zawierające rzeczywiste zasoby (usługi współdzielone, maszyny zarządzające, resolvery DNS, jump boxy) są często pozostawiane bez tablic tras. Rozumowanie jest takie, że hub jest „środkiem” i routuje cały ruch, więc sam nie potrzebuje routowania. To jest błąd.
Maszyna wirtualna w hubie dociera do spoke przez trasę systemową utworzoną przez peering VNet — bezpośrednio. Maszyna w spoke odpowiada przez zaporę, gdyż jej UDR tak wskazuje. Zapora widzi nieoczekiwany pakiet powrócony i go odrzuca.
Rozwiązanie: Podłącz tablicę tras do każdej podsieci z zasobami hub. Dodaj UDR dla wszystkich prefiksów spoke i sieci lokalnych, z next hopem wskazującym na zaporę. Sama podsieć zapory jest jedyną, która nie powinna mieć tablicy tras wskazującej z powrotem na zaporę.
| WSKAZÓWKA: Użyj tego polecenia, aby wyświetlić wszystkie podsieci VNet bez podłączonej tablicy tras: az network vnet subnet list –vnet-name <hub-vnet> –resource-group <rg> –query „[?routeTable==null].name” Uruchamiaj po każdej zmianie VNet. Każda podsieć, która tu się pojawi i nie jest AzureFirewallSubnet ani AzureBastionSubnet, wymaga tablicy tras. |
W celu zapewnienia wysokiej dostępności instancje NVA są wdrażane parami. W konfiguracji aktywne-aktywne obie instancje rozgłaszają te same trasy (przez Azure Route Server lub identyczne UDR wskazujące na Internal Load Balancer). Platforma SDN Azure wykonuje ECMP, rozdzielając ruch pomiędzy nimi.
Problem: Platforma SDN Azure nie gwarantuje symetrii na poziomie przepływu. Pakiet wychodzący przepływu może trafić przez instancję NVA A. Pakiet powrócony może trafić na instancję NVA B. Instancja B nie ma stanu sesji dla tego przepływu i odrzuca pakiet. To nie jest błąd — to zaprojektowane zachowanie ECMP w Azure SDN.
Istnieją trzy rozwiązania, każde z innymi kompromisami.
Opcja 1: SNAT na każdej instancji NVA. NVA zastępuje źródłowy IP pakietów wychodzących własnym adresem interfejsu. Ruch powrotny wraca gwarantowanie do tej samej instancji NVA. Proste i niezawodne, ale ukrywa oryginalny IP źródła w logach.
Opcja 2: Internal Load Balancer z portami HA i Floating IP. ILB rozdziela przepływy między instancje NVA przy użyciu skrótu 5-tuples, gwarantując, że wszystkie pakiety tego samego przepływu trafiają do tej samej NVA. Floating IP zapewnia, że NVA widzi oryginalny docelowy IP zamiast frontendowego IP ILB. To zalecany wzorzec dla ruchu East-West i sieci lokalnych bez SNAT.
Opcja 3: Synchronizacja stanu sesji NVA. Niektórzy dostawcy NVA obsługują replikację stanu sesji między aktywnymi instancjami. Obie NVA mogą obsłużyć ruch powrotny dowolnego przepływu. To architektonicznie najczystsze rozwiązanie, ale specyficzne dla dostawcy, kosztowne i z narzutem.
| UWAGA: Nie używaj aktywnych-aktywnych NVA z identycznymi reklamami AS-PATH dla połączeń wymagających stanowej inspekcji bez SNAT lub synchronizacji sesji.Azure Route Server z ECMP został zaprojektowany dla bezstanowych obciążeń (SD-WAN, IPsec NVA). Używanie go dla zapór nowej generacji bez mechanizmów kompensacyjnych spowoduje sporadyczne i trudne do zdiagnozowania odrzucanie pakietów. |
| WSKAZÓWKA: Przed wdrożeniem NVA HA sprawdź, czy Twój dostawca NVA obsługuje tryb asymetrycznego przekazywania lub synchronizację stanu sesji. Jeśli żadna z tych opcji nie jest dostępna i SNAT nie wchodzi w grę, aktywne-pasywne (nie aktywne-aktywne) z przełączaniem tras UDR jest bezpieczniejszym projektem. Dla Azure Firewall: jest to usługa zarządzana obsługująca SNAT i śledzenie sesji wewnętrznie. Azure Firewall w aktywno-aktywnym secured hub nie generuje tego problemu. |
Private Endpoints nie są prostymi kartami sieciowymi. Po wdrożeniu Private Endpoint w VNet, Azure automatycznie wstrzykuje trasy hosta /32 dla prywatnego IP PE do każdej VNet peerowanej z VNet PE. Ta propagacja odbywa się niezależnie od tego, czy peerowane VNet mają UDR.
W efekcie: maszyna wirtualna w sieci lokalnej lub zdalnym spoke może dotrzeć do Private Endpoint bezpośrednio przez trasy systemowe peeringu, omijając zaporę. Ruch powrotny z podsieci PE przechodzi przez zaporę (bo podsieć PE ma UDR). Jeden kierunek omija inspekcję. Drugi nie. Klasyczna asymetria.
Przyczyna źródłowa: Network Policy dla Private Endpoints jest domyślnie wyłączona w każdej podsieci. Po wyłączeniu UDR i NSG są pomijane dla ruchu kierowanego do Private Endpoints w tej podsieci, niezależnie od zawartości tablicy tras.
Rozwiązanie: Włącz Route Table Network Policy w podsieci, w której wdrażane są Private Endpoints. To pojedyncze ustawienie powoduje, że UDR dotyczą ruchu PE, pozwalając kierować go przez zaporę.
| UWAGA: Włączenie Network Policy to ustawienie na poziomie podsieci wpływające na wszystkie Private Endpoints w tej podsieci. W istniejących wdrożeniach z wieloma PE przetestuj wpływ przed włączeniem na produkcji. Niektóre stare konfiguracje korzystają z domyślnego zachowania pomijającego. Od końca 2024 roku zewnętrzne NVA obsługują tag zasobu disableSnatOnPL=true na karcie sieciowej NVA. Azure Firewall i NVA w vWAN Secured Hub nadal wymagają SNAT dla symetrii PE (stan na początek 2025). |
| WSKAZÓWKA: Jeśli włączenie Network Policy na istniejącej podsieci PE jest zbyt ryzykowne, użyj obejścia dla konkretnych PE: Dodaj jawny /32 UDR w podsieci klienta (nie podsieci PE) wskazujący prywatny IP PE na zaporę./32 jest bardziej szczegółowy niż niejawna trasa PE i wygrywa. To chirurgiczne podejście pozwala przekierować poszczególne przepływy PE przez inspekcję bez dotykania ustawienia Network Policy. |
Gdy ExpressRoute i VPN site-to-site współistnieją w tym samym hubie, obie ścieżki reklamują trasy do Azure. Azure zawsze preferuje ExpressRoute nad VPN dla tego samego prefiksu. Ale ścieżka powrotna z sieci lokalnej do Azure zależy od tego, co preferuje router lokalny — a to jest pod Twoją kontrolą.
Jeśli BGP lokalny nie jest skonfigurowany z wyższym Local Preference dla ExpressRoute, niektóre prefiksy mogą być osiągalne przez oba łącza, a router może wysyłać ruch przez VPN do Azure, podczas gdy Azure odsyła go przez ExpressRoute. Stanowa zapora lokalna widzi tylko jeden kierunek i odrzuca ruch powrotny.
Rozwiązanie: Ustaw wyższy Local Preference dla tras otrzymanych przez ExpressRoute na wszystkich lokalnych routerach BGP. Zapewnia to, że dla identycznych prefiksów router zawsze preferuje ExpressRoute dla obu kierunków, odpowiadając preferencji Azure.
| UWAGA: Podczas konserwacji ExpressRoute Microsoft celowo wydłuża ścieżkę AS na jednym z dwóch łączy ER, aby płynnie przenieść ruch. Jeśli Twoja konfiguracja BGP zawiera bgp bestpath as-path ignore, router ignoruje ten sygnał i może utrzymywać ruch na łączu, które Microsoft stara się opróżnić. Ruch idzie jednym łączem i wraca drugim. Lokalna stanowa zapora odrzuca ruch powrotny. Przed każdym oknem konserwacyjnym przeprowadź audyt konfiguracji BGP w zakresie as-path ignore. |
| WSKAZÓWKA: Jeśli musisz wpłynąć na wybór ścieżki bez modyfikowania Local Preference (np. nie kontrolujesz routera lokalnego), użyj AS path prepending w reklamie BGP VPN. Dodaj dwie lub trzy kopie własnego ASN do ścieżki AS po stronie VPN. Router lokalny wybierze krótszą ścieżkę AS, czyli trasę ExpressRoute. |
Azure Route Server (ARS) to w pełni zarządzana usługa umożliwiająca dynamiczną wymianę tras między NVA a Azure SDN przy użyciu BGP. Zamiast ręcznego utrzymywania UDR w każdym spoke, NVA reklamuje trasy do ARS, a ARS propaguje je automatycznie do wszystkich podłączonych spoke VNet.
Jest to potężne, ale wprowadza złożoność w pierwszeństwo tras, która może powodować własną asymetrię.
Trasy ExpressRoute mają pierwszeństwo przed trasami NVA Route Server gdy obie reklamują ten sam prefiks. Jeśli NVA reklamuje 10.0.0.0/8 (supernet), a ExpressRoute reklamuje konkretne /24 dla sieci lokalnych, trasy ExpressRoute wygrywają dla tych miejsc docelowych. Ruch ze spoke do tych miejsc docelowych lokalnych idzie bezpośrednio przez bramę, omijając NVA. Asymetria.
Rozwiązanie: Skonfiguruj NVA, aby reklamowały trasy ze społeczności BGP no-advertise (65535:65282). Zapobiega to ponownemu reklamowaniu tras NVA przez Route Server do innych peerów BGP, a konkretnie z powrotem do sieci lokalnych przez ExpressRoute.
Route Server nie uczestniczy w płaszczyźnie danych. Kontroluje tylko płaszczyznę sterowania (jakie trasy są programowane w tablicach tras VNet). Faktyczne przekazywanie pakietów nadal podąża za UDR lub trasą systemową.
| WSKAZÓWKA: Podczas analizy zachowania Route Server użyj widoku Effective Routes na poziomie huba (Azure Virtual WAN) lub statusu peerów BGP Route Server, a nie tylko efektywnych tras karty sieciowej VM. Dla rozdziału non-Virtual WAN: sprawdź zarówno az network route-server list-advertised-routes jak i az network route-server list-learned-routes, aby zobaczyć co ARS dystrybuuje i czego się nauczył. Porównaj z efektywnymi trasami karty sieciowej VM, aby znaleźć rozbieżności. |
Większość problemów z asymetrycznym routowaniem jest wykrywana przez użytkowników, a nie przez monitoring. Poniższe narzędzia to zmieniają.
Najbardziej niedoceniana technika wykrywania asymetrii to traktowanie efektywnych tras jako stanu infrastruktury, który musi być wersjonowany. Po każdym wdrożeniu IaC przechwytuj efektywne trasy jednej reprezentatywnej maszyny wirtualnej na podsieć i porównaj diff z poprzednim stanem.
| Capture effective routes for a VM NIC az network nic show-effective-route-table \ –name \ –resource-group \ –output table > effective-routes-$(date +%Y%m%d).txt Bulk: all NICs in a resource group for nic in $(az network nic list -g –query ‘[].name’ -o tsv); do echo “=== $nic ===” az network nic show-effective-route-table -n $nic -g –query \ ‘value[].{prefix:addressPrefix[0],nextHop:nextHopType,via:nextHopIpAddress[0]}’ \ –output table done |
Commituj te wyniki do git obok Terraform lub Bicep. Nowy spoke, zmiana peeringu lub aktualizacja prefiksu ExpressRoute pojawi się jako diff w efektywnych trasach, zanim stanie się incydentem.
| WSKAZÓWKA: Jeśli nextHopType pokazuje VnetPeering lub VirtualNetworkGateway dla miejsca docelowego, gdzie oczekujesz VirtualAppliance, znalazłeś asymetrię. Ruch omija Twoją zaporę dla tego miejsca docelowego. |
Kombinacja allowGatewayTransit (strona hub) i useRemoteGateways (strona spoke) jest wymagana dla ruchu spoke do sieci lokalnych. Ale jeśli Propagate Gateway Routes nie jest wyłączone w tablicy tras spoke, spoke uczy się prefiksów lokalnych i routuje bezpośrednio do nich, omijając zaporę.
Uruchamiaj ten skrypt dla wszystkich VNet hubów, aby znaleźć niezgodności:
| List all peering flag combinations in a hub VNet az network vnet peering list \ –vnet-name \ –resource-group \ –query ‘[].{name:name, allowGatewayTransit:allowGatewayTransit, \ useRemoteGateways:useRemoteGateways, \ allowForwardedTraffic:allowForwardedTraffic}’ \ –output table Check if spoke route table has Propagate Gateway Routes enabled az network route-table show \ –name \ –resource-group \ –query ‘disableBgpRoutePropagation’ |
Jeśli disableBgpRoutePropagation ma wartość false, trasy bramy propagują się do spoke. Wyłącz propagację tras BGP w tablicach tras spoke i opieraj się na UDR 0.0.0.0/0 dla całego ruchu do sieci lokalnych.
Connection Monitor jest zazwyczaj wdrażany po incydencie. Wdrażaj go przed Go-Live, celowo pokrywając ścieżki ruchu najbardziej podatne na asymetrię.
Skonfiguruj grupy testów Connection Monitor obejmujące co najmniej:
Uruchamiaj Connection Monitor przez 48–72 godziny przed każdym przejściem produkcyjnym. Utrata pakietów powiązana z konkretnymi parami źródło-destynacja wskazuje na asymetrię zanim zauważy ją zespół aplikacyjny.
| WSKAZÓWKA: Testy Connection Monitor kosztują ułamki centa za test na godzinę. Konfiguracja 10 testów przez tydzień przed Go-Live kosztuje poniżej 5 USD. Ustaw reguły alertów na procent niepowodzeń testów > 5%, a nie 0%. Pewna utrata pakietów jest normalna w złożonych topologiach hybrydowych. Alarmuj na trwałe błędy, nie przejściowe. |
Przed zatwierdzeniem zmiany UDR zweryfikuj oczekiwaną decyzję routowania przy użyciu Network Watcher: Next Hop. To narzędzie wykonuje zapytanie do Azure SDN o decyzję routowania dla konkretnego źródłowego IP, docelowego IP i karty sieciowej, bez wysyłania rzeczywistego ruchu.
| Verify that spoke VM routes on-premises traffic through firewall az network watcher show-next-hop \ –resource-group \ –vm \ –nic \ –source-ip \ –dest-ip Expected output: nextHopType: VirtualAppliance nextHopIpAddress: If you see VirtualNetworkGateway or Internet, the UDR is missing or being overridden |
Uruchamiaj dla obu kierunków każdego krytycznego przepływu: źródło-destynacja i destynacja-źródło. Asymetryczne routowanie oznacza, że te dwa wywołania zwrócą różne wartości nextHopType. Ta rozbieżność to Twój problem.
Po zidentyfikowaniu asymetrii, wybór poprawki zależy od scenariusza i ograniczeń. Poniższa tabela porównuje cztery główne podejścia.
| Podejście | Kiedy stosować | Co tracisz | Koszt operacyjny |
|---|---|---|---|
| SNAT na NVA | Aktywne-aktywne NVA HA, ruch North-South, dowolna stanowa inspekcja z wieloma instancjami | Oryginalny IP źródła ukryty w logach. Problemy dla polityk bezpieczeństwa i ścieżek audytu opartych na IP. | Niski po skonfigurowaniu. Azure Firewall wykonuje SNAT automatycznie dla celów spoza RFC1918. |
| Precyzyjne UDR w każdej podsieci | Pojedyncza instancja NVA, mniejsze topologie, gdy zachowanie IP źródła jest obowiązkowe | Ręczne utrzymywanie UDR per-spoke per-podsieć. Rozrost tablic tras. Wymagana automatyzacja IaC. | Wysoki. Każdy nowy spoke, podsieć lub prefiks sieci lokalnej wymaga aktualizacji UDR wszędzie. |
| ILB z portami HA + Floating IP | Aktywne-aktywne NVA HA, ruch East-West i do sieci lokalnej, gdy SNAT jest akceptowalny | Moduł load balancera dodaje opóźnienie. Konfiguracja Floating IP jest nieintuicyjna. | Średni. ILB zarządza symetrią przepływu automatycznie po prawidłowej konfiguracji. |
| Synchronizacja stanu sesji NVA | Aktywne-aktywne NVA HA, gdy zachowanie IP źródła jest obowiązkowe i SNAT jest nie do przyjęcia | Funkcja specyficzna dla dostawcy NVA. Dodaje złożoność i koszty licencjonowania. | Wysoki. Konfiguracja zależna od dostawcy, narzut ruchu między NVA, złożone tryby awarii. |
SNAT jest najprostszym operacyjnie wyborem, gdy zachowanie źródłowego IP nie jest wymaganiem twardym. W środowiskach regulowanych, gdzie każdy pakiet musi być logowany z prawdziwym źródłowym IP, precyzyjne UDR w połączeniu z ILB HA Ports to właściwy wzorzec. Synchronizację stanu sesji NVA zarezerwuj dla przypadków, gdzie ani SNAT ani ILB nie jest akceptowalne i dostawca NVA jawnie to obsługuje.
Ponieważ prefiksy on-premises nauczone przez BGP z bramy są bardziej szczegółowe niż 0.0.0.0/0. Prefiks /24 on-premises bije trasę domyślną /0. Spoke kieruje bezpośrednio do bramy. Rozwiązanie: wyłącz Propagate Gateway Routes (ustaw disableBgpRoutePropagation: true w tablicy routingu spoke’a). UDR 0.0.0.0/0 wygrywa wtedy dla wszystkich celów, w tym on-premises.
Nie. GatewaySubnet nie obsługuje domyślnego UDR trasy. Musisz dodać jawne trasy per-prefiks dla każdego spoke’a. Jest to twarde ograniczenie platformy, nie opcja konfiguracji.
Propagate Gateway Routes (disableBgpRoutePropagation: false domyślnie) powoduje, że tablica routingu podsieci automatycznie uczy się tras z bram ExpressRoute i VPN. Wyłącz to (disableBgpRoutePropagation: true) we wszystkich tablicach routingu podsieci spoke’a, gdy chcesz, aby UDR 0.0.0.0/0 kontrolował cały ruch nielokalny. Pozostaw włączone w GatewaySubnet.
Zarządzany silnik routingu Virtual WAN obsługuje większość scenariuszy UDR automatycznie przez Routing Intent i polityki routingu. Jednak Private Endpoints nadal wymagają ręcznego włączenia Route Table Network Policy. Aktywne-aktywne NVA z ECMP w vWAN nadal wymaga SNAT lub synchronizacji sesji. Platforma eliminuje problemy UDR GatewaySubnet i obciążeń huba, ale nie eliminuje problemów NVA HA i Private Endpoint.
Stanowe zapory i NVA utrzymują tablicę sesji. Gdy nowe połączenie jest nawiązywane, urządzenie tworzy wpis sesji. Gdy pakiet powrotny trafia na urządzenie, które nigdy nie widziało oryginalnego pakietu, nie ma wpisu sesji i traktuje pakiet powrotny jako nieoczekiwany, odrzucając go. Odrzucenie jest ciche, ponieważ urządzenie funkcjonuje poprawnie.
Nie. Trasy systemowe tworzone przez peering VNet używają dokładnego prefiksu VNet spoke’a (np. /24). Są one bardziej szczegółowe niż jakakolwiek trasa sumaryczna (np. /16). Bardziej szczegółowe trasy zawsze wygrywają.
Tag zasobu wprowadzony w październiku 2024 roku, który można zastosować do karty sieciowej NVA firmy trzeciej. Po ustawieniu (klucz: disableSnatOnPL, wartość: true) usuwa wymóg SNATowania ruchu przeznaczonego do Private Endpoints dla tej konkretnej NVA. Na początku 2025 roku dotyczy to tylko NVA firm trzecich w standardowym hub-and-spoke VNet.
Routing asymetryczny nie jest problemem, który naprawia się po wystąpieniu. Gdy pojawi się w produkcji, zasięg jest szeroki, a diagnoza czasochłonna. Poniższe decyzje projektowe mu zapobiegają.
Dodaj UDR GatewaySubnet jako część automatyzacji wdrażania spoke’ów. Każdy przepływ pracy tworzenia spoke’a musi zawierać dodanie prefiksu spoke’a do tablicy routingu GatewaySubnet. To nie jest opcjonalna konserwacja. Jeśli nie jest to w module Terraform lub szablonie Bicep, zostanie pominięte.
Wyłącz propagację tras BGP we wszystkich tablicach routingu spoke’ów. To jedno ustawienie eliminuje najczęstszą przyczynę omijania zapory dla ruchu on-premises. UDR 0.0.0.0/0 rządzi wtedy wszystkimi celami innymi niż lokalne.
Włącz Route Table Network Policy w każdej podsieci Private Endpoint. Domyślne (wyłączone) pozwala ruchowi PE omijać UDR i NSG. Jest to prawie nigdy nie to, czego chce architektura świadoma bezpieczeństwa.
Traktuj podsieci z obciążeniami huba tak samo jak podsieci spoke’ów. Każda podsieć w hubie, która hostuje obciążenia, potrzebuje tablicy routingu z taką samą dyscypliną UDR jak spoke’i. Hub nie jest zwolniony z polityki routingu.
Wybieraj aktywny-pasywny nad aktywnym-aktywnym dla stanowego NVA HA, chyba że SNAT lub ILB z portami HA jest w projekcie od początku. Aktywny-aktywny z ECMP powoduje sporadyczny asymetryczny routing ze stanowymi zaporami, który jest trudny do odtworzenia i zdiagnozowania.
Skonfiguruj Connection Monitor przed uruchomieniem, nie po pierwszym incydencie. Koszt pokrycia testami jest prawie zerowy. Diagnostyczna wartość, gdy coś się zepsuje, jest znaczna.
Routing asymetryczny w topologiach hub-and-spoke nie jest błędem konfiguracji, którego można uniknąć przy wystarczającej uwadze. Jest to właściwość strukturalna topologii: peering VNet tworzy trasy systemowe, propagacja bramy dystrybuuje prefiksy on-premises, a Private Endpoints wstrzykują niejawne trasy hosta. Wszystkie one mogą nadpisać Twój zamierzony routing, jeśli UDR nie są stosowane konsekwentnie w każdej podsieci każdego VNetu.
Pięć scenariuszy w tym artykule (brakujące UDR GatewaySubnet, niechronione podsieci z obciążeniami huba, aktywne-aktywne NVA z ECMP, Private Endpoints bez Network Policy i niezgodność ścieżki ExpressRoute plus VPN) obejmuje większość incydentów asymetrycznego routingu w produkcyjnych środowiskach hybrydowych Azure. Każdy ma konkretne, weryfikowalne rozwiązanie.
Zestaw diagnostyczny (diff efektywnych tras, audyt flag peeringu, Connection Monitor jako kanarek, weryfikacja Next Hop) przesuwa wykrywanie z reaktywnego na proaktywne. Symetria routingu powinna być weryfikowana jako część automatyzacji wdrożeń, nie odkrywana podczas reagowania na incydenty.
Jeśli budujesz nowe środowisko: Virtual WAN eliminuje problemy GatewaySubnet i obciążeń huba, ale nie eliminuje Network Policy Private Endpoint ani wymagań SNAT dla NVA HA. Upraszcza powierzchnię routingu, ale nie sprowadza jej do zera.
