Migrowanie do usługi Azure Virtual WAN

Usługa Azure Virtual WAN umożliwia firmom uproszczenie łączności globalnej w celu skorzystania ze skali globalnej sieci firmy Microsoft. Ten artykuł zawiera szczegółowe informacje techniczne dotyczące firm, które chcą przeprowadzić migrację z istniejącej topologii piasty i szprych zarządzanej przez klienta do projektu wykorzystującego koncentratory wirtualnej sieci WAN zarządzanej przez firmę Microsoft.

Aby uzyskać informacje o korzyściach, jakie usługa Azure Virtual WAN umożliwia przedsiębiorstwom wdrażanie nowoczesnej sieci globalnej przedsiębiorstwa skoncentrowanej na chmurze, zobacz Global transit network architecture (Architektura globalnej sieci tranzytowej) i Virtual WAN (Wirtualna sieć WAN).

Rysunek: Azure Virtual WAN

Model łączności piasty i szprych platformy Azure został przyjęty przez tysiące naszych klientów, aby wykorzystać domyślne przejściowe zachowanie routingu usługi Azure Networking w celu utworzenia prostych i skalowalnych sieci w chmurze. Usługa Azure Virtual WAN opiera się na tych pojęciach i wprowadza nowe możliwości, które umożliwiają globalne topologie łączności, nie tylko między lokalizacjami lokalnymi i platformą Azure, ale także umożliwiają klientom wykorzystanie skali sieci firmy Microsoft w celu rozszerzenia istniejących sieci globalnych.

W tym artykule pokazano, jak przeprowadzić migrację istniejącego środowiska piasty i szprych zarządzanego przez klienta do topologii opartej na usłudze Azure Virtual WAN.

Scenariusz

Firma Contoso jest globalną organizacją finansową z biurami w Europie i Azji. Planuje przenieść istniejące aplikacje z lokalnego centrum danych na platformę Azure i utworzyć podstawowy projekt oparty na architekturze piasty i szprych zarządzanej przez klienta, w tym regionalnych sieci wirtualnych piasty na potrzeby łączności hybrydowej. W ramach przejścia do technologii opartych na chmurze zespół ds. sieci ma za zadanie zapewnić, że ich łączność jest zoptymalizowana pod kątem rozwoju firmy.

Na poniższej ilustracji przedstawiono ogólny widok istniejącej sieci globalnej, w tym łączność z wieloma regionami świadczenia usługi Azure.

Rysunek: Istniejąca topologia sieci firmy Contoso

Z istniejącej topologii sieci można zrozumieć następujące kwestie:

• Topologia piasty i szprych jest używana w wielu regionach, w tym obwodach usługi ExpressRoute na potrzeby łączności z wspólną prywatną siecią rozległą (WAN).

• Niektóre z tych witryn mają również tunele sieci VPN bezpośrednio na platformie Azure, aby uzyskać dostęp do aplikacji hostowanych w chmurze.

Wymagania

Zespół ds. sieci ma za zadanie dostarczyć globalny model sieci, który może obsługiwać migrację firmy Contoso do chmury i musi zoptymalizować obszary kosztów, skalowania i wydajności. Podsumowując, należy spełnić następujące wymagania:

• Zapewnij zarówno siedzibę centralną, jak i biura oddziałów ze zoptymalizowaną ścieżką do aplikacji hostowanych w chmurze.
• Usuń zależność od istniejących lokalnych centrów danych (DC) dla zakończenia sieci VPN, zachowując następujące ścieżki łączności:
  • Oddział-sieć wirtualna: połączone biura sieci VPN muszą mieć dostęp do aplikacji migrowanych do chmury w lokalnym regionie świadczenia usługi Azure.
  • Połączenia między oddziałami i koncentratorami: połączone biura sieci VPN muszą mieć dostęp do aplikacji migrowanych do chmury w zdalnym regionie świadczenia usługi Azure.
  • Oddział-oddział: Regionalne biura połączone sieci VPN muszą być w stanie komunikować się ze sobą, a połączone lokacje HQ/DC usługi ExpressRoute.
  • Połączenia między oddziałami i koncentratorami: globalnie oddzielone połączone biura sieci VPN muszą mieć możliwość komunikowania się ze sobą i wszystkich połączonych lokacji HQ/DC usługi ExpressRoute.
  • Odgałęzienie do Internetu: połączone witryny muszą być w stanie komunikować się z Internetem. Ten ruch musi być filtrowany i rejestrowany.
  • Sieć wirtualna-sieć wirtualna: sieci wirtualne będące szprychami w tym samym regionie muszą być w stanie komunikować się ze sobą.
  • Sieć wirtualna-koncentrator do sieci wirtualnej: sieci wirtualne będące szprychami w różnych regionach muszą być w stanie komunikować się ze sobą.
• Zapewnij użytkownikom mobilnym (laptopom i telefonom) firmy Contoso możliwość uzyskiwania dostępu do zasobów firmy, a nie w sieci firmowej.

Architektura wirtualnej sieci WAN platformy Azure

Na poniższej ilustracji przedstawiono ogólny widok zaktualizowanej topologii docelowej przy użyciu usługi Azure Virtual WAN w celu spełnienia wymagań opisanych w poprzedniej sekcji.

Rysunek: Architektura usługi Azure Virtual WAN

Podsumowanie:

• Centrala w Europie pozostaje połączona z usługą ExpressRoute, lokalny kontroler domeny w Europie jest w pełni migrowany na platformę Azure i teraz zlikwidowany.
• Asia DC i HQ pozostają połączone z prywatną siecią WAN. Usługa Azure Virtual WAN jest teraz używana do rozszerzania lokalnej sieci przewoźnika i zapewniania łączności globalnej.
• Koncentratory usługi Azure Virtual WAN wdrożone zarówno w regionach Europa Zachodnia, jak i Południowo-Wschodnia Azja Azure w celu zapewnienia koncentratora łączności dla urządzeń połączonych z usługą ExpressRoute i sieci VPN.
• Centra zapewniają również przerwanie sieci VPN dla użytkowników mobilnych w wielu typach klientów przy użyciu łączności OpenVPN z globalną siecią siatki, umożliwiając dostęp nie tylko do aplikacji migrowanych na platformę Azure, ale także wszystkich zasobów pozostałych lokalnie.
• Łączność z Internetem dla zasobów w sieci wirtualnej udostępnianej przez usługę Azure Virtual WAN.

Łączność z Internetem dla witryn zdalnych również zapewniana przez usługę Azure Virtual WAN. Lokalny podział w Internecie obsługiwany za pośrednictwem integracji partnerów w celu zoptymalizowanego dostępu do usług SaaS, takich jak Microsoft 365.

Migrowanie do usługi Virtual WAN

W tej sekcji przedstawiono różne kroki migracji do usługi Azure Virtual WAN.

Krok 1. Pojedynczy region zarządzany przez centrum i szprychy zarządzane przez klienta

Na poniższej ilustracji przedstawiono topologię pojedynczego regionu dla firmy Contoso przed wdrożeniem usługi Azure Virtual WAN:

Rysunek 1. Ręczne ręczne piasty i szprychy w jednym regionie

Zgodnie z podejściem piasty i szprych sieć wirtualna koncentratora zarządzanego przez klienta zawiera kilka bloków funkcji:

• Usługi udostępnione (każda wspólna funkcja wymagana przez wiele szprych). Przykład: firma Contoso używa kontrolerów domeny systemu Windows Server na maszynach wirtualnych typu infrastruktura jako usługa (IaaS).
• Usługi zapory ip/routingu są udostępniane przez wirtualne urządzenie sieciowe innej firmy, co umożliwia routing adresów IP w warstwie 3 szprychy.
• Internetowe usługi ruchu przychodzącego/wychodzącego, w tym aplikacja systemu Azure Gateway dla przychodzących żądań HTTPS i usług proxy innych firm działających na maszynach wirtualnych w celu filtrowania dostępu wychodzącego do zasobów internetowych.
• Brama sieci wirtualnej usługi ExpressRoute i sieci VPN na potrzeby łączności z sieciami lokalnymi.

Krok 2. Wdrażanie koncentratorów usługi Virtual WAN

Wdróż koncentrator usługi Virtual WAN w każdym regionie. Skonfiguruj koncentrator usługi Virtual WAN z siecią VPN i funkcją usługi ExpressRoute zgodnie z opisem w następujących artykułach:

• Samouczek: tworzenie połączenia lokacja-lokacja przy użyciu usługi Azure Virtual WAN
• Samouczek: tworzenie skojarzenia usługi ExpressRoute przy użyciu usługi Azure Virtual WAN

Uwaga

Usługa Azure Virtual WAN musi używać standardowej jednostki SKU, aby umożliwić niektóre ścieżki ruchu pokazane w tym artykule.

Rysunek 2. Migracja usługi Virtual WAN zarządzana przez klienta z piastą i szprychą

Krok 3. Łączenie lokacji zdalnych (usługi ExpressRoute i sieci VPN) z usługą Virtual WAN

Połącz koncentrator usługi Virtual WAN z istniejącymi obwodami usługi ExpressRoute i skonfiguruj sieci VPN typu lokacja-lokacja za pośrednictwem Internetu z dowolnymi gałęziami zdalnymi.

Rysunek 3. Migracja usługi Virtual WAN zarządzana przez klienta

W tym momencie lokalny sprzęt sieciowy zacznie odbierać trasy odzwierciedlające przestrzeń adresów IP przypisaną do sieci wirtualnej koncentratora zarządzanego przez usługę Virtual WAN. Zdalne gałęzie połączone z siecią VPN na tym etapie będą widzieć dwie ścieżki do wszystkich istniejących aplikacji w sieciach wirtualnych szprych. Te urządzenia powinny być skonfigurowane tak, aby nadal używać tunelu do centrum zarządzanego przez klienta w celu zapewnienia symetrycznego routingu w fazie przejścia.

Krok 4. Testowanie łączności hybrydowej za pośrednictwem wirtualnej sieci WAN

Przed użyciem zarządzanego koncentratora usługi Virtual WAN na potrzeby łączności produkcyjnej zalecamy skonfigurowanie testowej sieci wirtualnej będącej szprychą i połączenia sieci wirtualnej usługi Virtual WAN. Przed kontynuowaniem następnych kroków sprawdź, czy połączenia z tym środowiskiem testowym działają za pośrednictwem usługi ExpressRoute i sieci VPN typu lokacja-lokacja.

Rysunek 4. Migracja usługi Virtual WAN zarządzana przez klienta z piastą i szprychą

Na tym etapie należy pamiętać, że zarówno oryginalna sieć wirtualna koncentratora zarządzanego przez klienta, jak i nowa usługa Virtual WAN Hub są połączone z tym samym obwodem usługi ExpressRoute. W związku z tym mamy ścieżkę ruchu, która może służyć do włączania szprych w obu środowiskach do komunikacji. Na przykład ruch z szprychy dołączonej do sieci wirtualnej koncentratora zarządzanego przez klienta będzie przechodzić przez urządzenia MSEE używane do obwodu usługi ExpressRoute w celu dotarcia do dowolnego szprychy połączonego za pośrednictwem połączenia sieci wirtualnej z nowym koncentratorem usługi Virtual WAN. Umożliwia to etapową migrację szprych w kroku 5.

Krok 5. Przejście łączności z koncentratorem wirtualnej sieci WAN

Rysunek 5. Migracja usługi Virtual WAN zarządzana przez klienta z piastą i szprychą

a. Usuń istniejące połączenia komunikacji równorzędnej z sieci wirtualnych szprych do starego centrum zarządzanego przez klienta. Dostęp do aplikacji w sieciach wirtualnych szprych jest niedostępny do momentu ukończenia kroków a-c.

b. Połącz sieci wirtualne będące szprychami z koncentratorem usługi Virtual WAN za pośrednictwem połączeń sieci wirtualnej.

c. Usuń wszystkie trasy zdefiniowane przez użytkownika (UDR) używane wcześniej w sieciach wirtualnych szprych na potrzeby komunikacji szprychy do szprych. Ta ścieżka jest teraz włączona przez routing dynamiczny dostępny w koncentratorze usługi Virtual WAN.

d. Istniejące bramy usługi ExpressRoute i VPN Gateway w centrum zarządzanym przez klienta są teraz likwidowane, aby zezwolić na następny krok (e).

e. Połącz stare centrum zarządzane przez klienta (sieć wirtualną koncentratora) z koncentratorem usługi Virtual WAN za pośrednictwem nowego połączenia sieci wirtualnej.

Krok 6. Stary koncentrator staje się szprychą usług udostępnionych

Teraz przeprojektowaliśmy naszą sieć platformy Azure, aby centrum usługi Virtual WAN było centralnym punktem naszej nowej topologii.

Rysunek 6. Migracja usługi Virtual WAN zarządzana przez klienta z piastą i szprychą

Ponieważ koncentrator usługi Virtual WAN jest jednostką zarządzaną i nie zezwala na wdrażanie zasobów niestandardowych, takich jak maszyny wirtualne, blok usług udostępnionych istnieje teraz jako sieć wirtualna szprychy i hosty funkcje, takie jak ruch przychodzący do Internetu za pośrednictwem bramy aplikacja systemu Azure lub wirtualnego urządzenia sieciowego. Ruch między środowiskiem usług udostępnionych a maszynami wirtualnymi zaplecza jest teraz przesyłany przez koncentrator zarządzany przez usługę Virtual WAN.

Krok 7. Optymalizowanie łączności lokalnej w celu pełnego wykorzystania wirtualnej sieci WAN

Na tym etapie firma Contoso w większości ukończyła migracje aplikacji biznesowych do chmury firmy Microsoft, a tylko kilka starszych aplikacji pozostaje w lokalnym kontrolerze domeny.

Rysunek 7. Migracja usługi Virtual WAN zarządzana przez klienta z piastą i szprychą

Aby wykorzystać pełną funkcjonalność usługi Azure Virtual WAN, firma Contoso decyduje się zlikwidować starsze lokalne połączenia sieci VPN. Wszystkie gałęzie, które nadal uzyskują dostęp do sieci HQ lub DC, mogą przekazywać globalną sieć firmy Microsoft przy użyciu wbudowanego routingu tranzytowego usługi Azure Virtual WAN.

Uwaga

Usługa ExpressRoute Global Reach jest wymagana dla klientów, którzy chcą korzystać z sieci szkieletowej firmy Microsoft, aby zapewnić tranzyt usługi ExpressRoute do usługi ExpressRoute (nie pokazano na rysunku 7).

Architektura stanu końcowego i ścieżki ruchu

Rysunek: Usługa Virtual WAN w dwóch regionach

Ta sekcja zawiera podsumowanie sposobu, w jaki ta topologia spełnia oryginalne wymagania, przeglądając przykładowe przepływy ruchu.

Ścieżka 1

Ścieżka 1 pokazuje przepływ ruchu z połączonej gałęzi sieci VPN S2S w Azji do sieci wirtualnej platformy Azure w regionie Azji Południowo-Wschodniej.

Ruch jest kierowany w następujący sposób:

• Gałąź Azja jest połączona za pośrednictwem odpornych tuneli protokołu BGP S2S do koncentratora wirtualnej sieci WAN Azji Południowo-Wschodniej.

• Centrum Asia Virtual WAN kieruje ruch lokalnie do połączonej sieci wirtualnej.

Ścieżka 2

Ścieżka 2 pokazuje przepływ ruchu z połączonej europejskiej siedziby usługi ExpressRoute z siecią wirtualną platformy Azure w regionie Azji Południowo-Wschodniej.

Ruch jest kierowany w następujący sposób:

• Europejska centrala jest połączona za pośrednictwem obwodu usługi ExpressRoute z koncentratorem Virtual WAN w regionie Europa Zachodnia.

• Globalna łączność koncentratora usługi Virtual WAN umożliwia tranzyt ruchu do sieci wirtualnej połączonej w regionie zdalnym.

Ścieżka 3

Ścieżka 3 przedstawia przepływ ruchu z lokalnego kontrolera domeny Azji połączonego z prywatną siecią WAN do europejskiej połączonej gałęzi S2S.

Ruch jest kierowany w następujący sposób:

• Asia DC jest połączony z lokalnym prywatnym przewoźnikiem sieci WAN.

• Obwód usługi ExpressRoute lokalnie kończy się w prywatnej sieci WAN łączy się z koncentratorem virtual WAN Azji Południowo-Wschodniej.

• Globalna łączność koncentratora usługi Virtual WAN umożliwia tranzyt ruchu.

Ścieżka 4

Ścieżka 4 przedstawia przepływ ruchu z sieci wirtualnej platformy Azure w regionie Azji Południowo-Wschodniej do sieci wirtualnej platformy Azure w regionie Europa Zachodnia.

Ruch jest kierowany w następujący sposób:

• Globalna łączność koncentratora usługi Virtual WAN umożliwia natywny tranzyt wszystkich połączonych sieci wirtualnych platformy Azure bez dalszej konfiguracji użytkownika.

Ścieżka 5

Ścieżka 5 przedstawia przepływ ruchu z roamingu użytkowników sieci VPN (P2S) do sieci wirtualnej platformy Azure w regionie Europa Zachodnia.

Ruch jest kierowany w następujący sposób:

• Użytkownicy laptopów i urządzeń przenośnych używają klienta OpenVPN do przezroczystej łączności z bramą sieci VPN typu punkt-lokacja w regionie Europa Zachodnia.

• Koncentrator wirtualnej sieci WAN w regionie Europa Zachodnia kieruje ruch lokalnie do połączonej sieci wirtualnej.

Kontrola zabezpieczeń i zasad za pośrednictwem usługi Azure Firewall

Firma Contoso zweryfikowała teraz łączność między wszystkimi gałęziami i sieciami wirtualnymi zgodnie z wymaganiami omówionymi wcześniej w tym artykule. Aby spełnić wymagania dotyczące kontroli zabezpieczeń i izolacji sieci, muszą nadal oddzielać i rejestrować ruch za pośrednictwem sieci koncentratora. Wcześniej ta funkcja była wykonywana przez wirtualne urządzenie sieciowe (WUS). Firma Contoso chce również zlikwidować istniejące usługi proxy i korzystać z natywnych usług platformy Azure na potrzeby filtrowania wychodzącego Internetu.

Rysunek: Usługa Azure Firewall w usłudze Virtual WAN (zabezpieczone koncentrator wirtualny)

Aby umożliwić ujednolicony punkt kontroli zasad, wymagane są następujące ogólne kroki wprowadzenia usługi Azure Firewall do koncentratorów usługi Virtual WAN. Aby uzyskać więcej informacji na temat tego procesu i koncepcji bezpiecznych koncentratorów wirtualnych, zobacz Azure Firewall Manager.

1. Tworzenie zasad usługi Azure Firewall.
2. Łączenie zasad zapory z koncentratorem usługi Azure Virtual WAN. Ten krok umożliwia istniejącemu koncentratorowi usługi Virtual WAN działanie jako zabezpieczonego koncentratora wirtualnego i wdrożenie wymaganych zasobów usługi Azure Firewall.

Uwaga

Istnieją ograniczenia dotyczące używania zabezpieczonych koncentratorów wirtualnych, w tym ruchu między regionami. Aby uzyskać więcej informacji, zobacz Menedżer zapory — znane problemy.

W poniższych ścieżkach przedstawiono ścieżki łączności włączone przy użyciu zabezpieczonych koncentratorów wirtualnych platformy Azure:

Ścieżka 6

Ścieżka 6 pokazuje bezpieczny przepływ ruchu między sieciami wirtualnymi w tym samym regionie.

Ruch jest kierowany w następujący sposób:

• Sieci wirtualne połączone z tym samym zabezpieczonym koncentratorem wirtualnym kierują teraz ruch do usługi Azure Firewall.

• Usługa Azure Firewall może stosować zasady do tych przepływów.

Ścieżka 7

Ścieżka 7 przedstawia przepływ ruchu z sieci wirtualnej platformy Azure do Internetu lub usługi zabezpieczeń innej firmy.

Ruch jest kierowany w następujący sposób:

• Sieci wirtualne połączone z bezpiecznym koncentratorem wirtualnym mogą wysyłać ruch do publicznych miejsc docelowych w Internecie przy użyciu bezpiecznego centrum jako centralnego punktu dostępu do Internetu.

• Ten ruch można filtrować lokalnie przy użyciu reguł FQDN usługi Azure Firewall lub wysyłać do usługi zabezpieczeń innej firmy w celu przeprowadzenia inspekcji.

Ścieżka 8

Ścieżka 8 pokazuje przepływ ruchu z usługi zabezpieczeń od gałęzi do Internetu lub usługi zabezpieczeń innej firmy.

Ruch jest kierowany w następujący sposób:

• Gałęzie połączone z bezpiecznym koncentratorem wirtualnym mogą wysyłać ruch do publicznych miejsc docelowych w Internecie przy użyciu bezpiecznego centrum jako centralnego punktu dostępu do Internetu.

• Ten ruch można filtrować lokalnie przy użyciu reguł FQDN usługi Azure Firewall lub wysyłać do usługi zabezpieczeń innej firmy w celu przeprowadzenia inspekcji.

Następne kroki

• Dowiedz się więcej o usłudze Azure Virtual WAN.
• Konfigurowanie wirtualnej sieci WAN dla usługi Azure NetApp Files