Jak skonfigurować intencje routingu i zasady routingu koncentratora usługi Virtual WAN

Intencja routingu usługi Virtual WAN Hub umożliwia skonfigurowanie prostych i deklaratywnych zasad routingu w celu wysyłania ruchu do rozwiązań zabezpieczeń typu bump-in-the-wire, takich jak Azure Firewall, wirtualne urządzenia sieciowe lub rozwiązania typu oprogramowanie jako usługa (SaaS) wdrożone w koncentratorze usługi Virtual WAN.

Tło

Intencje routingu i polityki routingu umożliwiają skonfigurowanie koncentratora usługi Virtual WAN w celu przekazywania ruchu internetowego i prywatnego (sieci VPN typu punkt-lokacja, sieci VPN typu lokacja-lokacja, usługi ExpressRoute, sieci wirtualnej i wirtualnego urządzenia sieciowego) do usługi Azure Firewall, zapory nowej generacji (NGFW), wirtualnego urządzenia sieciowego (NVA) lub rozwiązania zabezpieczeń oprogramowania jako usługi (SaaS) wdrożonego w koncentratorze wirtualnym.

Istnieją dwa typy zasad routingu: ruch internetowy i zasady routingu ruchu prywatnego. Każde wirtualne centrum sieci WAN może mieć co najwyżej jedną zasadę routingu ruchu internetowego i jedną zasadę routingu ruchu prywatnego, z których każda ma jeden własny zasób następnego przeskoku. Chociaż ruch prywatny obejmuje zarówno prefiksy adresów gałęzi, jak i sieci wirtualnej, zasady routingu uznają je za jedną jednostkę w ramach pojęć dotyczących intencji routingu.

• Zasady routingu ruchu internetowego: Gdy zasady routingu ruchu internetowego są skonfigurowane w koncentratorze sieci Virtual WAN, wszystkie połączenia oddziałowe (sieć VPN użytkownika zdalnego typu punkt-lokacja, sieć VPN typu lokacja-lokacja i usługa ExpressRoute) oraz połączenia sieci wirtualnej z tym koncentratorem przesyłają ruch skierowany do Internetu do usługi Azure Firewall, dostawcy zabezpieczeń innych firm, wirtualnego urządzenia sieciowego lub rozwiązania SaaS określonego w ramach zasad routingu.

  Innymi słowy, gdy zasady routingu ruchu internetowego są skonfigurowane w koncentratorze Virtual WAN, Virtual WAN anonsuje domyślną trasę (0.0.0.0/0) do wszystkich odgałęzień, bram i wirtualnych urządzeń sieciowych (wdrożonych w koncentratorze lub odgałęzieniach).

• Polityka routingu ruchu prywatnego: Gdy w koncentratorze usługi Virtual WAN skonfigurowana jest polityka routingu ruchu prywatnego, cały ruch gałęzi i sieci wirtualnej w ramach i poza koncentratorem wirtualnym, w tym ruch między koncentratorami, jest przekazywany do następnego przeskoku, takiego jak Azure Firewall, wirtualne urządzenie sieciowe lub rozwiązanie SaaS.

  Innymi słowy, gdy zasady routingu ruchu prywatnego są konfigurowane w koncentratorze usługi Virtual WAN, cały ruch: między oddziałami, między oddziałem a siecią wirtualną, między siecią wirtualną a oddziałem i między koncentratorami, jest wysyłany za pośrednictwem usługi Azure Firewall, wirtualnego urządzenia sieciowego lub rozwiązania SaaS wdrożonego w koncentratorze usługi Virtual WAN.

Przypadki użycia

W poniższej sekcji opisano dwa typowe scenariusze, w których zasady routingu są stosowane do zabezpieczonych koncentratorów wirtualnej sieci WAN.

Wszystkie koncentratory usługi Virtual WAN są zabezpieczone (wdrażane za pomocą usługi Azure Firewall, NVA lub rozwiązania SaaS)

W tym scenariuszu wszystkie koncentratory usługi Virtual WAN są wdrażane z Azure Firewall, urządzeniem NVA lub rozwiązaniem SaaS. W tym scenariuszu można skonfigurować zasady routingu ruchu internetowego, zasady routingu ruchu prywatnego lub oba te zasady w każdym koncentratorze usługi Virtual WAN.

Rozważ następującą konfigurację, w której centrum 1 i centrum 2 mają zasady routingu zarówno dla ruchu prywatnego, jak i internetowego.

Konfiguracja koncentratora 1:

• Polityka ruchu prywatnego z Next Hop Hub 1 w usłudze Azure Firewall, NVA lub rozwiązanie SaaS.
• Polityka ruchu internetowego z wykorzystaniem Next Hop Hub 1, z rozwiązaniem Azure Firewall, NVA lub SaaS.

Konfiguracja hubu 2:

• Zasady ruchu prywatnego z urządzeniem Next Hop Hub 2 dla rozwiązania Azure Firewall, NVA lub SaaS.
• Polityka ruchu internetowego z usługi Next Hop Hub 2 Azure Firewall, NVA lub rozwiązanie SaaS

Poniżej przedstawiono przepływy ruchu wynikające z takiej konfiguracji.

Uwaga

Ruch internetowy musi przechodzić przez lokalne rozwiązanie zabezpieczeń w centrum, ponieważ trasa domyślna (0.0.0.0/0) nie jest propagowana przez węzły.

Źródło	Do	Sieci 1 Hub VNets	Gałęzie węzła 1	Hub 2 sieci wirtualne	Oddziały węzła 2	Internet
Sieci 1 Hub VNets	→	Hub 1 AzFW lub NVA	Hub 1 AzFW lub NVA	Hub 1 i 2 AzFW, NVA lub SaaS	Hub 1 i 2 AzFW, NVA lub SaaS	Hub 1 AzFW, NVA lub SaaS
Gałęzie węzła 1	→	Hub 1 AzFW, NVA lub SaaS	Hub 1 AzFW, NVA lub SaaS	Hub 1 i 2 AzFW, NVA lub SaaS	Hub 1 i 2 AzFW, NVA lub SaaS	Hub 1 AzFW, NVA lub SaaS
Hub 2 sieci wirtualne	→	Hub 1 i 2 AzFW, NVA lub SaaS	Hub 1 i 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS
Oddziały Węzła 2	→	Hub 1 i 2 AzFW, NVA lub SaaS	Hub 1 i 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	Hub 2AzFW, NVA lub SaaS

Wdrażanie zabezpieczonych i zwykłych koncentratorów usługi Virtual WAN

W tym scenariuszu nie wszystkie koncentratory w sieci WAN to zabezpieczone koncentratory wirtualnej sieci WAN (koncentratory z wdrożonym w nich rozwiązaniem zabezpieczeń).

Rozważ następującą konfigurację, w której koncentrator 1 (normalny) i koncentrator 2 (zabezpieczone) są wdrażane w wirtualnej sieci WAN. Centrum 2 ma zasady routingu zarówno dla ruchu prywatnego, jak i internetowego.

Konfiguracja huba 1:

• Nie dotyczy (nie można skonfigurować zasad routingu, jeśli centrum nie zostało wdrożone przy użyciu usługi Azure Firewall, urządzenia NVA lub rozwiązania SaaS)

Konfiguracja Hubu 2:

• Polityka ruchu prywatnego z Next Hop Hub 2 z Azure Firewall, NVA lub rozwiązaniem SaaS.
• Zasady ruchu internetowego z Next Hop Hub 2 z wykorzystaniem rozwiązania Azure Firewall, NVA lub SaaS.

Poniżej przedstawiono przepływy ruchu wynikające z takiej konfiguracji. Gałęzie i sieci wirtualne połączone z koncentratorem 1 nie mogą uzyskać dostępu do Internetu za pośrednictwem rozwiązania zabezpieczeń wdrożonego w centrum, ponieważ trasa domyślna (0.0.0.0/0) nie jest propagowana między koncentratorami.

Źródło	Do	Sieci 1 Hub VNets	Gałęzie węzła 1	Hub 2 sieci wirtualne	Oddziały węzła 2	Internet
Sieci 1 Hub VNets	→	Bezpośredni	Bezpośredni	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	-
Gałęzie węzła 1	→	Bezpośredni	Bezpośredni	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	-
Hub 2 sieci wirtualne	→	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS
Oddziały Węzła 2	→	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS	Hub 2 AzFW, NVA lub SaaS

Znane ograniczenia

• W poniższej tabeli opisano dostępność intencji routingu w różnych środowiskach platformy Azure.
  • Intencja routingu nie jest dostępna na platformie Microsoft Azure obsługiwanej przez 21 Vianet.
  • Aplikacja Palo Alto Cloud NGFW jest dostępna tylko w publicznej wersji platformy Azure. Skontaktuj się z firmą Palo Alto Networks w zakresie dostępności rozwiązania Cloud NGFW na platformie Azure Government i platformy Microsoft Azure obsługiwanej przez Firmę Viacom.
  • Wirtualne urządzenia sieciowe nie są dostępne we wszystkich regionach świadczenia usługi Azure Government. Skontaktuj się z partnerem NVA dotyczącym dostępności w Azure Government.

Środowisko chmury	Azure Firewall	Wirtualne urządzenie sieciowe	Rozwiązania SaaS
Publiczna platforma Azure	Tak	Tak	Tak
Azure Government (usługi chmury dla administracji publicznej)	Tak	Ograniczony	Nie.
Platforma Microsoft Azure obsługiwana przez 21 Vianet	Nie.	Nie.	Nie.

• Zamiar routingu upraszcza routing poprzez zarządzanie skojarzeniami tabeli tras i propagacjami dla każdego połączenia (sieć wirtualna, sieć VPN typu lokacja-lokacja, sieć VPN typu punkt-lokacja i usługa ExpressRoute). Wirtualne sieci WAN z niestandardowymi tabelami tras i dostosowanymi zasadami nie mogą być używane z konstrukcjami intencji routingu.
• Zaszyfrowana usługa ExpressRoute (tunele VPN typu lokacja-lokacja uruchomione za pośrednictwem obwodów ExpressRoute) jest wspierana w hubach, gdzie skonfigurowano intencję trasowania, pod warunkiem że usługa Azure Firewall jest skonfigurowana do zazwalania na ruch pomiędzy punktami końcowymi tunelu VPN (prywatny adres IP bramy VPN typu lokacja-lokacja i prywatny adres IP lokalnego urządzenia VPN). Aby uzyskać więcej informacji na temat wymaganych konfiguracji, zobacz Zaszyfrowana usługa ExpressRoute z intencją routingu.
• Następujące przypadki użycia połączeń nie są obsługiwane przez Routing Intent:
  • Trasy statyczne w domyślnej tabeliRouteTable wskazujące połączenie sieci wirtualnej nie mogą być używane w połączeniu z intencją routingu. Można jednak użyć funkcji peeringu BGP.
  • Trasy statyczne na połączeniu sieci wirtualnej z "propagacją tras statycznych" nie są stosowane do zasobu następnego przeskoku określonego w prywatnych zasadach routingu. Obsługa stosowania tras statycznych w połączeniach sieci wirtualnej do następnego przeskoku zgodnie z polityką routingu prywatnego jest w planach.
  • Możliwość wdrożenia zarówno urządzenia SD-WAN Connectivity NVA, jak i oddzielnego urządzenia Firewall NVA lub rozwiązania SaaS w tym samym koncentratorze usługi Virtual WAN jest obecnie na etapie planowania. Po skonfigurowaniu intencji routingu przy użyciu rozwiązania SaaS następnego przeskoku lub urządzenia sieciowego zapory NVA, łączność między wirtualnym urządzeniem SD-WAN NVA a platformą Azure jest zmieniana. Zamiast tego wdróż rozwiązanie SD-WAN NVA i firewall NVA lub SaaS w różnych koncentratorach wirtualnych. Alternatywnie można również wdrożyć urządzenie NVA SD-WAN w sieci wirtualnej typu spoke połączonej z piastą i korzystać z funkcji peeringu BGP wirtualnego huba.
  • Wirtualne urządzenia sieciowe (WUS) można określić tylko jako zasób docelowy dla routingu, jeśli pełnią funkcję zapory nowej generacji lub łączą rolę zapory nowej generacji i SD-WAN. Obecnie checkpoint, fortinet-ngfw, fortinet-ngfw-and-sdwan i cisco-tdv-vwan-nva są jedynymi NVAs, które kwalifikują się do skonfigurowania jako następny punkt przeskoku dla zamierzeń routingu. Jeśli spróbujesz określić inny NVA, tworzenie celu routingu zakończy się niepowodzeniem. Typ urządzenia WUS można sprawdzić, przechodząc do swojego Wirtualnego Centrum -> Urządzenia Sieciowe, a następnie przeglądając pole Dostawca. Palo Alto Networks Cloud NGFW jest również obsługiwane jako następny przeskok dla Routing Intent, ale jest to następny przeskok typu rozwiązanie SaaS.
  • Użytkownicy programu Routing Intent, którzy chcą połączyć wiele połączeń ExpressRoute z usługą Virtual WAN i wysyłać ruch pomiędzy nimi za pomocą rozwiązania zabezpieczającego wdrożonego w centrum, mogą otworzyć zgłoszenie do pomocy technicznej, aby umożliwić ten przypadek użycia. Aby uzyskać więcej informacji, zobacz Włączanie łączności między obwodami usługi ExpressRoute.

Limity przestrzeni adresowej sieci wirtualnej

Uwaga

Maksymalna liczba przestrzeni adresowych sieci wirtualnej, którą można połączyć z jednym koncentratorem usługi Virtual WAN, jest regulowana. Otwórz zgłoszenie do pomocy technicznej platformy Azure, aby zażądać zwiększenia limitu. Limity mają zastosowanie na poziomie koncentratora usługi Virtual WAN. Jeśli masz wiele koncentratorów usługi Virtual WAN, które wymagają zwiększenia limitu, zażądaj zwiększenia limitu dla wszystkich koncentratorów usługi Virtual WAN we wdrożeniu usługi Virtual WAN.

W przypadku klientów korzystających z intencji routingu maksymalna liczba przestrzeni adresowych we wszystkich sieciach wirtualnych połączonych bezpośrednio z jednym koncentratorem usługi Virtual WAN wynosi 400. Ten limit jest stosowany indywidualnie do każdego koncentratora usługi Virtual WAN we wdrożeniu tego rozwiązania. Przestrzenie adresowe sieci wirtualnej połączone ze zdalnymi (innymi koncentratorami usługi Virtual WAN w tej samej wirtualnej sieci WAN) nie są liczone do tego limitu.

Jeśli liczba bezpośrednio połączonych przestrzeni adresowych sieci wirtualnej z koncentratorem przekroczy limit, włączenie lub zaktualizowanie intencji trasowania w Wirtualnym Koncentratorze zakończy się niepowodzeniem. W przypadku koncentratorów już skonfigurowanych z zamiarem routingu, gdzie przestrzenie adresowe sieci wirtualnej przekraczają limit w wyniku operacji, takiej jak aktualizacja przestrzeni adresowej sieci wirtualnej, nowo połączona przestrzeń adresowa może być nieroutowalna.

Proaktywnie żądaj zwiększenia limitu, jeśli łączna liczba przestrzeni adresowych we wszystkich sieciach wirtualnych połączonych lokalnie przekracza 90% udokumentowanego limitu lub jeśli masz zaplanowane operacje rozszerzania lub wdrażania sieci, które zwiększą liczbę przestrzeni adresowych sieci wirtualnej poza limitem.

Poniższa tabela zawiera przykładowe obliczenia przestrzeni adresowej sieci wirtualnej.

Centrum wirtualne	Liczba sieci wirtualnych	Przestrzenie adresowe w sieci wirtualnej	Łączna liczba przestrzeni adresowych sieci wirtualnej połączonych z koncentratorem wirtualnym	Sugerowana akcja
Węzeł nr 1	200	1	200	Nie jest wymagana żadna akcja, monitoruj liczbę przestrzeni adresowych.
Koncentrator 2	150	3	450	Wystąp o zwiększenie limitu żądań, aby móc używać intencji routingu.
Hub nr 3	370	1	370	Zwiększenie limitu żądań.

Poniższy skrypt programu PowerShell umożliwia przybliżenie liczby przestrzeni adresowych w sieciach wirtualnych połączonych z jednym koncentratorem usługi Virtual WAN. Uruchom ten skrypt dla wszystkich koncentratorów usługi Virtual WAN w Twojej konfiguracji Virtual WAN. Metryka usługi Azure Monitor, która umożliwi śledzenie i konfigurowanie alertów w połączonych przestrzeniach adresowych sieci wirtualnej, jest na planie rozwoju.

Pamiętaj, aby zmodyfikować identyfikator zasobu usługi Virtual WAN Hub w skrypecie, aby był zgodny ze środowiskiem. Jeśli posiadasz połączenia sieci wirtualnej międzydzierżawowe, upewnij się, że masz wystarczające uprawnienia do odczytu obiektu połączenia sieci wirtualnej usługi Virtual WAN oraz połączonego zasobu sieci wirtualnej.

$hubVNETconnections = Get-AzVirtualHubVnetConnection -ParentResourceId "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualHubs/<virtual hub name>"
$addressSpaceCount = 0
  
foreach($connection in $hubVNETconnections) {
  try{
    $resourceURI = $connection.RemoteVirtualNetwork.Id
    $RG = ($resourceURI -split "/")[4]
    $name = ($resourceURI -split "/")[8]
    $VNET = Get-AzVirtualNetwork -Name $name -ResourceGroupName $RG -ErrorAction "Stop"
    $addressSpaceCount += $VNET.AddressSpace.AddressPrefixes.Count
  }
  catch{
    Write-Host "An error occurred while processing VNET connected to Virtual WAN hub with resource URI:  " -NoNewline
    Write-Host $resourceURI 
    Write-Host "Error Message: " -ForegroundColor Red
    Write-Host $_.Exception.Message -ForegroundColor Red 
  }
  finally{
  }
}
Write-Host "Total Address Spaces in VNETs connected to this Virtual WAN Hub: " -ForegroundColor Green -NoNewline
Write-Host $addressSpaceCount -ForegroundColor Green

Kwestie wymagające rozważenia

Klienci, którzy obecnie korzystają z usługi Azure Firewall w koncentratorze usługi Virtual WAN bez intencji routingu, mogą włączyć intencję routingu przy użyciu usługi Azure Firewall Manager, portalu routingu koncentratora usługi Virtual WAN lub za pośrednictwem innych narzędzi do zarządzania platformy Azure (PowerShell, interfejsu wiersza polecenia, interfejsu API REST).

Przed włączeniem zamierzenia routingu, weź pod uwagę następujące kwestie:

• Intencję routingu można skonfigurować tylko w centrach, w których nie ma niestandardowych tabel tras i nie ma tras statycznych w domyślnej tabeli tras z następnym przeskokiem jako Połączenie z siecią wirtualną. Aby uzyskać więcej informacji, zobacz wymagania wstępne.
• Zapisz kopię bram, połączeń oraz tabel tras przed włączeniem funkcji routingu. System nie będzie automatycznie zapisywać i stosować poprzednich konfiguracji. Aby uzyskać więcej informacji, zobacz strategia wycofywania.
• Intencja routingu zmienia trasy statyczne w domyślnej tabeliRouteTable. Ze względu na optymalizacje witryny Azure Portal stan domyślnej tabeliRouteTable po skonfigurowaniu intencji routingu może się różnić w przypadku konfigurowania intencji routingu przy użyciu interfejsu REST, interfejsu wiersza polecenia lub programu PowerShell. Aby uzyskać więcej informacji, zobacz trasy statyczne.
• Włączenie intencji routingu wpływa na ogłaszanie prefiksów do lokalnej sieci. Aby uzyskać więcej informacji, zobacz reklamy dotyczące prefiksów.
• Możesz otworzyć zgłoszenie do wsparcia technicznego, aby włączyć łączność między obwodami usługi ExpressRoute za pośrednictwem urządzenia zapory w centrum. Włączenie tego wzorca łączności modyfikuje prefiksy ogłaszane do obwodów ExpressRoute. Aby uzyskać więcej informacji, zobacz About ExpressRoute (Informacje o usłudze ExpressRoute ).
• Zamiar routingu to jedyny mechanizm w usłudze Virtual WAN umożliwiający inspekcję ruchu między koncentratorami za pośrednictwem urządzeń zabezpieczających zainstalowanych w koncentratorze. Inspekcja ruchu między koncentratorami wymaga również włączenia intencji routingu we wszystkich koncentratorach, aby zapewnić symetryczne kierowanie ruchu między urządzeniami zabezpieczeń wdrożonymi w koncentratorach usługi Virtual WAN.
• Zamysł routingu wysyła sieć wirtualną i ruch w sieci lokalnej do zasobu następnego przeskoku określonego w polityce routingu. Usługa Virtual WAN programuje bazową platformę Azure do kierowania ruchem sieciowym w sieciach lokalnych i wirtualnych zgodnie z skonfigurowaną polityką routingu i nie przetwarza ruchu za pośrednictwem routera wirtualnego centrum. Ponieważ pakiety kierowane za pośrednictwem zamiaru routingu nie są przetwarzane przez router, nie trzeba przydzielać dodatkowych jednostek infrastruktury routingu na potrzeby przekazywania pakietów na płaszczyźnie danych na koncentratorach skonfigurowanych z zamiarem routingu. Może jednak być konieczne przydzielenie dodatkowych jednostek infrastruktury routingu na podstawie liczby maszyn wirtualnych w sieciach wirtualnych połączonych z koncentratorem usługi Virtual WAN.
• Koncepcja routingu umożliwia skonfigurowanie różnych zasobów dla następnego przeskoku dla polityk routingu prywatnego i internetowego. Można na przykład ustawić następny przeskok dla zasad routingu prywatnego na usługę Azure Firewall w centrum, a następny przeskok dla zasad routingu internetowego na wirtualne urządzenie sieciowe (NVA) lub rozwiązanie SaaS w centrum. Ponieważ rozwiązania SaaS i zapory NVA są wdrażane w tej samej podsieci w koncentratorze usługi Virtual WAN, wdrażanie rozwiązań SaaS z urządzeniem zapory NVA w tym samym koncentratorze może mieć wpływ na poziomą skalowalność rozwiązań SaaS, ponieważ dostępnych jest mniej adresów IP dla skalowania poziomego. Ponadto w każdym koncentratorze usługi Virtual WAN można wdrożyć co najwyżej jedno rozwiązanie SaaS.

Wymagania wstępne

Aby włączyć intencję i zasady routingu, centrum wirtualne musi spełniać poniższe wymagania wstępne:

• We Węźle Wirtualnym nie wdrożono niestandardowych tabel routingu. Jedyne tabele tras, które istnieją, to noneRouteTable i defaultRouteTable.
• Nie można mieć tras statycznych z połączeniem sieci wirtualnej jako następnym przeskokiem. W domyślnej tabeli RouteTable mogą istnieć trasy statyczne, które mają następny przeskok w usłudze Azure Firewall.

Opcja ustawienia intencji routingu jest wyszarzona w przypadku centrów, które nie spełniają powyższych wymagań.

Użycie intencji routingu (włącz opcję między hubami) w usłudze Azure Firewall Manager ma dodatkowy warunek:

• Trasy utworzone przez usługę Azure Firewall Manager są zgodne z konwencją nazewnictwa private_traffic, internet_traffic lub all_traffic. W związku z tym wszystkie trasy w domyślnej tabeliRouteTable muszą być zgodne z tą konwencją.

Strategia wycofania

Uwaga

Gdy konfiguracja intencji routingu zostanie całkowicie usunięta z koncentratora, wszystkie połączenia z koncentratorem są ustawione na propagowanie do domyślnej etykiety (która ma zastosowanie do wszystkich domyślnych tablic routingu w usłudze Virtual WAN). W związku z tym, jeśli rozważasz zaimplementowanie intencji routingu w wirtualnej sieci WAN, zapisz kopię istniejących konfiguracji (bram, połączeń, tabel tras), aby zastosować, jeśli chcesz przywrócić oryginalną konfigurację. System nie przywraca automatycznie poprzedniej konfiguracji.

Intencja routingu upraszcza trasowanie i konfigurację, zarządzając skojarzeniami i propagacjami wszystkich połączeń w centralnym węźle.

W poniższej tabeli opisano skojarzoną tabelę tras i propagowane tabele tras wszystkich połączeń po skonfigurowaniu zamiaru routingu.

Konfiguracja intencji routingu	Powiązana tablica tras	Propagowane tabele tras
Internet	domyślna tabela tras	etykieta domyślna (tabela tras domyślnych wszystkich centrów w sieci Virtual WAN)
Prywatne	domyślna tabela tras	noneRouteTable
Internet i prywatność	domyślna tabela tras	noneRouteTable

Trasy statyczne w domyślnej tabeliRouteTable

W poniższej sekcji opisano sposób zarządzania trasami statycznymi w domyślnej tabeli tras podczas włączania zamiaru routingu w węźle. Modyfikacje wprowadzone przez intencję routingu do domyślnej tabeliRouteTable są nieodwracalne.

Jeśli usuniesz intencję routingu, musisz ręcznie przywrócić poprzednią konfigurację. Dlatego zalecamy zapisanie migawki konfiguracji przed włączeniem funkcjonalności routingu.

Portal Menedżera Azure Firewall i Centrum Wirtualnej Sieci WAN

Gdy intencja routingu jest włączona w centrum, trasy statyczne odpowiadające skonfigurowanym zasadom routingu są tworzone automatycznie w domyślnej tabeliRouteTable. Oto te trasy:

Nazwa trasy	Prefiksy	Zasób następnego przeskoku
_polityka_PrywatnyRuch	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Azure Firewall
_polityka_PublicznyRuchDrogowy	0.0.0.0/0	Azure Firewall

Uwaga

Wszystkie trasy statyczne w domyślnej tabeliRouteTable zawierające prefiksy, które nie są dokładnie zgodne z 0.0.0.0/0 lub RFC1918 super-nets (10.0.0.0/8, 192.168.0.0/16 i 172.16.0.0/12) są automatycznie konsolidowane w jedną trasę statyczną o nazwie private_traffic. Prefiksy w domyślnej tabeli tras zgodne z nadsięciami RFC1918 lub 0.0.0.0/0 są zawsze automatycznie usuwane po skonfigurowaniu celu routingu, niezależnie od typu polityki.

Rozważmy na przykład scenariusz, w którym domyślna tabelaRouteTable ma następujące trasy przed skonfigurowaniem intencji routingu:

Nazwa trasy	Prefiksy	Zasób następnego przeskoku
prywatny_ruch	192.168.0.0/16, 172.16.0.0/12, 40.0.0.0/24, 10.0.0.0/24	Azure Firewall
to_internet	0.0.0.0/0	Azure Firewall
dodatkowy_prywatny	10.0.0.0/8, 50.0.0.0/24	Azure Firewall

Włączenie intencji routingu na tym hubie spowodowałoby następujący stan końcowy domyślnej tabeli tras. Wszystkie prefiksy, które nie są RFC1918 lub 0.0.0.0/0, są skonsolidowane w jedną trasę o nazwie private_traffic.

Nazwa trasy	Prefiksy	Zasób następnego przeskoku
_polityka_PrywatnyRuch	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Azure Firewall
_polityka_PublicznyRuchDrogowy	0.0.0.0/0	Azure Firewall
prywatny_ruch	40.0.0.0/24, 10.0.0.0/24, 50.0.0.0/24	Azure Firewall

Inne metody (PowerShell, REST, CLI)

Tworzenie intencji routingu przy użyciu metod innych niż portal automatycznie tworzy odpowiednie trasy polityk w domyślnej tabeli routingu i usuwa wszelkie prefiksy w trasach statycznych, które dokładnie pasują do 0.0.0.0/0 lub supernetów RFC1918 (10.0.0.0/8, 192.168.0.0/16 lub 172.16.0.0/12). Jednak inne trasy statyczne nie są automatycznie konsolidowane.

Rozważmy na przykład scenariusz, w którym domyślna tabelaRouteTable ma następujące trasy przed skonfigurowaniem intencji routingu:

Nazwa trasy	Prefiksy	Zasób następnego przeskoku
firewall_route_ 1	10.0.0.0/8	Azure Firewall
firewall_route_2	192.168.0.0/16, 10.0.0.0/24	Azure Firewall
firewall_route_3	40.0.0.0/24	Azure Firewall
to_internet	0.0.0.0/0	Azure Firewall

W poniższej tabeli przedstawiono ostateczny stan domyślnej tabeliRouteTable po pomyślnym utworzeniu intencji routingu. Należy pamiętać, że firewall_route_1 i to_internet zostały automatycznie usunięte jako jedyny prefiks w tych trasach to 10.0.0.0/8 i 0.0.0.0/0. firewall_route_2 został zmodyfikowany w celu usunięcia prefiksu agregacji 192.168.0.0/16, ponieważ prefiks ten jest prefiksem agregacji RFC1918.

Nazwa trasy	Prefiksy	Zasób następnego przeskoku
_polityka_PrywatnyRuch	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Azure Firewall
_polityka_PublicznyRuchDrogowy	0.0.0.0/0	Azure Firewall
firewall_route_2	10.0.0.0/24	Azure Firewall
firewall_route_3	40.0.0.0/24	Azure Firewall

Reklamowanie prefiksów w siedzibie firmy

W poniższej sekcji opisano, jak usługa Virtual WAN anonsuje trasy do środowiska lokalnego po skonfigurowaniu intencji routingu w koncentratorze wirtualnym.

Zasady routingu internetowego

Uwaga

Domyślna trasa 0.0.0.0/0 nie jest reklamowana w koncentratorach wirtualnych.

Jeśli włączysz zasady routingu internetowego w koncentratorze wirtualnym, domyślna trasa 0.0.0.0/0 jest anonsowana do wszystkich połączeń z koncentratorem (usługa ExpressRoute dla sieci wirtualnej, sieć VPN typu lokacja-lokacja, sieć VPN typu punkt-lokacja, urządzenie NVA w koncentratorze i połączenia z użyciem protokołu BGP), gdzie flaga Propaguj trasę domyślną lub Włącz zabezpieczenia internetu ma wartość true. Tę flagę można ustawić na false dla wszystkich połączeń, które nie powinny uczyć się trasy domyślnej.

Zasady routingu prywatnego

Gdy koncentrator wirtualny zostanie skonfigurowany z zasadami routingu prywatnego, usługa Virtual WAN anonsuje trasy do połączeń lokalnych w siedzibie w następujący sposób:

• Trasy odpowiadające prefiksom uzyskanym z wirtualnych sieci koncentratora lokalnego, ExpressRoute, VPN typu lokacja-do-lokacji, VPN typu punkt-do-lokacji, połączeń NVA w koncentratorze lub połączeń BGP z bieżącym koncentratorem.
• Trasy odpowiadające prefiksom poznanym z zdalnych sieci wirtualnych hubu, usługi ExpressRoute, sieci VPN typu lokacja-lokacja, sieci VPN typu punkt-lokacja, połączeń NVA w hubie lub połączeń BGP, w których skonfigurowano zasady routingu prywatnego.
• Trasy odpowiadające prefiksom uzyskanym z sieci wirtualnych koncentratora zdalnego, usługi ExpressRoute, sieci VPN typu lokacja-lokacja, sieci VPN typu punkt-punkt, połączeń NVA-in-the-hub i BGP, w których Intent routingu nie jest skonfigurowany i połączenia zdalne są propagowane do domyślnej tabeli routingu lokalnego koncentratora.
• Prefiksy uzyskane z jednego łącza ExpressRoute nie są przekazywane do innych łączy ExpressRoute, chyba że włączono Global Reach. Jeśli chcesz włączyć tranzyt między sieciami ExpressRoute za pośrednictwem rozwiązania zabezpieczeń wdrożonego w centrum sieciowym, skontaktuj się z pomocą techniczną. Aby uzyskać więcej informacji, zobacz Włączanie łączności między obwodami usługi ExpressRoute.

Kluczowe scenariusze routingu

W poniższej sekcji opisano kilka kluczowych scenariuszy routingu i zachowań routingu podczas konfigurowania intencji routingu w koncentratorze usługi Virtual WAN.

Łączność tranzytowa między obwodami usługi ExpressRoute z intencją routingu

Łączność tranzytowa między obwodami usługi ExpressRoute w usłudze Virtual WAN jest zapewniana za pośrednictwem dwóch różnych konfiguracji. Ponieważ te dwie konfiguracje nie są zgodne, klienci powinni wybrać jedną opcję konfiguracji, aby obsługiwać łączność tranzytową między dwoma obwodami usługi ExpressRoute.

Uwaga

Aby włączyć łączność tranzytową między usługami ExpressRoute za pośrednictwem urządzenia zapory w centrum sieciowym z prywatnymi zasadami routingu, otwórz zgłoszenie do pomocy technicznej do Microsoftu. Ta opcja nie jest zgodna z usługą Global Reach i wymaga wyłączenia usługi Global Reach w celu zapewnienia prawidłowego routingu tranzytowego między wszystkimi obwodami usługi ExpressRoute połączonymi z usługą Virtual WAN.

• ExpressRoute Global Reach: Usługa ExpressRoute Global Reach umożliwia dwóm obwodom z funkcją Global Reach wysyłanie ruchu między sobą bezpośrednio, bez przechodzenia przez wirtualny hub.
• Prywatna polityka routingu Routing Intent: Konfigurowanie prywatnych polityk routingu umożliwia dwóm obwodom usługi ExpressRoute wysyłanie ruchu do siebie za pośrednictwem rozwiązania zabezpieczeń wdrożonego w centralnym punkcie.

Łączność między obwodami usługi ExpressRoute za pomocą urządzenia zapory w centrum z prywatną polityką routingu z zamiarem routingu jest dostępna w następujących konfiguracjach:

• Oba obwody usługi ExpressRoute są połączone z tym samym węzłem, a w tym węźle skonfigurowano politykę routingu prywatnego.
• Obwody usługi ExpressRoute są połączone z różnymi koncentratorami, a zasady routingu prywatnego są konfigurowane na obu koncentratorach. W związku z tym oba koncentratory muszą mieć wdrożone rozwiązanie zabezpieczeń.

Zagadnienia dotyczące routingu w usłudze ExpressRoute

Uwaga

Poniższe rozważania dotyczące routingu mają zastosowanie do wszystkich koncentratorów wirtualnych w subskrypcjach, które zostały włączone przez Wsparcie Microsoft, aby umożliwiać łączność ExpressRoute do ExpressRoute za pośrednictwem urządzenia zabezpieczającego w koncentratorze.

Po włączeniu łączności tranzytowej między obwodami usługi ExpressRoute przy użyciu urządzenia zapory wdrożonego w koncentratorze wirtualnym można oczekiwać następujących zmian zachowania w sposobie anonsowania tras do lokalnej usługi ExpressRoute:

• Usługa Virtual WAN automatycznie ogłasza prefiksy agregujące RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) dla lokalnych środowisk sieciowych połączonych z usługą ExpressRoute. Te trasy agregujące są anonsowane oprócz tras opisanych w poprzedniej sekcji.
• Usługa Virtual WAN automatycznie anonsuje wszystkie trasy statyczne w tabeli tras domyślnych do obwodu usługi ExpressRoute połączonego z lokalną siecią. Oznacza to, że usługa Virtual WAN rozgłasza trasy określone w polu tekstowym prefiksu ruchu prywatnego do środowiska lokalnego.

Ze względu na te zmiany anonsowania tras oznacza to, że lokalne środowiska połączone z usługą ExpressRoute nie mogą anonsować dokładnych zakresów adresowych dla zagregowanych zakresów adresów RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Upewnij się, że reklamujesz bardziej szczegółowe podsieci w zakresach zgodnych z RFC1918, zamiast agregowanych super-sieci, oraz wszelkie prefiksy w polu tekstowym "Ruch prywatny".

Ponadto jeśli obwód usługi ExpressRoute reklamuje prefiks inny niż RFC1918 platformy Azure, upewnij się, że zakresy adresów umieszczone w polu tekstowym Prefiksy ruchu prywatnego są mniej specyficzne niż anonsowane trasy usługi ExpressRoute. Jeśli na przykład obwód usługi ExpressRoute rozgłasza 40.0.0.0/24 z lokalnej infrastruktury, umieść prefiks CIDR /23 lub większy w polu Prefiks ruchu prywatnego (na przykład: 40.0.0.0/23).

Kierowanie reklam do innych infrastruktur lokalnych (sieci VPN typu site-to-site, VPN typu point-to-site, wirtualnego urządzenia sieciowego) nie jest wpływane przez włączenie łączności tranzytowej między połączeniami ExpressRoute za pośrednictwem urządzenia zabezpieczającego wdrożonego w centrum sieciowym.

Zaszyfrowana usługa ExpressRoute

Aby użyć szyfrowanego połączenia ExpressRoute (tunel VPN typu Site-to-site uruchomiony za pośrednictwem obwodu ExpressRoute) z zamierzonymi zasadami routingu prywatnego, skonfiguruj regułę zapory, aby zezwolić na ruch między prywatnymi adresami IP tunelu bramy sieci VPN typu Site-to-site sieci WAN (źródło) i lokalnym urządzeniem sieci VPN (miejscem docelowym). Zaleca się, aby klienci korzystający z inspekcji pakietów głębokich na urządzeniu zapora sieciowa wykluczyli ruch między tymi prywatnymi adresami IP z inspekcji pakietów głębokich.

Prywatne adresy IP tunelu bramy VPN dla połączenia typu site-to-site w usłudze Virtual WAN można uzyskać, pobierając konfigurację sieci VPN i wyświetlając vpnSiteConnections —> gatewayConfiguration —> IPAddresses. Adresy IP wymienione w polu IPAddresses to prywatne adresy IP przypisane do każdego wystąpienia bramy sieci VPN typu lokacja-lokacja, które są używane do zakończenia tuneli VPN za pośrednictwem ExpressRoute. W poniższym przykładzie adresy IP tunelu na Bramie to 192.168.1.4 i 192.168.1.5.

 "vpnSiteConnections": [
      {
        "hubConfiguration": {
          "AddressSpace": "192.168.1.0/24",
          "Region": "South Central US",
          "ConnectedSubnets": [
            "172.16.1.0/24",
            "172.16.2.0/24",
            "172.16.3.0/24",
            "192.168.50.0/24",
            "192.168.0.0/24"
          ]
        },
        "gatewayConfiguration": {
          "IpAddresses": {
            "Instance0": "192.168.1.4",
            "Instance1": "192.168.1.5"
          },
          "BgpSetting": {
            "Asn": 65515,
            "BgpPeeringAddresses": {
              "Instance0": "192.168.1.15",
              "Instance1": "192.168.1.12"
            },
            "CustomBgpPeeringAddresses": {
              "Instance0": [
                "169.254.21.1"
              ],
              "Instance1": [
                "169.254.21.2"
              ]
            },
            "PeerWeight": 0
          }
        }

Prywatne adresy IP, których używają lokalne urządzenia do terminacji połączenia VPN, to adresy IP określone jako część połączenia lokalizacji sieci VPN.

Korzystając z przykładowej konfiguracji sieci VPN i lokalizacji sieci VPN wymienionej powyżej, utwórz reguły zapory, aby zezwolić na następujący ruch. Adresy IP bramy sieci VPN muszą być źródłowym adresem IP, a lokalne urządzenie sieci VPN musi być docelowym adresem IP w skonfigurowanych regułach.

Parametr reguły	Wartość
Źródłowy adres IP	192.168.1.4 i 192.168.1.5
Port źródłowy	*
Docelowy adres IP	10.100.0.4
Port docelowy	*
Protokół	DOWOLNE

Wydajność dla zaszyfrowanej usługi ExpressRoute

Konfigurowanie prywatnych zasad routingu z użyciem tras szyfrowanej ExpressRoute kieruje pakiety VPN ESP przez urządzenie zabezpieczające następnego skoku wdrożone w centrali. W związku z tym można oczekiwać maksymalnej przepływności tunelu VPN usługi ExpressRoute w szyfrowanej usłudze ExpressRoute wynoszącej 1 Gb/s w obu kierunkach (przychodzących ze środowiska lokalnego i wychodzącego z platformy Azure). Aby uzyskać maksymalną przepływność tunelu VPN, rozważ następujące optymalizacje wdrażania:

• Wdróż usługę Azure Firewall Premium zamiast usługi Azure Firewall w warstwie Standardowa lub Azure Firewall w warstwie Podstawowa.
• Upewnij się, że usługa Azure Firewall przetwarza regułę zezwalającą na ruch między punktami końcowymi tunelu sieci VPN (192.168.1.4 i 192.168.1.5 w powyższym przykładzie), najpierw określając, że reguła ma najwyższy priorytet w zasadach usługi Azure Firewall. Aby uzyskać więcej informacji na temat logiki przetwarzania reguł usługi Azure Firewall, zobacz Logika przetwarzania reguł usługi Azure Firewall.
• Wyłącz głębokie pakiety dla ruchu między punktami końcowymi tunelu SIECI VPN. Aby uzyskać informacje na temat sposobu konfigurowania usługi Azure Firewall w celu wykluczenia ruchu z inspekcji pakietów w warstwie aplikacji, zapoznaj się z dokumentacją listą omijania systemów IDPS.
• Skonfiguruj urządzenia sieci VPN do używania GCMAES256 zarówno dla szyfrowania IPSEC, jak i integralności, aby zmaksymalizować wydajność.

Routing bezpośredni do wystąpień NVA w celu zapewnienia łączności i funkcji zapory dla NVA

Uwaga

Routing bezpośredni do NVA z podwójną rolą, używany z zasadami routingu prywatnego w usłudze Virtual WAN, dotyczy tylko ruchu między sieciami wirtualnymi a trasami przekazanymi za pośrednictwem protokołu BGP przez NVA wdrożone w koncentratorze usługi Virtual WAN. Łączność tranzytowa usługi ExpressRoute i sieci VPN z lokalnymi zasobami połączonymi z NVA nie jest kierowana bezpośrednio do wystąpień NVA, lecz poprzez równoważnik obciążenia NVA działający z podwójną funkcją.

Niektóre wirtualne urządzenia sieciowe mogą mieć możliwości łączności (SD-WAN) i zabezpieczeń (NGFW) na tym samym urządzeniu. Te NVAs są uważane za NVAs z podwójną rolą. Sprawdź, czy twoje NVA jest urządzeniem NVA z podwójną rolą w ramach partnerów NVA.

Gdy zasady routingu prywatnego są skonfigurowane dla NVAs z podwójną rolą, usługa Virtual WAN automatycznie reklamuje ścieżki nauczone z urządzenia NVA koncentratora usługi Virtual WAN do bezpośrednio połączonych (lokalnych) sieci wirtualnych, a także do innych koncentratorów wirtualnych w wirtualnej sieci WAN z następnym przeskokiem jako instancję NVA, w przeciwieństwie do wewnętrznego modułu równoważenia obciążenia NVAs.

W przypadku konfiguracji aktywno-pasywnych NVA, w których tylko jedno wystąpienie NVA ogłasza trasę dla określonego prefiksu do usługi Virtual WAN (lub długość ścieżki AS-PATH tras uzyskanych z jednego z wystąpień jest zawsze najkrótsza), usługa Virtual WAN zapewnia, że ruch wychodzący z sieci wirtualnej Azure jest zawsze kierowany do aktywnego (lub preferowanego) wystąpienia NVA.

W przypadku konfiguracji aktywno-aktywnych NVA (wiele wystąpień NVA anonsuje ten sam prefiks o tej samej długości ścieżki AS), platforma Azure automatycznie wykonuje ECMP w celu kierowania ruchu z platformy Azure do środowiska lokalnego. Platforma programowo definiowanej sieci w Azure nie gwarantuje symetrii na poziomie przepływu, co oznacza, że przepływ przychodzący do Azure i wychodzący z Azure może się znaleźć na różnych wystąpieniach urządzenia wirtualnego dedykowanego (NVA). Skutkuje to routingiem asymetrycznym, który jest porzucany przez inspekcję zapory stanowej. W związku z tym nie zaleca się używania wzorców łączności aktywne-aktywne, w których NVA pełni rolę podwójną, chyba że może obsługiwać przekazywanie asymetryczne lub udostępnianie/synchronizację sesji. Aby uzyskać więcej informacji na temat tego, czy urządzenie WUS obsługuje asymetryczne przekazywanie, czy udostępnianie stanu sesji/synchronizację, skontaktuj się z dostawcą urządzenia WUS.

Konfigurowanie intencji routingu za pomocą Azure Portal

Intencje routingu i zasady routingu można skonfigurować za pośrednictwem witryny Azure Portal przy użyciu usługi Azure Firewall Manager lub portalu usługi Virtual WAN. Portal Azure Firewall Manager umożliwia konfigurowanie zasad routingu z użyciem zasobu następnego przeskoku, jakim jest Azure Firewall. Portal usługi Virtual WAN umożliwia konfigurowanie zasad routingu z wykorzystaniem zasobu następnego przeskoku, takiego jak Azure Firewall, wirtualne urządzenia sieciowe wdrożone we Wirtualnym koncentratorze lub rozwiązania SaaS.

Klienci korzystający z usługi Azure Firewall w chronionym koncentratorze Virtual WAN mogą ustawić w usłudze Azure Firewall Manager opcję „Włącz między koncentratorami" na wartość „Włączone", aby skorzystać z intencji routingu lub użyć portalu usługi Virtual WAN do bezpośredniego skonfigurowania usługi Azure Firewall jako zasobu następnego przeskoku dla intencji routingu i polityk. Konfiguracje w obu środowiskach portalu są równoważne, a zmiany w usłudze Azure Firewall Manager są automatycznie odzwierciedlane w portalu usługi Virtual WAN i na odwrót.

Konfigurowanie intencji i zasad routingu za pomocą usługi Azure Firewall Manager

W poniższych krokach opisano sposób konfigurowania intencji routingu i zasad routingu w centrum wirtualnym przy użyciu usługi Azure Firewall Manager. Usługa Azure Firewall Manager obsługuje tylko zasoby następnego przeskoku typu Azure Firewall.

1. Przejdź do koncentratora usługi Virtual WAN, w którym chcesz skonfigurować zasady routingu.

2. W obszarze Zabezpieczenia wybierz Zabezpieczone ustawienia koncentratora wirtualnego, a następnie Zarządzaj ustawieniami dostawcy zabezpieczeń i tras dla tego zabezpieczonego koncentratora wirtualnego w usłudze Azure Firewall Manager.

3. Z menu wybierz koncentrator, na którym chcesz skonfigurować zasady routingu.

4. Wybierz pozycję Konfiguracja zabezpieczeń w obszarze Ustawienia

5. Jeśli chcesz skonfigurować zasady routingu ruchu internetowego, wybierz pozycję Azure Firewall lub odpowiedniego dostawcę zabezpieczeń internetowych z listy rozwijanej dla ruchu internetowego. Jeśli nie, wybierz pozycję Brak

6. Jeśli chcesz skonfigurować zasady routingu ruchu prywatnego (dla ruchu gałęzi i sieci wirtualnej) za pośrednictwem usługi Azure Firewall, wybierz pozycję Azure Firewall z listy rozwijanej dla ruchu prywatnego. W przeciwnym razie wybierz Pomiń Azure Firewall.

   

7. Jeśli chcesz skonfigurować zasady routingu ruchu prywatnego i mieć gałęzie lub sieci wirtualne anonsujące prefiksy inne niż IANA RFC1918, wybierz pozycję Prefiksy ruchu prywatnego i określ zakresy prefiksów innych niż IANA RFC1918 w wyświetlonym polu tekstowym. Wybierz pozycję Gotowe.

   

8. Wybierz Inter-hub, aby ustawić na Włączone. Włączenie tej opcji gwarantuje, że zasady routingu są stosowane do intencji routingu tego centrum sieci Virtual WAN.

9. Wybierz pozycję Zapisz.

10. Powtórz kroki 2–8 dla innych zabezpieczonych koncentratorów usługi Virtual WAN, dla których chcesz skonfigurować zasady routingu.

11. Na tym etapie możesz wysłać ruch testowy. Upewnij się, że zasady zapory są odpowiednio skonfigurowane tak, aby zezwalać na ruch i odmawiać go na podstawie żądanych konfiguracji zabezpieczeń.

Konfigurowanie intencji routingu i zasad za pośrednictwem portalu usługi Virtual WAN

W poniższych krokach opisano sposób konfigurowania intencji routingu i zasad routingu w koncentratorze wirtualnym przy użyciu portalu usługi Virtual WAN.

1. Z poziomu linku portalu niestandardowego podanego w wiadomości e-mail z potwierdzeniem z kroku 3 w sekcji Wymagania wstępne przejdź do centrum usługi Virtual WAN, w którym chcesz skonfigurować zasady routingu.

2. W obszarze Routing wybierz pozycję Zasady routingu.

   

3. Jeśli chcesz skonfigurować zasady routingu ruchu prywatnego (dla ruchu sieciowego w gałęzi i sieci wirtualnej), wybierz pozycję Azure Firewall, wirtualne urządzenie sieciowe lub rozwiązania SaaS w obszarze Ruch prywatny. W obszarze Zasób następnego przeskoku wybierz odpowiedni następny zasób przeskoku.

   

4. Jeśli chcesz skonfigurować zasady routingu ruchu prywatnego i mieć gałęzie lub sieci wirtualne przy użyciu prefiksów innych niż IANA RFC1918, wybierz pozycję Dodatkowe prefiksy i określ zakresy prefiksów innych niż IANA RFC1918 w wyświetlonym polu tekstowym. Wybierz pozycję Gotowe. Upewnij się, że we wszystkich koncentratorach wirtualnych skonfigurowanych przy użyciu zasad routingu prywatnego dodano ten sam prefiks w polu tekstowym prefiksu ruchu prywatnego, aby zapewnić prawidłowe anonsowanie tras do wszystkich koncentratorów.

   

5. Jeśli chcesz skonfigurować zasady routingu ruchu internetowego, wybierz pozycję Azure Firewall, wirtualne urządzenie sieciowe lub rozwiązanie SaaS. W obszarze Zasób następnego przeskoku wybierz odpowiedni następny zasób przeskoku.

   

6. Aby zastosować konfigurację intencji routingu i zasad routingu, kliknij przycisk Zapisz.

   

7. Powtórz dla wszystkich hubów, dla których chcesz skonfigurować zasady routingu.

8. Na tym etapie możesz wysłać ruch testowy. Upewnij się, że zasady zapory są odpowiednio skonfigurowane tak, aby zezwalać na ruch i odmawiać go na podstawie żądanych konfiguracji zabezpieczeń.

Konfigurowanie intencji routingu przy użyciu pliku Bicep

Aby uzyskać informacje o szablonie i krokach, zobacz plik Bicep .

Rozwiązywanie problemów

W poniższej sekcji opisano typowe sposoby rozwiązywania problemów podczas konfigurowania intencji routingu i zasad w usłudze Virtual WAN Hub.

Obowiązujące trasy

Uwaga

Pobieranie efektywnych tras stosowanych w zasobach następnego przeskoku określonych w ustawieniu routingu usługi Virtual WAN jest obsługiwane tylko dla tych zasobów, które są określone w polityce routingu prywatnego. Jeśli używasz zarówno zasad routingu prywatnego, jak i internetowego, sprawdź efektywne trasy w zasobie następnego przeskoku określonym w zasadach routingu prywatnego oraz efektywne trasy, które programy Virtual WAN stosują w zasobie następnego przeskoku w zasadach routingu internetowego. Jeśli używasz tylko zasad routingu internetowego, sprawdź obowiązujące trasy w domyślnej tablicy tras, aby wyświetlić trasy zaprogramowane w zasobie zasad routingu internetowego następnego przeskoku.

Gdy zasady routingu prywatnego są konfigurowane w koncentratonie wirtualnym, cały ruch między sieciami lokalnymi i wirtualnymi jest sprawdzany przez usługę Azure Firewall, wirtualne urządzenie sieciowe lub rozwiązanie SaaS w koncentratonie wirtualnym.

W związku z tym efektywne trasy domyślnej tabeli tras (defaultRouteTable) pokazują prefiksy agregacyjne RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) z kolejnym przeskokiem do Azure Firewall lub do wirtualnego urządzenia sieciowego. Odzwierciedla to, że cały ruch między sieciami wirtualnymi i gałęziami jest kierowany do usługi Azure Firewall, NVA lub rozwiązania SaaS w centrum w celu przeprowadzenia inspekcji.

Po sprawdzeniu pakietu przez zaporę (a pakiet zostanie dopuszczony zgodnie z konfiguracją reguły zapory), usługa Virtual WAN przekazuje pakiet do jego ostatecznego miejsca docelowego. Aby sprawdzić, które trasy usługa Virtual WAN używa do przekazywania zbadanych pakietów, wyświetl obowiązującą tabelę tras zapory lub wirtualnego urządzenia sieciowego.

Tabela obowiązujących tras zapory ułatwia zawężenie i izolowanie problemów w sieci, takich jak błędne konfiguracje lub problemy z niektórymi gałęziami i sieciami wirtualnymi.

Rozwiązywanie problemów z konfiguracją

Jeśli rozwiązujesz problemy z konfiguracją, rozważ następujące kwestie:

• Upewnij się, że nie masz niestandardowych tabel tras ani tras statycznych w domyślnej tabeli tras z połączeniem sieci wirtualnej jako następnego przeskoku.
  • Opcja konfigurowania ustawień routingu jest wyszarzona w Azure Portal, jeśli wdrożenie nie spełnia powyższych wymagań.
  • Jeśli używasz interfejsu wiersza polecenia, programu PowerShell lub REST, operacja tworzenia intencji routingu kończy się niepowodzeniem. Usuń nieudaną intencję routingu, usuń niestandardowe tabele tras i trasy statyczne, a następnie spróbuj utworzyć ponownie.
  • Jeśli używasz usługi Azure Firewall Manager, upewnij się, że istniejące trasy w domyślnej tabeliRouteTable mają nazwę private_traffic, internet_traffic lub all_traffic. Opcja konfigurowania intencji trasowania (umożliwiająca połączenia między koncentratorami) jest wyszarzona, jeśli trasy mają różne nazwy.
• Po skonfigurowaniu intencji routingu w centrum upewnij się, że wszelkie aktualizacje istniejących połączeń lub nowe połączenia z centrum są tworzone z opcjonalnymi polami tabeli tras, które są skojarzone i propagowane, pozostawionymi pustymi. Ustawienie opcjonalnych skojarzeń i propagacji jako puste jest wykonywane automatycznie dla wszystkich operacji wykonywanych za pośrednictwem witryny Azure Portal.

Rozwiązywanie problemów ze ścieżką danych

Przy założeniu, że znasz już sekcję Znane ograniczenia , poniżej przedstawiono kilka sposobów rozwiązywania problemów ze ścieżką danych i łącznością:

• Rozwiązywanie problemów z skutecznymi trasami:
  • Jeśli skonfigurowano zasady routingu prywatnego, trasy z zaporą następnego przeskoku powinny być widoczne w obowiązujących trasach domyślnej TabeliRoute dla RFC1918 agregacji (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12), a także wszelkich prefiksów określonych w polu tekstowym ruchu prywatnego. Upewnij się, że wszystkie prefiksy sieci wirtualnej i prefiksy sieci lokalnej są podsieciami w ramach tras statycznych w domyślnej tabeli routingu. Jeśli sieć lokalna lub wirtualna używa przestrzeni adresowej, która nie jest podsiecią w obowiązujących trasach w domyślnej tabeli RouteTable, dodaj prefiks do okna tekstowego ruchu prywatnego.
  • Jeśli skonfigurowano zasady routingu ruchu internetowego, powinna zostać wyświetlona trasa domyślna (0.0.0.0/0) w obowiązujących trasach domyślnej tabeliRouteTable.
  • Po sprawdzeniu, czy obowiązujące trasy domyślnej tabeliRouteTable mają poprawne prefiksy, wyświetl obowiązujące trasy wirtualnego urządzenia sieciowego lub usługi Azure Firewall. Obowiązujące trasy w zaporze pokazują, które trasy usługa Virtual WAN wybrała i określa, do których miejsc docelowych zapora może przekazywać pakiety. Ustalenie, które prefiksy są brakujące lub w nieprawidłowym stanie, pomaga zawęzić problemy ze ścieżką danych i wskazać właściwą sieć VPN, usługę ExpressRoute, urządzenie NVA lub połączenie BGP w celu rozwiązania problemów.
• Rozwiązywanie problemów specyficznych dla scenariusza:
  • Jeśli w swojej Wirtualnej Sieci WAN masz niezabezpieczone centrum (centrum bez usługi Azure Firewall lub NVA - wirtualnego urządzenia sieciowego), upewnij się, że połączenia z niezabezpieczonym centrum są propagowane do domyślnej Tabeli Tras koncentratorów z skonfigurowaną intencją routingu. Jeśli propagacje nie są ustawione na domyślną tabelę tras, połączenia z zabezpieczonym hubem nie będą mogły wysyłać pakietów do niezabezpieczonego huba.
  • Jeśli skonfigurowano zasady routingu internetowego, upewnij się, że ustawienie "Propagacja trasy domyślnej" lub "Włącz zabezpieczenia internetowe" ma wartość "true" dla wszystkich połączeń, które powinny poznać trasę domyślną 0.0.0.0/0. Połączenia, w których to ustawienie ma wartość "false", nie będą uczyć się trasy 0.0.0.0/0, nawet jeśli skonfigurowano zasady routingu internetowego.
  • Jeśli używasz Prywatnych Punktów Końcowych wdrożonych w sieciach wirtualnych połączonych z Wirtualnym Koncentratorem, ruch z sieci lokalnej, przeznaczony dla Prywatnych Punktów Końcowych wdrożonych w sieciach wirtualnych połączonych z koncentratorem usługi Virtual WAN, domyślnie pomija kolejny krok kierowania, taki jak Firewall Azure, NVA lub SaaS. Jednak powoduje to routing asymetryczny (co może prowadzić do utraty łączności między lokalnymi i Prywatnymi Punktami Końcowymi), ponieważ Prywatne Punkty Końcowe w Sieciach Wirtualnych typu Szprycha przekazują ruch lokalny do Zapory. Aby zapewnić symetrię routingu, włącz zasady sieciowe tabeli tras dla prywatnych punktów końcowych w podsieciach, w których wdrożono prywatne punkty końcowe. Skonfigurowanie tras /32 odpowiadających prywatnym adresom IP prywatnego punktu końcowego w polu tekstowym Ruch prywatny nie zapewni symetrii ruchu po skonfigurowaniu zasad routingu prywatnego w centrum.
  • Jeśli używasz zaszyfrowanego ExpressRoute z prywatnymi zasadami routingu, upewnij się, że urządzenie zapory ma skonfigurowaną regułę zezwalającą na ruch między prywatnym punktem końcowym tunelu IP bramy sieci VPN typu site-to-site usługi Virtual WAN a lokalnym urządzeniem sieci VPN. Pakiety ESP (zewnętrzne zaszyfrowane) powinny rejestrować się w dziennikach usługi Azure Firewall. Aby uzyskać więcej informacji na temat szyfrowanej usługi ExpressRoute z intencją routingu, zobacz Zaszyfrowana dokumentacja usługi ExpressRoute.
  • Jeśli używasz tabel tras zdefiniowanych przez użytkownika w sieciach wirtualnych typu spoke, upewnij się, że opcja "Propagacja tras bramy" została ustawiona na "Tak" w tabeli tras. Aby usługa Virtual WAN mogła anonsować trasy do obciążeń wdrożonych w sieciach wirtualnych typu spoke połączonych z usługą Virtual WAN, musi być włączona opcja "Propagacja tras bram". Aby uzyskać więcej informacji na temat ustawień tabeli tras zdefiniowanych przez użytkownika, zobacz dokumentację routingu zdefiniowanego przez użytkownika w sieci wirtualnej.

Rozwiązywanie problemów z routingiem usługi Azure Firewall

• Upewnij się, że stan aprowizacji Azure Firewall jest zakończony pomyślnie przed podjęciem próby skonfigurowania intencji routingu.
• Jeśli używasz prefiksów innych niż IANA RFC1918 w gałęziach/sieciach wirtualnych, upewnij się, że określono te prefiksy w polu tekstowym "Prefiksy prywatne". Skonfigurowane "Prefiksy prywatne" nie są automatycznie propagowane do innych centrów w wirtualnej sieci WAN skonfigurowanej z intencją routingu. Aby zapewnić łączność, dodaj te prefiksy do pola tekstowego "Prefiksy prywatne" w każdym pojedynczym centrum, które ma intencję routingu.
• Jeśli określono adresy inne niż te zgodne z RFC1918 w polu tekstowym Prefiksy ruchu prywatnego w usłudze Firewall Manager, może okazać się konieczne skonfigurowanie zasad SNAT w zaporze w celu wyłączenia SNAT dla ruchu prywatnego z adresami innymi niż RFC1918. Aby uzyskać więcej informacji, zapoznaj się z Zakresami SNAT usługi Azure Firewall.
• Konfigurowanie i wyświetlanie dzienników usługi Azure Firewall w celu ułatwienia rozwiązywania problemów i analizowania ruchu sieciowego. Aby uzyskać więcej informacji na temat konfigurowania monitorowania dla usługi Azure Firewall, zapoznaj się z tematem Diagnostyka usługi Azure Firewall. Aby uzyskać przegląd różnych typów dzienników Azure Firewall, zobacz Dzienniki i metryki usługi Azure Firewall.
• Aby uzyskać więcej informacji na temat usługi Azure Firewall, zapoznaj się z dokumentacją usługi Azure Firewall.

Rozwiązywanie problemów z wirtualnymi urządzeniami sieciowymi

• Przed podjęciem próby skonfigurowania intencji routingu upewnij się, że stan udostępnienia wirtualnego urządzenia sieciowego jest pomyślny.
• Jeśli używasz prefiksów innych niż IANA RFC1918 w połączonych sieciach lokalnych lub wirtualnych, upewnij się, że zostały określone te prefiksy w polu tekstowym "Prefiksy prywatne". Skonfigurowane "Prefiksy prywatne" nie są automatycznie propagowane do innych centrów w wirtualnej sieci WAN skonfigurowanej z intencją routingu. Aby zapewnić łączność, dodaj te prefiksy do pola tekstowego "Prefiksy prywatne" w każdym pojedynczym centrum, które ma intencję routingu.
• Jeśli w polu tekstowym Prefiksy Ruchu Prywatnego określono adresy inne niż RFC1918, może być konieczne skonfigurowanie zasad SNAT na Twoim urządzeniu wirtualnym NVA, aby wyłączyć SNAT dla określonego prywatnego ruchu niezgodnego z RFC1918.
• Sprawdź dzienniki zapory NVA, aby zobaczyć, czy ruch jest odrzucany lub blokowany przez reguły zapory.
• Skontaktuj się z dostawcą NVA, aby uzyskać więcej wsparcia i wskazówek dotyczących rozwiązywania problemów.

Rozwiązywanie problemów z oprogramowaniem jako usługą

• Przed próbą skonfigurowania intencji routingu upewnij się, że stan aprowizacji rozwiązania SaaS zakończył się pomyślnie .
• Aby uzyskać więcej wskazówek dotyczących rozwiązywania problemów, zobacz sekcję dotyczącą rozwiązywania problemów w dokumentacji usługi Virtual WAN lub zapoznaj się z dokumentacją rozwiązania Palo Alto Networks Cloud NGFW.

Następne kroki

Aby uzyskać więcej informacji na temat routingu koncentratora wirtualnego, zobacz About virtual hub routing (Informacje o routingu koncentratora wirtualnego). Aby uzyskać więcej informacji na temat usługi Virtual WAN, zobacz często zadawane pytania.