Jak skonfigurować zasady routingu i intencję 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
Zasady intencji routingu i routingu umożliwiają skonfigurowanie koncentratora usługi Virtual WAN w celu przekazywania ruchu powiązanego z Internetem 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żda usługa Virtual WAN Hub może mieć co najwyżej jedną zasadę routingu ruchu internetowego i jedną zasadę routingu ruchu prywatnego, z których każdy ma jeden 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 usługi Virtual WAN, wszystkie gałęzi (sieć VPN użytkownika zdalnego (vpn typu punkt-lokacja), sieć VPN typu lokacja-lokacja i usługa ExpressRoute) oraz połączenia sieci wirtualnej z tym koncentratorem usługi Virtual WAN przesyłają ruch powiązany z Internetem 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 usługi Virtual WAN, usługa Virtual WAN anonsuje domyślną trasę (0.0.0.0.0/0) do wszystkich szprych, bram i wirtualnych urządzeń sieciowych (wdrożonych w piastze lub szprych).
Zasady routingu ruchu prywatnego: gdy zasady routingu ruchu prywatnego są konfigurowane w koncentratorze usługi Virtual WAN, wszystkie gałęzie i ruch sieci wirtualnej w i poza koncentratorem wirtualnym, w tym ruch między koncentratorami, jest przekazywany do zasobu usługi Azure Firewall następnego przeskoku, wirtualnego urządzenia sieciowego lub rozwiązania SaaS.
Innymi słowy, gdy zasady routingu ruchu prywatnego są konfigurowane w koncentratorze usługi Virtual WAN, wszystkie odgałęzienia do gałęzi, sieć wirtualna-gałąź, ruch międzyoperacyjności i ruch 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 (wdrożone za pomocą usługi Azure Firewall, urządzenia WUS lub rozwiązania SaaS)
W tym scenariuszu wszystkie koncentratory usługi Virtual WAN są wdrażane za pomocą usługi Azure Firewall, urządzenia WUS lub rozwiązania 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:
- Zasady ruchu prywatnego z rozwiązaniem Azure Firewall, NVA lub SaaS w usłudze Next Hop Hub 1
- Zasady ruchu internetowego z rozwiązaniem Azure Firewall, NVA lub SaaS w usłudze Next Hop Hub 1
Konfiguracja koncentratora 2:
- Zasady ruchu prywatnego z rozwiązaniem Azure Firewall, NVA lub SaaS w usłudze Next Hop Hub 2
- Zasady ruchu internetowego z rozwiązaniem Azure Firewall, NVA lub SaaS w usłudze Next Hop Hub 2
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/0) nie jest propagowana między koncentratorami.
| Źródło | Działanie | Sieci wirtualne koncentratora 1 | Gałęzie centrum 1 | Sieci wirtualne koncentratora 2 | Gałęzie centrum 2 | Internet |
|---|---|---|---|---|---|---|
| Sieci wirtualne koncentratora 1 | → | Koncentrator 1 AzFW lub NVA | Koncentrator 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 centrum 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 |
| Sieci wirtualne koncentratora 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 2 AzFW, NVA lub SaaS |
| Gałęzie centrum 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 bezpiecznych 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 koncentratora 1:
- Nie dotyczy (nie można skonfigurować zasad routingu, jeśli centrum nie zostało wdrożone za pomocą usługi Azure Firewall, urządzenia WUS lub rozwiązania SaaS)
Konfiguracja koncentratora 2:
- Zasady ruchu prywatnego z rozwiązaniem Azure Firewall, NVA lub SaaS w usłudze Next Hop Hub 2.
- Zasady ruchu internetowego z rozwiązaniem Azure Firewall, NVA lub SaaS w usłudze Next Hop Hub 2.
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 | Działanie | Sieci wirtualne koncentratora 1 | Gałęzie centrum 1 | Sieci wirtualne koncentratora 2 | Gałęzie centrum 2 | Internet |
|---|---|---|---|---|---|---|
| Sieci wirtualne koncentratora 1 | → | Bezpośredni | Bezpośredni | Hub 2 AzFW, NVA lub SaaS | Hub 2 AzFW, NVA lub SaaS | - |
| Gałęzie centrum 1 | → | Bezpośredni | Bezpośredni | Hub 2 AzFW, NVA lub SaaS | Hub 2 AzFW, NVA lub SaaS | - |
| Sieci wirtualne koncentratora 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 |
| Gałęzie centrum 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 avaiablility intencji routingu w różnych środowiskach platformy Azure.
- Intencja routingu nie jest dostępna w usłudze Mirosoft Azure obsługiwanej przez firmę 21 Vianet.
- Aplikacja Palo Alto Cloud NGFW jest dostępna tylko w publicznej wersji platformy Azure. Skontaktuj się z firmą Palo Alto Networks dotyczącą avaialbility of Cloud NGFW w usługach Azure Government i Microsoft Azure obsługiwanych przez Viacom.
- Wirtualne urządzenia sieciowe nie są dostępne we wszystkich regionach świadczenia usługi Azure Government. Skontaktuj się z partnerem urządzenia WUS w zakresie dostępności w usłudze Azure Government.
| Środowisko chmury | Azure Firewall | Wirtualne urządzenie sieciowe | Rozwiązania SaaS |
|---|---|---|---|
| Publiczna platforma Azure | Tak | Tak | Tak |
| Azure Government | Tak | Ograniczony | Nie. |
| Platforma Microsoft Azure obsługiwana przez 21 Vianet | Nie | Nie. | Nie. |
- Intencja routingu upraszcza routing, zarządzając skojarzeniami tabeli tras i propagacjami dla wszystkich połączeń (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 usługi ExpressRoute) jest obsługiwana w centrach, w których intencja routingu jest skonfigurowana, jeśli usługa Azure Firewall jest skonfigurowana tak, aby zezwalała na ruch między punktami końcowymi tunelu VPN (prywatny adres IP bramy VPN Gateway typu lokacja-lokacja i prywatny adres IP lokalnego urządzenia sieci VPN). Aby uzyskać więcej informacji na temat wymaganych konfiguracji, zobacz Zaszyfrowana usługa ExpressRoute z intencją routingu.
- Następujące przypadki użycia łączności nie są obsługiwane w przypadku intencji routingu:
- 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 komunikacji równorzędnej BGP.
- Trasy statyczne w połączeniu sieci wirtualnej z "propagacją trasy statycznej" nie są stosowane do zasobu następnego przeskoku określonego w zasadach routingu prywatnego. Obsługa stosowania tras statycznych w połączeniach sieci wirtualnej z zasadami routingu prywatnego następnego przeskoku jest w planie.
- Możliwość wdrożenia urządzenia WAN SD-WAN oraz oddzielnego urządzenia WUS zapory lub rozwiązania SaaS w tym samym koncentratorze usługi Virtual WAN znajduje się obecnie na planie. Po skonfigurowaniu intencji routingu przy użyciu rozwiązania SaaS następnego przeskoku lub wirtualnego urządzenia sieciowego zapory łączność między wirtualnym urządzeniem WAN SD-WAN a platformą Azure ma wpływ. 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 WAN SD-WAN w sieci wirtualnej szprychy połączonej z piastą i korzystać z funkcji komunikacji równorzędnej BGP koncentratora wirtualnego.
- Wirtualne urządzenia sieciowe (WUS) można określić tylko jako zasób następnego przeskoku dla intencji routingu, jeśli są zaporą nowej generacji lub podwójną rolą Zapora nowej generacji i urządzenia WAN SD-WAN. Obecnie punkty kontrolne, fortinet-ngfw i fortinet-ngfw-and-sdwan są jedynymi urządzeniami WUS, które mogą być skonfigurowane jako następny przeskok na potrzeby routingu. Jeśli spróbujesz określić inne urządzenie WUS, tworzenie intencji routingu zakończy się niepowodzeniem. Typ urządzenia WUS można sprawdzić, przechodząc do wirtualnego centrum wirtualnego —> wirtualne urządzenia sieciowe, a następnie przeglądając pole Dostawca . Aplikacja Palo Alto Networks Cloud NGFW jest również obsługiwana jako następny przeskok dla intencji routingu, ale jest uważany za następny przeskok typu rozwiązanie SaaS.
- Użytkownicy intencji routingu, którzy chcą połączyć wiele obwodów usługi ExpressRoute z usługą Virtual WAN oraz wysyłać ruch między nimi za pośrednictwem rozwiązania zabezpieczającego wdrożonego w centrum, mogą otworzyć zgłoszenie do pomocy technicznej, aby włączyć 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 przypadek pomoc techniczna 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 usługi Virtual WAN. 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 połączonych bezpośrednio przestrzeni adresowych sieci wirtualnej połączonych z koncentratorem przekroczy limit, włączenie lub zaktualizowanie intencji routingu w koncentratonie wirtualnym zakończy się niepowodzeniem. W przypadku centrów już skonfigurowanych z intencją routingu, w której przestrzenie adresowe sieci wirtualnej przekraczają limit w wyniku operacji, takiej jak aktualizacja przestrzeni adresowej sieci wirtualnej, nowo połączona przestrzeń adresowa może nie być routingowa.
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 na sieć wirtualną | Łączna liczba przestrzeni adresowych sieci wirtualnej połączonych z koncentratorem wirtualnym | Sugerowana akcja |
|---|---|---|---|---|
| Koncentrator nr 1 | 200 | 1 | 200 | Nie jest wymagana żadna akcja, monitoruj liczbę przestrzeni adresowych. |
| Koncentrator 2 | 150 | 3 | 450 | Zwiększenie limitu żądań w celu użycia intencji routingu. |
| Koncentrator 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 usłudze Virtual WAN. Metryka usługi Azure Monitor umożliwiająca śledzenie i konfigurowanie alertów w połączonych przestrzeniach adresowych sieci wirtualnej jest w harmonogramie działania.
Pamiętaj, aby zmodyfikować identyfikator zasobu usługi Virtual WAN Hub w skrypecie, aby był zgodny ze środowiskiem. Jeśli masz połączenia sieci wirtualnej między dzierżawami, upewnij się, że masz wystarczające uprawnienia do odczytu obiektu połączenia sieci wirtualnej usługi Virtual WAN, a także 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 ocurred 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 intencji routingu rozważ 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 tabeliRouteTable z następnym przeskokiem Połączenie z siecią wirtualną następnego przeskoku. Aby uzyskać więcej informacji, zobacz wymagania wstępne.
- Zapisz kopię bram, połączeń i tabel tras przed włączeniem intencji 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 anonsowanie prefiksów do środowiska lokalnego. Aby uzyskać więcej informacji, zobacz anonse prefiksów .
- Możesz otworzyć zgłoszenie do pomocy technicznej, 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 anonsowane do obwodów usługi ExpressRoute. Aby uzyskać więcej informacji, zobacz About ExpressRoute (Informacje o usłudze ExpressRoute ).
- Intencja routingu to jedyny mechanizm w usłudze Virtual WAN umożliwiający inspekcję ruchu między koncentratora za pośrednictwem urządzeń zabezpieczeń wdrożonych w koncentratorze. Inspekcja ruchu między koncentratora wymaga również włączenia intencji routingu we wszystkich centrach w celu zapewnienia symetrycznego kierowania ruchu między urządzeniami zabezpieczeń wdrożonym w koncentratorach usługi Virtual WAN.
- Intencja routingu wysyła sieć wirtualną i ruch lokalny do zasobu następnego przeskoku określonego w zasadach routingu. Usługa Virtual WAN programuje podstawową platformę Azure do kierowania ruchu lokalnego i wirtualnego sieci zgodnie ze skonfigurowanymi zasadami routingu i nie przetwarza ruchu za pośrednictwem routera koncentratora wirtualnego. Ponieważ pakiety kierowane za pośrednictwem intencji routingu nie są przetwarzane przez router, nie trzeba przydzielać dodatkowych jednostek infrastruktury routingu na potrzeby przekazywania pakietów płaszczyzny danych na koncentratorach skonfigurowanych z intencją 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.
- Intencja routingu umożliwia skonfigurowanie różnych zasobów następnego przeskoku dla zasad 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ępnie następnego przeskoku dla zasad routingu internetowego na urządzenie WUS lub rozwiązanie SaaS w centrum. Ponieważ rozwiązania SaaS i wirtualne urządzenia WUS zapory są wdrażane w tej samej podsieci w koncentratorze usługi Virtual WAN, wdrażanie rozwiązań SaaS z urządzeniem WUS zapory w tym samym centrum może mieć wpływ na skalowalność poziomą rozwiązań SaaS, ponieważ istnieje mniej adresów IP dostępnych dla skalowania w poziomie. 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:
- W koncentratonie wirtualnym nie wdrożono niestandardowych tabel tras. Jedyne tabele tras, które istnieją, to noneRouteTable i defaultRouteTable.
- Nie można mieć tras statycznych z połączeniem sieci wirtualnej następnego przeskoku. W domyślnej tabeliRouteTable mogą istnieć trasy statyczne, które mają następny przeskok w usłudze Azure Firewall.
Opcja konfigurowania intencji routingu jest wyszarzony dla centrów, które nie spełniają powyższych wymagań.
Użycie intencji routingu (włącz opcję między koncentratora) w usłudze Azure Firewall Manager wymaga dodatkowego wymagania:
- 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 wycofywania
Uwaga
Gdy konfiguracja intencji routingu zostanie całkowicie usunięta z koncentratora, wszystkie połączenia z koncentratorem są ustawione do propagacji do etykiety domyślnej (która ma zastosowanie do domyślnych tabelrouteTables 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 routing i konfigurację, zarządzając skojarzeniami tras i propagacjami wszystkich połączeń w centrum.
W poniższej tabeli opisano skojarzona tabela tras i propagowane tabele tras wszystkich połączeń po skonfigurowaniu intencji routingu.
| Konfiguracja intencji routingu | Skojarzona tabela tras | Propagowane tabele tras |
|---|---|---|
| Internet | defaultRouteTable | etykieta domyślna (defaultRouteTable wszystkich centrów w usłudze Virtual WAN) |
| Prywatne | defaultRouteTable | noneRouteTable |
| Internet i prywatny | defaultRouteTable | noneRouteTable |
Trasy statyczne w domyślnej tabeliRouteTable
W poniższej sekcji opisano sposób zarządzania trasami statycznymi w domyślnej tabeliRouteTable podczas włączania intencji routingu w centrum. 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 intencji routingu.
Portal usługi Azure Firewall Manager i Virtual WAN Hub
Gdy intencja routingu jest włączona w centrum, trasy statyczne odpowiadające skonfigurowanym zasadom routingu są tworzone automatycznie w domyślnej tabeliRouteTable. Te trasy to:
| Nazwa trasy | Prefiksy | Zasób następnego przeskoku |
|---|---|---|
| _policy_PrivateTraffic | 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 | Azure Firewall |
| _policy_PublicTraffic | 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 tabeliRouteTable zgodne z RFC1918 supersieci lub 0.0.0.0/0 są zawsze automatycznie usuwane po skonfigurowaniu intencji routingu, niezależnie od typu zasad.
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 |
|---|---|---|
| private_traffic | 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 |
| additional_private | 10.0.0.0/8, 50.0.0.0/24 | Azure Firewall |
Włączenie intencji routingu w tym centrum spowodowałoby następujący stan końcowy domyślnej tabeliRouteTable. 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 |
|---|---|---|
| _policy_PrivateTraffic | 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 | Azure Firewall |
| _policy_PublicTraffic | 0.0.0.0/0 | Azure Firewall |
| private_traffic | 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 zasad w domyślnej tabeliRouteTable, a także usuwa wszelkie prefiksy w trasach statycznych, które są dokładnie zgodne z 0.0.0.0/0 lub RFC1918 supersieci (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 |
|---|---|---|
| _policy_PrivateTraffic | 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 | Azure Firewall |
| _policy_PublicTraffic | 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 |
Anonsowanie prefiksu do środowiska lokalnego
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 anonsowana w koncentratorach wirtualnych.
Jeśli włączysz zasady routingu internetowego w koncentratonie 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 WUS w połączeniach centrum i protokołu BGP), gdzie flaga Propaguj trasę domyślną lub Włącz flagę zabezpieczeń internetu ma wartość true. Tę flagę można ustawić na wartość false dla wszystkich połączeń, które nie powinny uczyć się trasy domyślnej.
Zasady routingu prywatnego
Po skonfigurowaniu koncentratora wirtualnego z zasadami routingu prywatnego usługa Virtual WAN anonsuje trasy do lokalnych połączeń lokalnych w następujący sposób:
- Trasy odpowiadające prefiksom uzyskanym z sieci wirtualnych koncentratora lokalnego, usługi ExpressRoute, sieci VPN typu lokacja-lokacja, sieci VPN typu punkt-lokacja, połączenia NVA-in-the-hub lub BGP połączone z bieżącym koncentratorem.
- Trasy odpowiadające prefiksom poznanym na podstawie zdalnych sieci wirtualnych koncentratora, usługi ExpressRoute, sieci VPN typu lokacja-lokacja, sieci VPN typu punkt-lokacja, połączeń NVA-in-the-hub lub 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-lokacja, połączeń NVA-in-the-hub i BGP, w których intencja routingu nie jest skonfigurowana , a połączenia zdalne są propagowane do domyślnej tabeliRouteTable centrum lokalnego.
- Prefiksy poznane na podstawie jednego obwodu usługi ExpressRoute nie są anonsowane do innych obwodów usługi ExpressRoute, chyba że włączono usługę Global Reach. Jeśli chcesz włączyć tranzyt usługi ExpressRoute do usługi ExpressRoute za pośrednictwem rozwiązania zabezpieczeń wdrożonego w centrum, otwórz zgłoszenie do pomocy technicznej. Aby uzyskać więcej informacji, zobacz Włączanie łączności między obwodami usługi ExpressRoute.
Scenariusze routingu kluczy
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ą usługi ExpressRoute z usługą ExpressRoute za pośrednictwem urządzenia zapory w centrum z zasadami routingu prywatnego, otwórz zgłoszenie do pomocy technicznej z pomoc techniczna firmy Microsoft. 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 obsługą usługi Global Reach wysyłanie ruchu między sobą bezpośrednio bez przesyłania koncentratora wirtualnego.
- Zasady routingu prywatnego intencji: konfigurowanie zasad routingu prywatnego umożliwia dwóm obwodom usługi ExpressRoute wysyłanie ruchu do siebie za pośrednictwem rozwiązania zabezpieczeń wdrożonego w centrum.
Łączność między obwodami usługi ExpressRoute za pośrednictwem urządzenia zapory w centrum z zasadami routingu prywatnego intencji routingu jest dostępna w następujących konfiguracjach:
- Oba obwody usługi ExpressRoute są połączone z tym samym koncentratorem, a w tym centrum skonfigurowano zasady routingu prywatnego.
- Obwody usługi ExpressRoute są połączone z różnymi koncentratorami, a zasady routingu prywatnego są konfigurowane w obu centrach. 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 zagadnienia dotyczące routingu dotyczą wszystkich koncentratorów wirtualnych w subskrypcjach, które są włączone przez pomoc techniczna firmy Microsoft, aby umożliwić usłudze ExpressRoute łączność z usługą ExpressRoute za pośrednictwem urządzenia zabezpieczeń w centrum.
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 anonsuje prefiksy agregujące RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) do sieci lokalnej połączonej 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 domyślnej tabeliRouteTable do obwodu usługi ExpressRoute połączonego lokalnie. Oznacza to, że usługa Virtual WAN anonsuje trasy określone w polu tekstowym prefiksu ruchu prywatnego do środowiska lokalnego.
Ze względu na te zmiany anonsowania tras oznacza to, że usługa ExpressRoute połączona lokalnie nie może anonsować dokładnych zakresów adresów dla RFC1918 zagregowanych zakresów adresów (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Upewnij się, że reklamujesz bardziej szczegółowe podsieci (w RFC1918 zakresach), a nie agregowane super-nets i 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 jest reklamą 40.0.0.0/24 ze środowiska lokalnego, umieść zakres CIDR /23 lub większy w polu tekstowym Prefiks ruchu prywatnego (na przykład: 40.0.0.0/23).
Kierowanie anonsów do innych lokalnych (sieć VPN typu lokacja-lokacja, sieć VPN typu punkt-lokacja, urządzenie WUS) nie ma wpływu na włączenie usługi ExpressRoute do łączności tranzytowej usługi ExpressRoute za pośrednictwem urządzenia zabezpieczeń wdrożonego w centrum.
Zaszyfrowana usługa ExpressRoute
Aby użyć szyfrowanego połączenia ExpressRoute (tunel vpn typu lokacja-lokacja uruchomiona za pośrednictwem obwodu usługi ExpressRoute) z zasadami routingu prywatnego intencji, skonfiguruj regułę zapory, aby zezwolić na ruch między prywatnymi adresami IP tunelu bramy vpn gateway typu lokacja-lokacja sieci WAN (źródło) i lokalnym urządzeniem sieci VPN (miejscem docelowym). W przypadku klientów korzystających z inspekcji głębokiego pakietu na urządzeniu Zapora zaleca się wykluczenie ruchu między tymi prywatnymi adresami IP z inspekcji pakietów głębokich.
Prywatne adresy IP tunelu bramy vpn typu lokacja-lokacja usługi 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óra jest używana do kończenie tuneli SIECI VPN za pośrednictwem usługi ExpressRoute. W poniższym przykładzie adresy IP tunelu w 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 używane przez urządzenia lokalne do kończenia żądań sieci VPN to adresy IP określone w ramach połączenia połączenia lokacji sieci VPN.
Korzystając z przykładowej konfiguracji sieci VPN i lokacji sieci VPN z powyższej strony, 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 zasad routingu prywatnego za pomocą szyfrowanej usługi ExpressRoute kieruje pakiety VPN ESP za pośrednictwem urządzenia zabezpieczeń następnego przeskoku wdrożonego w centrum. 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 głębokiego pakietu, zapoznaj się z dokumentacją listy pomijania dostawcy tożsamości.
- 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ń urządzenia WUS na potrzeby łączności z podwójną rolą i wirtualnych urządzeń sieciowych zapory
Uwaga
Routing bezpośredni do urządzenia WUS z podwójną rolą używany z zasadami routingu prywatnego w usłudze Virtual WAN dotyczy tylko ruchu między sieciami wirtualnymi i trasami nauczonym za pośrednictwem protokołu BGP z urządzenia WAN wdrożonego w koncentratorze usługi Virtual WAN. Łączność tranzytowa usługi ExpressRoute i sieci VPN z połączonym urządzeniem WUS nie jest kierowana bezpośrednio do wystąpień urządzenia WUS i jest zamiast tego kierowana za pośrednictwem modułu równoważenia obciążenia urządzenia WUS z podwójną rolą.
Niektóre wirtualne urządzenia sieciowe mogą mieć możliwości łączności (SD-WAN) i zabezpieczeń (NGFW) na tym samym urządzeniu. Te urządzenia WUS są uważane za urządzenia WUS z podwójną rolą. Sprawdź, czy urządzenie WUS jest urządzeniem WUS z podwójną rolą w ramach partnerów urządzenia WUS.
Gdy zasady routingu prywatnego są skonfigurowane dla urządzeń WA z podwójną rolą, usługa Virtual WAN automatycznie anonsuje trasy dowiedziały się z urządzenia WA koncentratora usługi Virtual WAN bezpośrednio połączonych (lokalnych) sieci wirtualnych, a także do innych koncentratorów wirtualnych w wirtualnej sieci WAN z następnym przeskokiem jako wystąpienia urządzenia WUS, w przeciwieństwie do wewnętrznego modułu równoważenia obciążenia urządzeń WUS.
W przypadku konfiguracji aktywnego pasywnego urządzenia WUS, w których tylko jedno wystąpienie urządzenia WUS anonsuje trasę dla określonego prefiksu usługi Virtual WAN (lub długość ścieżki AS-PATH tras wyciągniętych z jednego z wystąpień jest zawsze najkrótsza), usługa Virtual WAN zapewnia, że ruch wychodzący z sieci wirtualnej platformy Azure jest zawsze kierowany do aktywnego (lub preferowanego) wystąpienia urządzenia WUS.
W przypadku konfiguracji aktywnego aktywnego urządzenia WUS (wiele wystąpień urządzenia WUS 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 sieciowa zdefiniowana programowo na platformie Azure nie gwarantuje symetrii na poziomie przepływu, co oznacza, że przepływ przychodzący do platformy Azure i przepływ wychodzący z platformy Azure może wylądować na różnych wystąpieniach urządzenia WUS. 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 urządzenie WUS działa jako urządzenie WUS o podwójnej roli, chyba że urządzenie WUS może obsługiwać przekazywanie asymetryczne lub obsługiwać 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 usługi Azure Firewall Manager umożliwia konfigurowanie zasad routingu przy użyciu zasobu następnego przeskoku usługi Azure Firewall. Portal usługi Virtual WAN umożliwia konfigurowanie zasad routingu przy użyciu zasobu następnego przeskoku usługi Azure Firewall, wirtualnych urządzeń sieciowych wdrożonych w ramach rozwiązań Virtual Hub lub SaaS.
Klienci korzystający z usługi Azure Firewall w bezpiecznym koncentratorze Virtual WAN mogą aktywować ustawienie „Włącz między koncentratorami" usługi Azure Firewall Manager na wartość „Włączone", aby użyć intencji routingu, lub użyć portalu usługi Virtual WAN, aby bezpośrednio skonfigurować usługę Azure Firewall jako zasób następnego przeskoku dla intencji i zasad routingu. 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.
Przejdź do koncentratora usługi Virtual WAN, w którym chcesz skonfigurować zasady routingu.
W obszarze Zabezpieczenia wybierz pozycję Zabezpieczone ustawienia koncentratora wirtualnego, a następnie pozycję Zarządzaj ustawieniami dostawcy zabezpieczeń i tras dla tego zabezpieczonego koncentratora wirtualnego w usłudze Azure Firewall Manager.
Wybierz koncentrator, w którym chcesz skonfigurować zasady routingu w menu.
Wybierz pozycję Konfiguracja zabezpieczeń w obszarze Ustawienia
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
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 pozycję Pomiń usługę Azure Firewall.
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.
Wybierz pozycję Inter-hub(Inter-hub), aby włączyć. Włączenie tej opcji gwarantuje, że zasady routingu są stosowane do intencji routingu tego koncentratora usługi Virtual WAN.
Wybierz pozycję Zapisz.
Powtórz kroki 2–8 dla innych zabezpieczonych koncentratorów usługi Virtual WAN, dla których chcesz skonfigurować zasady routingu.
Na tym etapie możesz wysłać testowy ruch. 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.
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.
W obszarze Routing wybierz pozycję Zasady routingu.
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 zasób następnego przeskoku.
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 dodano ten sam prefiks do pola tekstowego prefiksu ruchu prywatnego we wszystkich koncentratorach wirtualnych skonfigurowanych przy użyciu zasad routingu prywatnego. Pozwoli to zapewnić anonsowanie do wszystkich koncentratorów prawidłowych tras.
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 zasób następnego przeskoku.
Aby zastosować konfigurację intencji routingu i zasad routingu, kliknij przycisk Zapisz.
Powtórz dla wszystkich koncentratorów, dla których chcesz skonfigurować zasady routingu.
Na tym etapie możesz wysłać testowy ruch. 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 szablonu BICEP
Zobacz szablon BICEP, aby uzyskać informacje o szablonie i krokach.
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 obowiązujących tras stosowanych w zasobach następnego przeskoku intencji routingu usługi Virtual WAN jest obsługiwane tylko dla zasobu następnego przeskoku określonego w zasadach routingu prywatnego. Jeśli używasz zasad routingu prywatnego i internetowego, sprawdź obowiązujące trasy dla zasobu następnego przeskoku określonego w zasadach routingu prywatnego dla obowiązujących tras programy usługi Virtual WAN w zasobie następnego przeskoku zasad routingu internetowego. Jeśli używasz tylko zasad routingu internetowego, sprawdź obowiązujące trasy w domyślnej tabeliRouteTable, aby wyświetlić trasy programowane 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 obowiązujące trasy tabeli defaultRouteTable pokazują RFC1918 zagregowanych prefiksów (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) z następnym przeskokiem usługi Azure Firewall lub wirtualne urządzenie sieciowe. Odzwierciedla to, że cały ruch między sieciami wirtualnymi i gałęziami jest kierowany do usługi Azure Firewall, urządzenia WUS lub rozwiązania SaaS w centrum na potrzeby inspekcji.
Po sprawdzeniu przez zaporę pakietu (a pakiet jest dozwolony zgodnie z konfiguracją reguły zapory), usługa Virtual WAN przekazuje pakiet do jego końcowego 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 tabeliRouteTable z połączeniem sieci wirtualnej następnego przeskoku.
- Opcja konfigurowania intencji routingu jest wyszarzony w witrynie 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 zakończy się niepowodzeniem. Usuń intencję routingu, usuń niestandardowe tabele tras i trasy statyczne, a następnie spróbuj ponownie utworzyć.
- 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 routingu (włącz między koncentratorami) jest wyszarzony, jeśli trasy są nazwane inaczej.
- Po skonfigurowaniu intencji routingu w centrum upewnij się, że wszystkie aktualizacje istniejących połączeń lub nowych połączeń z koncentratorem są tworzone z opcjonalnymi polami tabeli tras skojarzonymi i propagowanymi ustawionymi na puste. 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 obowiązującymi 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 lokalne są podsieciami w ramach tras statycznych w domyślnej tabeliRouteTable. Jeśli sieć lokalna lub wirtualna używa przestrzeni adresowej, która nie jest podsiecią w obowiązujących trasach w domyślnej tabeliRouteTable, dodaj prefiks do pola 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 WUS lub połączenie BGP w celu rozwiązania problemów.
- Rozwiązywanie problemów specyficznych dla scenariusza:
- Jeśli w wirtualnej sieci WAN masz niebezpieczone centrum (centrum bez usługi Azure Firewall lub urządzenia WUS), upewnij się, że połączenia z niezabezpieczonym koncentratorem są propagowane do domyślnej tabeliRouteTable koncentratorów ze skonfigurowaną intencją routingu. Jeśli propagacje nie są ustawione na domyślną tabelęRouteTable, połączenia z zabezpieczonym koncentratorem nie będą mogły wysyłać pakietów do niezabezpieczonego centrum.
- 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 koncentratorem wirtualnym, ruch z lokalnego przeznaczony dla prywatnych punktów końcowych wdrożonych w sieciach wirtualnych połączonych z koncentratorem usługi Virtual WAN domyślnie pomija intencję routingu następnego przeskoku Usługi Azure Firewall, URZĄDZENIA WUS lub SaaS. Jednak powoduje to routing asymetryczny (co może prowadzić do utraty łączności między lokalnymi i prywatnymi punktami końcowymi) jako prywatnych punktów końcowych w sieciach wirtualnych szprych do przekazywania ruchu lokalnego 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 /32 tras odpowiadających prywatnym adresom IP punktu końcowego w polu tekstowym Ruch prywatny nie zapewni symetrii ruchu po skonfigurowaniu zasad routingu prywatnego w centrum.
- Jeśli używasz szyfrowanej usługi ExpressRoute z zasadami routingu prywatnego, upewnij się, że urządzenie zapory ma skonfigurowaną regułę zezwalającą na ruch między prywatnym punktem końcowym prywatnego tunelu IP bramy sieci VPN usługi Virtual WAN typu lokacja-lokacja i lokalnym urządzeniem sieci VPN. Pakiety ESP (zaszyfrowane zewnętrzne) powinny logować 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.
Rozwiązywanie problemów z routingiem usługi Azure Firewall
- Przed podjęciem próby skonfigurowania intencji routingu upewnij się, że stan aprowizacji usługi Azure Firewall zakończył się pomyślnie .
- 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ą propagowane automatycznie 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ż RFC1918 w polu tekstowym Prefiksy ruchu prywatnego w usłudze Firewall Manager, może być konieczne skonfigurowanie zasad SNAT w zaporze w celu wyłączenia protokołu SNAT dla ruchu prywatnego bez RFC1918. Aby uzyskać więcej informacji, zapoznaj się z tematem Zakresy 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 zapoznać się z omówieniem różnych typów dzienników zapory, 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 aprowizacji wirtualnego urządzenia sieciowego zakończył się pomyślnie .
- 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ą propagowane automatycznie 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 w urządzeniu WUS w celu wyłączenia protokołu SNAT dla określonego ruchu prywatnego bez RFC1918.
- Sprawdź dzienniki zapory urządzenia WUS, aby sprawdzić, czy ruch jest porzucony lub blokowany przez reguły zapory.
- Skontaktuj się z dostawcą urządzenia WUS, aby uzyskać więcej pomocy technicznej 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.