Szczegółowe omówienie routingu usługi Virtual WAN

Azure Virtual WAN to rozwiązanie sieciowe, które umożliwia łatwe tworzenie zaawansowanych topologii sieci: obejmuje routing na różnych regionach Azure między sieciami wirtualnymi Azure a lokalizacjami lokalnymi za pośrednictwem sieci VPN typu punkt-lokacja, sieci VPN typu lokacja-lokacja, usługi ExpressRoute i zintegrowanych urządzeń SD-WAN, w tym opcję zabezpieczenia ruchu. W większości scenariuszy nie jest wymagana głęboka wiedza na temat sposobu działania wewnętrznego routingu usługi Virtual WAN, ale w niektórych sytuacjach warto zrozumieć pojęcia dotyczące routingu usługi Virtual WAN.

W tym dokumencie opisano przykładowe scenariusze usługi Virtual WAN, które wyjaśniają niektóre zachowania, które organizacje mogą napotkać podczas łączenia sieci wirtualnych i gałęzi w złożonych sieciach. Scenariusze przedstawione w tym artykule nie są w żaden sposób zaleceniami projektowymi, są po prostu przykładowymi topologiami zaprojektowanymi w celu zademonstrowania niektórych funkcji usługi Virtual WAN.

Scenariusz 1: topologia z domyślnymi preferencjami routingu

Pierwszy scenariusz w tym artykule analizuje topologię z dwoma koncentratorami usługi Virtual WAN, usługą ExpressRoute, siecią VPN i łącznością SDWAN. W każdym koncentratorze istnieją sieci wirtualne połączone bezpośrednio (11 i 21) oraz pośrednio za pośrednictwem urządzenia NVA (121, 122, 221 i 222). Sieć wirtualna 12 wymienia informacje o trasach z koncentratorem 1 za pośrednictwem BGP (zobacz komunikację równorzędną BGP z koncentratorem wirtualnym), podczas gdy sieć wirtualna 22 ma skonfigurowane statyczne trasy, co pozwala na pokazanie różnic między obiema opcjami.

W każdym koncentratorze urządzenia sieci VPN i SDWAN obsługują podwójny cel: po jednej stronie anonsują własne prefiksy (za pośrednictwem sieci VPN w koncentratorze 1 i za pośrednictwem sieci SDWAN w koncentratorze 2), a na drugim anonsują te same prefiksy co obwody usługi ExpressRoute w tym samym regionie (10.4.1.0/2410.5.3.0/24w koncentratorze 1 i 10.4.2.0/2410.5.2.0/24 w koncentratorze 2). Ta różnica zostanie wykorzystana do zademonstrowania, jak działa preferencja trasowania centrali Virtual WAN.

Wszystkie połączenia sieci wirtualnej i gałęzi są skojarzone i propagowane do domyślnej tabeli tras. Mimo że koncentratory są zabezpieczone (w każdym centrum wdrożono usługę Azure Firewall), nie są one skonfigurowane do zabezpieczania ruchu prywatnego ani internetowego. Spowoduje to propagowanie wszystkich połączeń do None tabeli tras, co spowoduje usunięcie wszystkich niestatycznych tras z Default tabeli tras i będzie sprzeczne z celem tego artykułu, ponieważ skuteczne okienko tras w portalu będzie prawie puste (z wyjątkiem tras statycznych do wysyłania ruchu do usługi Azure Firewall).

Ważne

Na poprzednim diagramie przedstawiono dwa zabezpieczone koncentratory wirtualne. Ta topologia jest obsługiwana w przypadku intencji routingu. Aby uzyskać więcej informacji, zobacz How to configure Virtual WAN Hub routing intent and routing policies (Jak skonfigurować intencję routingu i zasady routingu w usłudze Virtual WAN Hub).

Domyślnie koncentratory Virtual WAN wymieniają informacje między sobą, umożliwiając komunikację między regionami. Efektywne trasy można sprawdzić w tabelach tras usługi Virtual WAN: na przykład na poniższej ilustracji przedstawiono obowiązujące trasy w centrum 1:

Te efektywne trasy będą następnie reklamowane przez usługę Virtual WAN do odgałęzień i wprowadzą je do sieci wirtualnych połączonych z koncentratorami wirtualnymi, co uczyni zbędnym użycie ręcznie zdefiniowanych tras. Podczas inspekcji efektywnych tras w koncentratorze wirtualnym pola "Typ następnego przeskoku" i "Źródło" będą wskazywać, skąd pochodzą trasy. Na przykład typ następnego przeskoku "Połączenie z siecią wirtualną" wskazuje, że prefiks jest zdefiniowany w sieci VNets bezpośrednio połączonej z usługą Virtual WAN (VNets 11 i 12 na poprzednim zrzucie ekranu)

Urządzenie NVA w sieci wirtualnej 12 wprowadza trasę 10.1.20.0/22 za pośrednictwem protokołu BGP, co sugeruje typ następnego przeskoku "HubBgpConnection" (zobacz Komunikacja równorzędna BGP z węzłem wirtualnym). Ta trasa podsumowująca obejmuje zarówno pośrednie VNety 121 (10.1.21.0/24) i 122 (10.1.22.0/24). Sieci wirtualne i gałęzie w koncentratorze zdalnym są widoczne z następnym przeskokiem hub2, a na ścieżce AS można zauważyć, że numer systemu autonomicznego 65520 został dołączony dwa razy do tych tras międzyhubowych.

W hubie 2 znajduje się zintegrowane wirtualne urządzenie SDWAN. Aby uzyskać więcej informacji na temat obsługiwanych NVAs na potrzeby tej integracji, odwiedź stronę About NVAs in a Virtual WAN hub (Informacje o NVAs w koncentratorze usługi Virtual WAN). Pamiętaj, że trasa do oddziału 10.5.3.0/24 SDWAN ma następny przeskok VPN_S2S_Gateway. Ten rodzaj następnego przeskoku może wskazywać obecnie zarówno trasy pochodzące z bramy sieci wirtualnej platformy Azure, jak i z integrowanych w centrum urządzeń NVA.

W koncentratorze 2 trasa dla 10.2.20.0/22 do pośrednich szprych VNet 221 (10.2.21.0/24) i VNet 222 (10.2.22.0/24) jest instalowana jako trasa statyczna, jak wskazuje źródło defaultRouteTable. Jeśli sprawdzisz obowiązujące trasy dla węzła 1, tej trasy tam nie ma. Powodem jest to, że trasy statyczne nie są propagowane za pośrednictwem protokołu BGP, ale należy je skonfigurować w każdym koncentratorze. W związku z tym trasa statyczna jest wymagana w koncentratonie 1 w celu zapewnienia łączności między sieciami wirtualnymi i gałęziami w koncentratonie 1 do szprych pośrednich w koncentratonie 2 (sieci wirtualne 221 i 222):

Po dodaniu trasy statycznej, również koncentrator 1 będzie zawierał trasę 10.2.20.0/22.

Scenariusz 2. Preferencja routingu globalnego zasięgu i koncentratora

Nawet jeśli piasta 1 zna prefiks usługi ExpressRoute z obwodu 2 (10.5.2.0/24) i piasta 2 zna prefiks usługi ExpressRoute z obwodu 1 (10.4.2.0/24), trasy usługi ExpressRoute z regionów zdalnych nie są ogłaszane z powrotem do lokalnych łączy usługi ExpressRoute. W związku z tym usługa ExpressRoute Global Reach jest wymagana, aby lokalizacje usługi ExpressRoute komunikowały się ze sobą:

Ważne

Na poprzednim diagramie przedstawiono dwa zabezpieczone koncentratory wirtualne. Ta topologia jest obsługiwana przez Intencję Routingu. Aby uzyskać więcej informacji, zobacz How to configure Virtual WAN Hub routing intent and routing policies (Jak skonfigurować intencję routingu i zasady routingu w usłudze Virtual WAN Hub).

Jak wyjaśniono w preferencjach routingu koncentratora wirtualnego, usługa Virtual WAN domyślnie faworyzuje trasy pochodzące z usługi ExpressRoute. Ponieważ trasy są anonsowane z koncentratora 1 do obwodu usługi ExpressRoute 1, z obwodu usługi ExpressRoute 1 do obwodu 2, a z obwodu usługi ExpressRoute 2 do koncentratora 2 (i odwrotnie), koncentratory wirtualne preferują tę ścieżkę zamiast bardziej bezpośredniego połączenia między koncentratorami. Obowiązujące trasy w węźle 1 przedstawiają to:

Jak można zauważyć w trasach, usługa ExpressRoute Global Reach wielokrotnie dodaje numer systemu autonomicznego ExpressRoute (12076) przed wysłaniem tras z powrotem do platformy Azure, aby te trasy były mniej preferowane. Jednak domyślny priorytet routingu koncentratora usługi ExpressRoute w usłudze Virtual WAN ignoruje długość ścieżki AS podczas podejmowania decyzji o routingu.

Obowiązujące trasy w centrum 2 będą podobne:

Preferencję routingu można zmienić na VPN lub AS-Path, zgodnie z opisem w preferencjach routingu koncentratora wirtualnego. Można na przykład ustawić preferencję sieci VPN.

Przy preferencji routingu węzła jako VPN, efektywne trasy w węźle 1 wyglądają następująco:

Na poprzedniej ilustracji pokazano, że trasa do 10.4.2.0/24 teraz ma następny przeskok VPN_S2S_Gateway, podczas gdy z domyślną preferencją routingu usługi ExpressRoute był to ExpressRouteGateway. Jednak w centrum 2 trasa do 10.5.2.0/24 będzie nadal wyświetlana z następnym przeskokiem ExpressRoute, ponieważ w tym przypadku alternatywna trasa nie pochodzi z bramy sieci VPN, ale z urządzenia NVA zintegrowanego z centrum.

Jednak ruch między punktami nadal preferuje trasy przez ExpressRoute. Aby użyć bardziej wydajnego bezpośredniego połączenia między koncentratorami wirtualnymi, preferencję trasy można ustawić na "Ścieżka AS" w obu koncentratorach.

Teraz trasy dla zdalnych segmentów i gałęzi w centralach 1 będą miały kolejny przeskok zgodnie z oczekiwaniami na Remote Hub.

Widać, że prefiks IP dla koncentratora 2 (192.168.2.0/23) nadal jest dostępny za pośrednictwem linku Global Reach, ale nie powinien to mieć wpływu na ruch, ponieważ nie powinien istnieć żaden ruch skierowany do urządzeń w centrum 2. Ścieżka ta może stanowić problem, jeśli w obu koncentratorach znajdują się połączone ze sobą urządzenia NVAs, ustanawiające tunele SDWAN.

Należy jednak pamiętać, że 10.4.2.0/24 jest teraz preferowana przez usługę VPN Gateway. Może się tak zdarzyć, jeśli trasy anonsowane za pośrednictwem sieci VPN mają krótszą ścieżkę AS niż trasy anonsowane za pośrednictwem usługi ExpressRoute. Po skonfigurowaniu lokalnego urządzenia sieci VPN w celu dodania do tras sieci VPN numeru systemu autonomicznego (65501), aby uczynić je mniej preferowanymi, centrum 1 wybiera teraz usługę ExpressRoute jako następny przeskok dla:10.4.2.0/24

Hub 2 wyświetli podobną tabelę dla efektywnych tras, w której sieci wirtualne i gałęzie w innym hubie teraz pokazują Remote Hub jako następny przeskok.

Scenariusz 3: Łączenie krzyżowe obwodów ExpressRoute z oboma koncentratorami

Aby dodać bezpośrednie połączenia między regionami platformy Azure a lokalizacjami wewnętrznymi połączonymi za pośrednictwem ExpressRoute, często pożądane jest połączenie jednego obwodu ExpressRoute z wieloma koncentratorami Virtual WAN w topologii opisanej czasami jako "kokarda", co pokazuje poniższa topologia.

Ważne

Na poprzednim diagramie przedstawiono dwa zabezpieczone koncentratory wirtualne. Ta topologia jest wspierana przez mechanizm routingu. Aby uzyskać więcej informacji, zobacz How to configure Virtual WAN Hub routing intent and routing policies (Jak skonfigurować intencję routingu i zasady routingu w usłudze Virtual WAN Hub).

Usługa Virtual WAN pokazuje, że oba obwody są połączone z obydwoma koncentratorami:

Po powrocie do domyślnej preferencji routingu koncentratora ExpressRoute trasy do zdalnych gałęzi i sieci wirtualnych w hubie 1 znów pokażą ExpressRoute jako następny przeskok. Chociaż tym razem przyczyną nie jest Global Reach, ale fakt, że obwody usługi ExpressRoute odbijają anonse tras, które uzyskują z jednego koncentratora do drugiego. Na przykład efektywne trasy koncentratora 1 z preferencją routingu ExpressRoute są następujące:

Ponowna zmiana preferencji routingu koncentratora na trasę AS powoduje, że ścieżki między koncentratorami wracają na optymalną trasę, korzystając z bezpośredniego połączenia między koncentratorami 1 i 2.

Następne kroki

Aby uzyskać więcej informacji na temat usługi Virtual WAN, zobacz:

• Usługa Virtual WAN — często zadawane pytania