Korzystanie z projektu rozwiązania Azure VMware Solution z dwoma regionami, który nie ma zasięgu globalnego
W tym artykule opisano najlepsze rozwiązania dotyczące łączności, przepływów ruchu i wysokiej dostępności podczas wdrażania rozwiązania Azure VMware Solution w dwóch regionach i używania bezpiecznej usługi Azure Virtual WAN z intencją routingu. Zawiera wskazówki dotyczące korzystania z tego projektu bez globalnego zasięgu. W tym artykule opisano usługę Virtual WAN z topologią intencji routingu dla chmur prywatnych usługi Azure VMware Solution, lokacji lokalnych i zasobów natywnych dla platformy Azure. Implementacja i konfiguracja bezpiecznej usługi Virtual WAN z intencją routingu wykraczają poza zakres tego artykułu.
Jeśli używasz regionu, który nie obsługuje usługi Global Reach lub jeśli masz wymóg zabezpieczeń inspekcji ruchu między usługą Azure VMware Solution i lokalnie w zaporze koncentratora, musisz otworzyć bilet pomocy technicznej, aby włączyć tranzyt usługi ExpressRoute-to-ExpressRoute. Usługa Virtual WAN domyślnie nie obsługuje przechodniości usługi ExpressRoute-to-ExpressRoute. Aby uzyskać więcej informacji, zobacz Tranzyt łączności między obwodami usługi ExpressRoute z intencją routingu.
Korzystanie z bezpiecznej wirtualnej sieci WAN w dwóch regionach bez usługi Global Reach
Tylko jednostka SKU usługi Virtual WAN w warstwie Standardowa obsługuje bezpieczną usługę Virtual WAN z intencją routingu. Użyj bezpiecznej wirtualnej sieci WAN z intencją routingu, aby wysyłać cały ruch internetowy i ruch sieciowy prywatny (RFC 1918) do rozwiązania zabezpieczeń, takiego jak usługa Azure Firewall, wirtualne urządzenie sieciowe innej firmy niż Microsoft lub rozwiązanie oprogramowania jako usługi (SaaS).
Centrum tego scenariusza ma następującą konfigurację:
Sieć z dwoma regionami ma jedno wystąpienie usługi Virtual WAN i dwa koncentratory. Każdy region ma jedno centrum.
Każde centrum ma wdrożone własne wystąpienie usługi Azure Firewall, co czyni je bezpiecznymi koncentratorami usługi Virtual WAN.
Bezpieczne koncentratory usługi Virtual WAN mają włączoną intencję routingu.
Ten scenariusz ma również następujące składniki:
Każdy region ma własną chmurę prywatną rozwiązania Azure VMware Solution i sieć wirtualną platformy Azure.
Lokacja lokalna łączy się z obydwoma regionami.
Uwaga
Jeśli używasz prefiksów innych niż RFC 1918 w połączonych zasobach lokalnych, sieciach wirtualnych lub rozwiązaniu Azure VMware Solution, określ te prefiksy w polu Prefiksy ruchu prywatnego funkcji intencji routingu. Wprowadź podsumowane trasy w polu Prefiksy ruchu prywatnego, aby pokryć zakres. Nie wprowadzaj dokładnego zakresu anonsowania do usługi Virtual WAN, ponieważ ta specyfikacja może prowadzić do problemów z routingiem. Jeśli na przykład obwód usługi Azure ExpressRoute anonsuje zakres 192.0.2.0/24 ze środowiska lokalnego, wprowadź zakres /23 Classless Inter-Domain Routing (CIDR) lub większy, na przykład 192.0.2.0/23. Aby uzyskać więcej informacji, zobacz Konfigurowanie intencji routingu i zasad za pośrednictwem portalu usługi Virtual WAN.
Uwaga
Podczas konfigurowania rozwiązania Azure VMware Solution z bezpiecznymi koncentratorami usługi Virtual WAN ustaw opcję preferencji routingu koncentratora na ścieżkę AS, aby zapewnić optymalne wyniki routingu w centrum. Aby uzyskać więcej informacji, zobacz Preferencje routingu koncentratora wirtualnego.
Na poniższym diagramie przedstawiono przykład tego scenariusza.
W poniższej tabeli opisano łączność topologii na powyższym diagramie.
Connection | opis |
---|---|
D | Połączenie chmury prywatnej usługi Azure VMware Solution z lokalnym koncentratorem regionalnym |
E | Łączność lokalna za pośrednictwem usługi ExpressRoute z obydwoma centrami regionalnymi |
Interhub | Połączenie logiczne między usługami Interhub między dwoma koncentratorami wdrożonym w ramach tej samej usługi Virtual WAN |
Bezpieczne przepływy ruchu usługi Virtual WAN w dwóch regionach
W poniższych sekcjach opisano przepływy ruchu i łączność dla usługi Azure VMware Solution, lokalnych, sieci wirtualnych platformy Azure i Internetu.
Łączność i przepływy ruchu w chmurze prywatnej usługi Azure VMware Solution
Na poniższym diagramie przedstawiono przepływy ruchu dla obu chmur prywatnych usługi Azure VMware Solution.
W poniższej tabeli opisano łączność topologii na powyższym diagramie.
Numer przepływu ruchu | Element źródłowy | Element docelowy | Czy bezpieczna zapora koncentratora usługi Virtual WAN sprawdza ten ruch? |
---|---|---|---|
1 | Region chmury usługi Azure VMware Solution 1 | Sieć wirtualna 1 | Tak, za pośrednictwem zapory koncentratora 1 |
2 | Region chmury usługi Azure VMware Solution 1 | Lokalne | Tak, za pośrednictwem zapory koncentratora 1 |
3 | Region chmury usługi Azure VMware Solution 1 | Sieć wirtualna 2 | Tak, za pośrednictwem zapory koncentratora 1, a następnie za pośrednictwem zapory koncentratora 2 |
100 | Region chmury usługi Azure VMware Solution 1 | Region chmury usługi Azure VMware Solution 2 | Tak, za pośrednictwem zapory koncentratora 1, a następnie za pośrednictwem zapory koncentratora 2 |
5 | Region chmury usługi Azure VMware Solution 2 | Sieć wirtualna 1 | Tak, za pośrednictwem zapory koncentratora 2, a następnie za pośrednictwem zapory koncentratora 1 |
6 | Region chmury usługi Azure VMware Solution 2 | Sieć wirtualna 2 | Tak, za pośrednictwem zapory koncentratora 2 |
7 | Region chmury usługi Azure VMware Solution 2 | Lokalne | Tak, za pośrednictwem zapory koncentratora 2 |
Każda chmura prywatna usługi Azure VMware Solution łączy się z koncentratorem za pośrednictwem połączenia usługi ExpressRoute D.
Po włączeniu przechodniości usługi ExpressRoute-to-ExpressRoute w bezpiecznym centrum i włączeniu intencji routingu, bezpieczne centrum wysyła domyślne adresy RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) do usługi Azure VMware Solution za pośrednictwem połączenia D. Oprócz domyślnych adresów RFC 1918 rozwiązanie Azure VMware Solution uczy się bardziej szczegółowych tras z sieci wirtualnych i sieci oddziałów platformy Azure, takich jak S2S VPN, P2S VPN i SD-WAN, które łączą się z obydwoma koncentratorami. Obie chmury prywatne usługi Azure VMware Solution nie uczą się określonych tras z sieci lokalnych.
Aby kierować ruch z powrotem do sieci lokalnych, rozwiązanie Azure VMware Solution używa domyślnych adresów RFC 1918, które uczy się za pośrednictwem połączenia D z lokalnego centrum regionalnego. Ten ruch jest przesyłany przez lokalną zaporę centrum regionalnego. Zapora piasty używa określonych tras dla sieci lokalnych do kierowania ruchu do miejsc docelowych za pośrednictwem połączenia E. Ruch, który przechodzi z chmury prywatnej usługi Azure VMware Solution do sieci wirtualnych, przechodzi przez zaporę koncentratora.
Łączność lokalna i przepływ ruchu
Na poniższym diagramie przedstawiono przepływy ruchu dla łączności lokalnej.
W poniższej tabeli opisano łączność topologii na powyższym diagramie.
Numer przepływu ruchu | Element źródłowy | Element docelowy | Czy bezpieczna zapora koncentratora usługi Virtual WAN sprawdza ten ruch? |
---|---|---|---|
2 | Lokalne | Region chmury usługi Azure VMware Solution 1 | Tak, za pośrednictwem zapory koncentratora 1 |
7 | Lokalne | Region chmury usługi Azure VMware Solution 2 | Tak, za pośrednictwem zapory koncentratora 2 |
8 | Lokalne | Sieć wirtualna 1 | Tak, za pośrednictwem zapory koncentratora 1 |
9 | Lokalne | Sieć wirtualna 2 | Tak, za pośrednictwem zapory koncentratora 2 |
Lokacja lokalna łączy się z obydwoma koncentratorami za pośrednictwem połączenia usługi ExpressRoute E.
Po włączeniu przechodniości usługi ExpressRoute-to-ExpressRoute w obu bezpiecznych centrach i włączeniu intencji routingu każde bezpieczne centrum wysyła domyślne adresy RFC 1918 (10.0.0.0/8, 172.16.0.0.0/12 i 192.168.0.0/16) do środowiska lokalnego za pośrednictwem połączenia E. Oprócz domyślnych adresów RFC 1918 lokalnie poznaje bardziej szczegółowe trasy z sieci wirtualnych i sieci oddziałów platformy Azure, takich jak sieć VPN typu lokacja-lokacja, sieć VPN typu punkt-lokacja i sieć SD-WAN, które łączą się z obydwoma koncentratorami.
Środowisko lokalne nie uczy się określonych tras dla chmur prywatnych usługi Azure VMware Solution. Lokalnie poznaje domyślne adresy RFC 1918 z obu centrów za pośrednictwem połączenia E. Trasy lokalne do obu chmur prywatnych usługi Azure VMware Solution za pośrednictwem domyślnych adresów RFC 1918, które uczy się za pośrednictwem połączenia E.
Uwaga
Należy dodać określone trasy w obu centrach. Jeśli nie dodasz określonych tras na koncentratorach, możesz wprowadzić nieoptymalny routing, ponieważ lokalnie używa routingu wielościeżkowego (ECMP) o równym koszcie między połączeniami E dla ruchu, który przechodzi do chmury prywatnej usługi Azure VMware Solution. W związku z tym ruch między środowiskiem lokalnym a chmurą prywatną usługi Azure VMware Solution może powodować opóźnienia, problemy z wydajnością lub spadek pakietów.
Aby anonsować bardziej szczegółową trasę do środowiska lokalnego, określ te prefiksy w polu Prefiksy ruchu prywatnego funkcji intencji routingu. Aby uzyskać więcej informacji, zobacz Konfigurowanie intencji routingu i zasad za pośrednictwem portalu usługi Virtual WAN. Musisz dodać podsumowaną trasę obejmującą zarówno blok rozwiązania Azure VMware Solution /22, jak i podsieci rozwiązania Azure VMware Solution. Jeśli dodasz ten sam dokładny prefiks lub bardziej konkretny prefiks zamiast trasy podsumowania, w środowisku platformy Azure wprowadzisz problemy z routingiem. Uwzględnij tylko podsumowane trasy w polu Prefiksy ruchu prywatnego.
Jak pokazano na diagramie, chmura prywatna usługi Azure VMware Solution 1 obejmuje podsieci obciążeń z zakresu od 10.10.0.0/24 do 10.10.7.0/24. W centrum 1 trasa podsumowania 10.10.0.0/21 jest dodawana do prefiksów ruchu prywatnego, ponieważ obejmuje wszystkie osiem podsieci. Ponadto w centrum 1 trasa podsumowania 10.150.0.0/22 jest dodawana do prefiksów ruchu prywatnego w celu pokrycia bloku zarządzania usługą Azure VMware Solution. Trasy podsumowania 10.10.0.0/21 i 10.150.0.0/22 są anonsowane do środowiska lokalnego za pośrednictwem połączenia E , tak aby lokalnie miał bardziej szczegółową trasę, a nie 10.0.0.0/8.
Chmura prywatna usługi Azure VMware Solution 2 obejmuje podsieci obciążeń z wersji 10.20.0.0/24 do 10.20.7.0/24. W centrum 2 trasa podsumowania 10.20.0.0/21 jest dodawana do prefiksów ruchu prywatnego, ponieważ obejmuje wszystkie osiem podsieci. Ponadto w centrum 2 trasa podsumowania 10.250.0.0/22 jest dodawana do prefiksów ruchu prywatnego w celu pokrycia bloku zarządzania usługą Azure VMware Solution. Trasy podsumowania 10.20.0.0/21 i 10.250.0.0/22 anonsują się do środowiska lokalnego za pośrednictwem połączenia E , aby lokalnie miał bardziej szczegółową trasę, a nie 10.0.0.0/8.
Cały blok zarządzania usługą Azure VMware Solution /22 można dodać w polu Prefiksy ruchu prywatnego, ponieważ rozwiązanie Azure VMware Solution nie anonsuje dokładnego bloku /22 do platformy Azure. Usługa Azure VMware Solution anonsuje bardziej szczegółowe trasy.
Po włączeniu przechodniości usługi ExpressRoute-to-ExpressRoute w centrum wysyła domyślne adresy RFC 1918 do sieci lokalnej. Nie ogłaszaj dokładnych prefiksów RFC 1918 z powrotem na platformę Azure. Te same dokładne trasy mogą tworzyć problemy z routingiem na platformie Azure. Zamiast tego należy anonsować bardziej szczegółowe trasy z powrotem na platformę Azure dla sieci lokalnych.
Uwaga
Jeśli anonsujesz domyślne adresy RFC 1918 ze środowiska lokalnego na platformę Azure i chcesz kontynuować tę praktykę, musisz podzielić każdy zakres RFC 1918 na dwa równe podrangi i anonsować te podranges z powrotem na platformę Azure. Podranges to 10.0.0.0/9, 10.128.0.0/9, 172.16.0.0/13, 172.24.0.0/13, 192.168.0.0/17 i 192.168.128.0/17.
Łączność sieci wirtualnej platformy Azure i przepływ ruchu
Na poniższym diagramie przedstawiono przepływy ruchu dla sieci wirtualnych platformy Azure.
W poniższej tabeli opisano przepływ ruchu na powyższym diagramie.
Numer przepływu ruchu | Element źródłowy | Element docelowy | Czy bezpieczna zapora koncentratora usługi Virtual WAN sprawdza ten ruch? |
---|---|---|---|
1 | Sieć wirtualna 1 | Region chmury usługi Azure VMware Solution 1 | Tak, za pośrednictwem zapory koncentratora 1 |
3 | Sieć wirtualna 2 | Region chmury usługi Azure VMware Solution 1 | Tak, za pośrednictwem zapory koncentratora 2, a następnie zapory koncentratora 1 |
5 | Sieć wirtualna 1 | Region chmury usługi Azure VMware Solution 2 | Tak, za pośrednictwem zapory koncentratora 1, a następnie zapory koncentratora 2 |
6 | Sieć wirtualna 2 | Region chmury usługi Azure VMware Solution 2 | Tak, za pośrednictwem zapory koncentratora 2 |
8 | Sieć wirtualna 1 | Lokalne | Tak, za pośrednictwem zapory koncentratora 1 |
9 | Sieć wirtualna 2 | Lokalne | Tak, za pośrednictwem zapory koncentratora 2 |
10 | Sieć wirtualna 1 | Sieć wirtualna 2 | Tak, za pośrednictwem zapory koncentratora 1, a następnie zapory koncentratora 2 |
10 | Sieć wirtualna 2 | Sieć wirtualna 1 | Tak, za pośrednictwem zapory koncentratora 2, a następnie zapory koncentratora 1 |
Każda sieć wirtualna jest bezpośrednio równorzędna do jej regionalnego centrum.
Na diagramie pokazano, jak wszystkie zasoby natywne dla platformy Azure w obu sieciach wirtualnych uczą się efektywnych tras. Po włączeniu intencji routingu koncentrator 1 i koncentrator 2 wysyła domyślne adresy RFC 1918 do równorzędnych sieci wirtualnych. Zasoby natywne dla platformy Azure w sieciach wirtualnych nie uczą się określonych tras spoza sieci wirtualnej.
Po włączeniu intencji routingu wszystkie zasoby w sieci wirtualnej uczą się domyślnego adresu RFC 1918 i używają ich regionalnej zapory koncentratora jako następnego przeskoku. Chmury prywatne usługi Azure VMware Solution komunikują się ze sobą za pośrednictwem połączenia D za pośrednictwem lokalnej zapory koncentratora regionalnego. Stamtąd przechodzą przez interhub usługi Virtual WAN i przechodzą inspekcję w zaporze koncentratora między regionami. Chmury prywatne usługi Azure VMware Solution komunikują się również ze środowiskiem lokalnym za pośrednictwem połączenia D za pośrednictwem lokalnej zapory centrum regionalnego. Cały ruch, który wchodzi do sieci wirtualnych i wychodzi z niego, przejeżdża za zapory koncentratora regionalnego.
Łączność z Internetem
W tej sekcji opisano sposób zapewniania łączności z Internetem dla zasobów natywnych dla platformy Azure w sieciach wirtualnych i chmurach prywatnych usługi Azure VMware Solution w obu regionach. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące projektowania łączności internetowej. Poniższe opcje umożliwiają zapewnienie łączności z Internetem z usługą Azure VMware Solution.
- Opcja 1. Usługa internetowa hostowana na platformie Azure
- Opcja 2. Translacja adresów sieciowych zarządzanych przez rozwiązanie Azure VMware Solution (SNAT)
- Opcja 3. Publiczny adres IPv4 platformy Azure do krawędzi centrum danych NSX-T
Projekt wirtualnej sieci WAN z dwoma regionami, który ma intencję routingu, obsługuje wszystkie opcje, ale zalecamy opcję 1. Scenariusz w dalszej części tego artykułu używa opcji 1 do zapewnienia łączności z Internetem. Opcja 1 działa najlepiej z bezpiecznym wirtualnym siecią WAN, ponieważ łatwo jest sprawdzać, wdrażać i zarządzać.
Po włączeniu intencji routingu w obu bezpiecznych centrach anonsuje dokument RFC 1918 do bezpośrednio równorzędnych sieci wirtualnych. Można jednak również anonsować trasę domyślną 0.0.0.0/0 na potrzeby łączności internetowej z zasobami podrzędnym. Po włączeniu intencji routingu można wygenerować trasę domyślną z obu zapór koncentratora. Ta trasa domyślna anonsuje się do bezpośrednio równorzędnych sieci wirtualnych i bezpośrednio połączonych z usługą Azure VMware Solution.
Usługa Azure VMware Solution i łączność z internetem sieci wirtualnej
Na poniższym diagramie przedstawiono przepływy ruchu dla chmur prywatnych i sieci wirtualnych rozwiązania Azure VMware Solution.
W poniższej tabeli opisano przepływ ruchu na powyższym diagramie.
Numer przepływu ruchu | Element źródłowy | Element docelowy | Czy bezpieczna zapora koncentratora usługi Virtual WAN sprawdza ten ruch? |
---|---|---|---|
11 | Region chmury usługi Azure VMware Solution 1 | Internet | Tak, za pośrednictwem zapory koncentratora 1 |
12 | Sieć wirtualna 2 | Internet | Tak, za pośrednictwem zapory koncentratora 2 |
13 | Sieć wirtualna 1 | Internet | Tak, za pośrednictwem zapory koncentratora 1 |
14 | Region chmury usługi Azure VMware Solution 2 | Internet | Tak, za pośrednictwem zapory koncentratora 2 |
Po włączeniu intencji routingu dla ruchu internetowego domyślnie bezpieczne centrum usługi Virtual WAN nie anonsuje trasy domyślnej między obwodami usługi ExpressRoute. Aby upewnić się, że trasa domyślna jest propagowana do bezpośrednio połączonej usługi Azure VMware Solution z wirtualnej sieci WAN, należy włączyć propagację tras domyślnych w obwodach usługi ExpressRoute usługi Azure VMware Solution. Aby uzyskać więcej informacji, zobacz Anonsuj trasę domyślną 0.0.0.0/0 do punktów końcowych.
Po włączeniu propagacji trasy domyślnej połączenie D anonsuje trasę domyślną 0.0.0.0/0 z centrum. Nie włączaj tego ustawienia dla lokalnych obwodów usługi ExpressRoute. Zalecamy zaimplementowanie filtru BGP (Border Gateway Protocol) na sprzęcie lokalnym w celu wykluczenia uczenia się trasy domyślnej. Filtr protokołu BGP dodaje dodatkową warstwę ochrony i pomaga zapewnić, że konfiguracja nie ma wpływu na lokalną łączność z Internetem.
Po włączeniu intencji routingu dla dostępu do Internetu oba centra regionalne generują trasę domyślną i anonsują ją do połączeń sieci wirtualnej równorzędnej koncentratora. Należy pamiętać, że w kartach interfejsów sieciowych maszyn wirtualnych w sieci wirtualnej następny przeskok 0.0.0.0/0 jest zaporą koncentratora. Aby znaleźć następny przeskok, wybierz pozycję Obowiązujące trasy w karcie sieciowej. Trasa domyślna nie anonsuje się między koncentratorami regionalnymi za pośrednictwem łącza międzyhubowego. W związku z tym sieci wirtualne używają lokalnego centrum regionalnego do uzyskiwania dostępu do Internetu i nie mają kopii zapasowych łączności internetowej z koncentratorem między regionami.
Odporność dostępu do Internetu dla rozwiązania Azure VMware Solution
Jeśli nie używasz usługi Global Reach w projekcie z dwoma regionami, wychodząca łączność internetowa nie ma nadmiarowości, ponieważ każda chmura prywatna usługi Azure VMware Solution uczy się trasy domyślnej z lokalnego centrum regionalnego i nie jest bezpośrednio połączona z centrum między regionami. Jeśli awaria regionalna ma wpływ na lokalne centrum regionalne, użyj jednej z następujących konfiguracji ręcznych, aby uzyskać nadmiarowość internetową.
Opcja 1
Użyj tej opcji tylko dla wychodzącego dostępu do Internetu. Jeśli podczas lokalnej awarii regionalnej potrzebujesz wychodzącego dostępu do Internetu dla obciążenia usługi Azure VMware Solution, użyj zarządzanej przez rozwiązanie SNAT usługi Azure VMware Solution. To rozwiązanie zapewnia prosty i szybki dostęp. Aby uzyskać więcej informacji, zobacz Włączanie zarządzanego protokołu SNAT dla obciążeń usługi Azure VMware Solution.
Opcja 2
Użyj tej opcji w przypadku dostępu przychodzącego i wychodzącego do Internetu. Jeśli podczas lokalnej awarii regionalnej potrzebujesz zarówno przychodzącego, jak i wychodzącego dostępu do Internetu dla chmury usługi Azure VMware Solution, użyj następującej metody.
Usuń połączenie, które przechodzi z usługi Azure VMware Solution do lokalnego centrum regionalnego (połączenie D na diagramach).
W witrynie Azure Portal wybierz pozycję Azure VMware Solution i usuń klucz autoryzacji utworzony na potrzeby połączenia D.
Utwórz nowe połączenie z koncentratorem między regionami.
Aby obsługiwać ruch przychodzący, rozważ użycie usługi Azure Front Door lub Azure Traffic Manager w celu zachowania wysokiej dostępności regionalnej.
Korzystanie z sieci VMware HCX Mobility Optimized Networking (MON) bez zasięgu globalnego
Możesz włączyć funkcję HCX Mobility Optimized Networking (MON) podczas korzystania z rozszerzenia sieciowego HCX. Baza danych MON zapewnia optymalny routing ruchu w niektórych scenariuszach, aby zapobiec nakładaniu się sieci lub pętli między zasobami opartymi na środowisku lokalnym i w chmurze w sieciach rozszerzonych.
Ruch wychodzący z rozwiązania Azure VMware Solution
Po włączeniu mon dla określonej sieci rozszerzonej i maszyny wirtualnej przepływ ruchu zmienia się. Po zaimplementowaniu bazy danych MON ruch wychodzący z maszyny wirtualnej nie będzie pętli z powrotem do środowiska lokalnego. Zamiast tego pomija tunel IPSec rozszerzenia sieci. Ruch maszyny wirtualnej kończy się z bramy usługi Azure VMware Solution NSX-T Tier-1, przechodzi do bramy NSX-T Tier-0, a następnie przechodzi do wirtualnej sieci WAN.
Ruch przychodzący do rozwiązania Azure VMware Solution
Po włączeniu mon dla określonej sieci rozszerzonej i maszyny wirtualnej należy wprowadzić następujące zmiany. Z usługi Azure VMware Solution NSX-T mon wprowadza trasę hosta /32 z powrotem do wirtualnej sieci WAN. Usługa Virtual WAN anonsuje tę trasę /32 z powrotem do sieci lokalnych, sieci wirtualnych i sieci oddziałów. Ta trasa hosta /32 gwarantuje, że ruch z sieci lokalnych, sieci wirtualnych i sieci oddziałów nie korzysta z tunelu IPSec rozszerzenia sieci, gdy ruch przechodzi do maszyny wirtualnej z obsługą mon. Ruch z sieci źródłowych przechodzi bezpośrednio do maszyny wirtualnej z obsługą mon, ponieważ uczy się trasy /32.
Ograniczenie mon rozwiązania HCX dla bezpiecznej wirtualnej sieci WAN bez globalnego zasięgu
Po włączeniu przechodniości usługi ExpressRoute-to-ExpressRoute w bezpiecznym centrum i włączeniu intencji routingu bezpieczny koncentrator wysyła domyślne adresy RFC 1918 zarówno do lokalnego, jak i rozwiązania Azure VMware Solution. Oprócz domyślnych adresów RFC 1918 zarówno lokalnych, jak i usługi Azure VMware Solution, poznaj bardziej szczegółowe trasy z sieci wirtualnych platformy Azure i sieci oddziałów łączących się z koncentratorem.
Jednak sieci lokalne nie uczą się określonych tras z usługi Azure VMware Solution, a rozwiązanie Azure VMware Solution nie uczy się określonych tras z sieci lokalnych. Zamiast tego oba środowiska bazują na domyślnych adresach RFC 1918, aby ułatwić routing z powrotem do siebie za pośrednictwem zapory koncentratora. W związku z tym bardziej szczegółowe trasy, takie jak trasy hosta MON, nie anonsują się z usługi ExpressRoute usługi Azure VMware Solution do obwodu usługi ExpressRoute opartego na środowisku lokalnym. Dotyczy to również odwrotnej sytuacji. Niezdolność do uczenia się określonych tras wprowadza asymetryczne przepływy ruchu. Ruch wychodzący z rozwiązania Azure VMware Solution za pośrednictwem bramy NSX-T Tier-0, ale zwraca ruch ze środowiska lokalnego zwracany przez tunel IPSec rozszerzenia sieci.
Poprawianie asymetrii ruchu
Aby poprawić asymetrię ruchu, należy dostosować trasy zasad MON. Trasy zasad MON określają, który ruch wraca do bramy lokalnej za pośrednictwem rozszerzenia L2. Decydują również, który ruch przechodzi przez bramę NSX rozwiązania Azure VMware Solution w warstwie 0.
Jeśli docelowy adres IP jest zgodny z ustawieniami dozwolonymi w konfiguracji zasad MON, zostaną wykonane dwie akcje. Najpierw system identyfikuje pakiet. Po drugie system wysyła pakiet do bramy lokalnej za pośrednictwem urządzenia rozszerzenia sieciowego.
Jeśli docelowy adres IP nie jest zgodny lub ustawiono go na odmowę w zasadach MON, system wysyła pakiet do bramy usługi Azure VMware Solution Tier-0 na potrzeby routingu.
W poniższej tabeli opisano trasy zasad HCX.
Sieć | Przekierowywanie do elementu równorzędnego | Uwaga |
---|---|---|
Przestrzeń adresowa sieci wirtualnej platformy Azure | Zablokuj | Jawnie uwzględnij zakresy adresów dla wszystkich sieci wirtualnych. Ruch przeznaczony dla platformy Azure kieruje ruch wychodzący za pośrednictwem usługi Azure VMware Solution i nie wraca do sieci lokalnej. |
Domyślne przestrzenie adresowe RFC 1918 | Zezwalaj | Dodaj domyślne adresy RFC 1918. Ta konfiguracja gwarantuje, że każdy ruch, który nie spełnia powyższych kryteriów, przekierowuje z powrotem do sieci lokalnej. Jeśli konfiguracja lokalna używa adresów, które nie są częścią RFC 1918, należy jawnie uwzględnić te zakresy. |
0.0.0.0/0 przestrzeń adresowa | Zablokuj | Adresy, które RFC 1918 nie obejmują, takich jak adresy IP routingu internetowego lub ruch, który nie jest zgodny z określonymi wpisami, wyjdź bezpośrednio za pośrednictwem rozwiązania Azure VMware Solution i nie przekierowuje z powrotem do sieci lokalnej. |