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 między sieciami wirtualnymi platformy Azure i lokalizacjami lokalnymi za pośrednictwem sieci VPN typu punkt-lokacja, sieci VPN typu lokacja-lokacja, usługi ExpressRoute i zintegrowanych urządzeń SDWAN, w tym opcji 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 koncentratoście istnieją sieci wirtualne połączone bezpośrednio (sieci wirtualne 11 i 21) oraz pośrednio za pośrednictwem urządzenia WUS (sieci wirtualne 121, 122, 221 i 222). Sieć wirtualna 12 wymienia informacje o routingu z koncentratorem 1 za pośrednictwem protokołu BGP (zobacz komunikacja równorzędna BGP z koncentratorem wirtualnym), a sieć wirtualna 22 ma skonfigurowane trasy statyczne, dzięki czemu można wyświetlić różnice między obiem opcją.
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.4.2.0/24w koncentratorze 1 i 10.5.3.0/24 10.5.2.0/24 w koncentratorze 2). Ta różnica będzie używana do zademonstrowania sposobu działania preferencji routingu koncentratora usługi 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 niestacjonanych tras z Default tabeli tras i pokonanie celu tego artykułu, ponieważ skuteczny blok trasy w portalu będzie prawie pusty (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).
Poza tym koncentratory usługi Virtual WAN wymieniają informacje między sobą, aby komunikacja między regionami została włączona. 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 obowiązujące trasy będą następnie anonsowane przez usługę Virtual WAN do gałęzi i będą wprowadzać je do sieci wirtualnych połączonych z koncentratorami wirtualnymi, co spowoduje niepotrzebne użycie tras zdefiniowanych przez użytkownika. Podczas inspekcji obowiązujących tras w koncentratonie wirtualnym pola "Typ następnego przeskoku" i "Źródło" będą wskazywać, skąd pochodzą trasy. Na przykład typ następnego przeskoku "Sieć wirtualna Połączenie ion" wskazuje, że prefiks jest zdefiniowany w sieci wirtualnej bezpośrednio połączonej z usługą Virtual WAN (sieci wirtualne 11 i 12 na poprzednim zrzucie ekranu)
Urządzenie WUS w sieci wirtualnej 12 wprowadza trasę 10.1.20.0/22 za pośrednictwem protokołu BGP, ponieważ typ następnego przeskoku "HubBgp Połączenie ion" oznacza (zobacz Komunikacja równorzędna BGP z koncentratorem wirtualnym). Ta trasa podsumowania obejmuje zarówno pośrednią sieć wirtualną szprychy 121 (10.1.21.0/24) i sieć wirtualną 122 (10.1.22.0/24). Sieci wirtualne i gałęzie w koncentratorze zdalnym są widoczne z następnym przeskokiem hub2i można je zobaczyć w ścieżce AS, że numer 65520 systemu autonomicznego został dołączony dwa razy do tych tras międzyhubowych.
W koncentratonie 2 znajduje się zintegrowane wirtualne urządzenie sieciowe SDWAN. Aby uzyskać więcej informacji na temat obsługiwanych urządzeń WUS na potrzeby tej integracji, odwiedź stronę About NVAs in a Virtual WAN hub (Informacje o urządzeniach WUS w koncentratorze usługi Virtual WAN). Pamiętaj, że trasa do gałęzi 10.5.3.0/24 SDWAN ma następny przeskok .VPN_S2S_Gateway Ten typ następnego przeskoku może wskazywać na dzisiejsze trasy pochodzące z bramy sieci wirtualnej platformy Azure lub z urządzeń WUS zintegrowanych z koncentratorem.
W koncentratonie 2 trasa dla 10.2.20.0/22 sieci wirtualnej szprych 221 (10.2.21.0/24) i sieci wirtualnej 222 (10.2.22.0/24) jest instalowana jako trasa statyczna, jak wskazuje źródło defaultRouteTable. Jeśli zaewidencjonujesz obowiązujące trasy dla centrum 1, ta trasa nie istnieje. Przyczyną jest to, że trasy statyczne nie są propagowane za pośrednictwem protokołu BGP, ale należy je skonfigurować w każdym koncentratoście. 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 koncentrator 1 będzie również zawierać 10.2.20.0/22 trasę:
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 piasty 2 zna prefiks usługi ExpressRoute z obwodu 1 (10.4.2.0/24), trasy usługi ExpressRoute z regionów zdalnych nie są anonsowane 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 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).
Jak wyjaśniono w preferencjach routingu koncentratora wirtualnego, usługa Virtual WAN faworyzuje trasy pochodzące z usługi ExpressRoute na wartość domyślną. 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ę za pośrednictwem bardziej bezpośredniego połączenia między koncentratorami. Obowiązujące trasy w centrum 1 pokazują to:
Jak widać w trasach, usługa ExpressRoute Global Reach wielokrotnie poprzedza numer systemu autonomicznego usługi ExpressRoute (12076) przed wysłaniem tras z powrotem na platformę 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. Na przykład można ustawić preferencję sieci VPN, jak pokazano na poniższej ilustracji:
W przypadku preferencji routingu koncentratora sieci VPN obowiązujące trasy w centrum 1 wyglądają następująco:
Na poprzedniej ilustracji pokazano, że trasa, do 10.4.2.0/24 którego ma teraz następny przeskok VPN_S2S_Gateway, natomiast z domyślnym preferencją routingu usługi ExpressRoute była 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 WUS zintegrowanego w centrum:
Jednak ruch między koncentratorami nadal preferuje trasy przychodzące za pośrednictwem usługi ExpressRoute. Aby użyć bardziej wydajnego bezpośredniego połączenia między koncentratorami wirtualnymi, preferencji trasy można ustawić na "Ścieżka AS" w obu koncentratorach:
Teraz trasy dla zdalnych szprych i gałęzi w piastze 1 będą miały następny przeskok zgodnie z Remote Hub oczekiwaniami:
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. Ta trasa może być jednak problemem, jeśli w obu koncentratorach istnieją urządzenia WUS tworzące tunele SDWAN między sobą.
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 wstępnego przydzielenia numeru systemu autonomicznego (65501) do tras sieci VPN w celu uzyskania mniej preferowanego centrum 1 wybiera teraz usługę ExpressRoute jako następny przeskok dla :10.4.2.0/24
Centrum 2 wyświetli podobną tabelę dla obowiązujących tras, w której sieci wirtualne i gałęzie w innym centrum będą teraz wyświetlane Remote Hub jako następny przeskok:
Scenariusz 3. Łączenie krzyżowe obwodów usługi ExpressRoute z obydwoma koncentratorami
Aby dodać bezpośrednie połączenia między regionami platformy Azure i lokalizacjami lokalnymi połączonymi za pośrednictwem usługi ExpressRoute, często pożądane jest połączenie jednego obwodu usługi ExpressRoute z wieloma koncentratorami usługi Virtual WAN w topologii czasami opisane jako "bow tie", jak pokazano w poniższej topologii:
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).
Usługa Virtual WAN pokazuje, że oba obwody są połączone z obydwoma koncentratorami:
Po powrocie do domyślnej preferencji routingu koncentratora usługi ExpressRoute trasy do zdalnych gałęzi i sieci wirtualnych w centrum 1 będą ponownie wyświetlane w usłudze 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 obowiązujące trasy koncentratora 1 z preferencjami routingu koncentratora usługi ExpressRoute są następujące:
Zmiana preferencji routingu koncentratora ponownie na ścieżkę AS zwraca trasy między koncentratorami do optymalnej ścieżki przy użyciu 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