Migrowanie do usługi Azure Virtual WAN

Usługa Azure Virtual WAN pozwala firmom uprościć globalną łączność w celu skorzystania ze skali globalnej sieci firmy Microsoft. Ten artykuł zawiera szczegóły techniczne dotyczące firm, które chcą przeprowadzić migrację z istniejącej topologii piasty i szprych zarządzanej przez klienta do projektu wykorzystującego centra Virtual WAN zarządzane przez firmę Microsoft.

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

rysunek gwiazdy: Azure Virtual WAN

Model łączności piasty i szprych platformy Azure został przyjęty przez tysiące naszych klientów, aby wykorzystać domyślne przechodnie zachowanie routingu sieci platformy Azure w celu tworzenia 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

Contoso to globalna organizacja finansowa z biurami w Europie i Azji. Planuje przenieść istniejące aplikacje z lokalnego centrum danych na platformę Azure i utworzyć projekt podstawowy oparty na architekturze piasty i szprych zarządzanej przez klienta, w tym regionalnych sieci wirtualnych koncentratora 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

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

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

• Niektóre z tych lokacji 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 być optymalizowany w obszarach kosztów, skalowania i wydajności. Podsumowując, należy spełnić następujące wymagania:

• Zapewnij zarówno główne kwartały (HQ), 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) na potrzeby kończenia działania 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łączenie między oddziałami i sieciami wirtualnymi: połączone biura sieci VPN muszą mieć dostęp do aplikacji migrowanych do chmury w zdalnym regionie świadczenia usługi Azure.
  • Oddział-oddział: Regionalne połączone biura sieci VPN muszą mieć możliwość komunikowania się ze sobą i połączonych lokacji HQ/DC usługi ExpressRoute.
  • Oddział-piasta-oddział: 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ą.
  • Połączenie między sieciami wirtualnymi typu piasta-sieć wirtualna: sieci wirtualne będące szprychami w różnych regionach muszą być w stanie komunikować się ze sobą.
• Zapewnij użytkownikom mobilnym firmy Contoso (laptopowi i telefonowi) dostęp do zasobów firmy, a nie w sieci firmowej.

Architektura usługi Azure Virtual WAN

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, a lokalny kontroler domeny w Europie jest w pełni migrowany na platformę Azure i jest teraz zlikwidowany.
• Azja DC i HQ pozostają połączone z prywatną siecią WAN. Usługa Azure Virtual WAN teraz używana do rozszerzania sieci przewoźnika lokalnego i zapewniania łączności globalnej.
• Centra usługi Azure Virtual WAN wdrożone w regionach świadczenia usługi Azure Europa Zachodnia i Azja Południowo-Wschodnia w celu zapewnienia centrum łą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 lokacji zdalnych zapewniana również przez usługę Azure Virtual WAN. Lokalny podział internetowy obsługiwany za pośrednictwem integracji partnera 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ęczny koncentrator i szprycha 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 (dowolna wspólna funkcja wymagana przez wiele szprych). Przykład: firma Contoso używa kontrolerów domeny systemu Windows Server na maszynach wirtualnych IaaS (Infrastructure-as-a-service).
• 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 będącej szprychą.
• Internetowe usługi ruchu przychodzącego/wychodzącego, w tym Azure Application Gateway dla przychodzących żądań HTTPS i usług proxy innych firm działających na maszynach wirtualnych w celu odfiltrowania 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 centrów Virtual WAN

Wdróż centrum Virtual WAN w każdym regionie. Skonfiguruj centrum Virtual WAN przy użyciu sieci VPN i funkcji 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 centrum i szp Virtual WAN rych zarządzana przez klienta

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

Połącz centrum Virtual WAN z istniejącymi obwodami usługi ExpressRoute i skonfiguruj sieci VPN typu lokacja-lokacja przez Internet z dowolnymi gałęziami zdalnymi.

Figure 3: centrum i szprychy zarządzane przez klienta w celu Virtual WAN migracji

W tym momencie lokalny sprzęt sieciowy zacznie odbierać trasy odzwierciedlające przestrzeń adresów IP przypisaną do sieci wirtualnej koncentratora zarządzanego przez Virtual WAN. Na tym etapie zdalne gałęzie połączone z siecią VPN będą widzieć dwie ścieżki do wszystkich istniejących aplikacji w sieciach wirtualnych szprych. Te urządzenia powinny być skonfigurowane tak, aby nadal korzystały z 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 Virtual WAN

Przed rozpoczęciem korzystania z zarządzanego centrum Virtual WAN na potrzeby łączności produkcyjnej zalecamy skonfigurowanie testowej sieci wirtualnej będącej szprychą i Virtual WAN połączenia sieci wirtualnej. 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.

Figure 4: centrum i szprych zarządzane przez klienta w celu Virtual WAN migracji

Na tym etapie należy pamiętać, że zarówno oryginalna sieć wirtualna koncentratora zarządzanego przez klienta, jak i nowe centrum Virtual WAN 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 umożliwienia komunikacji szprych w obu środowiskach. Na przykład ruch ze 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, aby uzyskać dostęp do dowolnej szprychy połączonej za pośrednictwem połączenia sieci wirtualnej z nowym koncentratorem Virtual WAN. Umożliwia to migrację etapową szprych w kroku 5.

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

Rysunek 5: Migracja z centrum Virtual WAN zarządzanego 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 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 szprycha-szprych. Ta ścieżka jest teraz włączona przez routing dynamiczny dostępny w centrum Virtual WAN.

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

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

Krok 6. Stare centrum staje się szprychą usług udostępnionych

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

Rysunek 6: Centrum i szprychy zarządzane przez klienta w celu Virtual WAN migracji

Ponieważ centrum 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 Azure Application Gateway lub wirtualnego urządzenia sieciowego. Ruch między środowiskiem usług udostępnionych a maszynami wirtualnymi zaplecza przesyła teraz centrum zarządzane przez Virtual WAN.

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

Na tym etapie firma Contoso ukończyła głównie migracje aplikacji biznesowych do chmury firmy Microsoft, a tylko kilka starszych aplikacji pozostaje w lokalnym kontrolerze domeny.

Figure 7: centrum i szprychy zarządzane przez klienta w celu Virtual WAN migracji

Aby korzystać z pełnej funkcjonalności 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ą przesłać sieć globalną 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: Podwójny region Virtual WAN

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

Ścieżka 1

Ścieżka 1 przedstawia 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 BGP S2S do południowo-wschodniej Azji Virtual WAN centrum.

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

Ścieżka 2

Ścieżka 2 przedstawia 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 centrum Virtual WAN Europy Zachodniej.

• Virtual WAN łączności globalnej piasta-koncentrator 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 centrum Virtual WAN Azji Południowo-Wschodniej.

• Virtual WAN łączność globalna piasta-koncentrator 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:

• Virtual WAN łączność globalna między koncentratorami 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.

• Europa Zachodnia Virtual WAN centrum kieruje ruch lokalnie do połączonej sieci wirtualnej.

Kontrola zabezpieczeń i zasad za pośrednictwem 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 piasty. 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.

Figure: Azure Firewall w Virtual WAN (zabezpieczone koncentrator wirtualny)

Do wprowadzenia Azure Firewall do centrów Virtual WAN wymagane są następujące ogólne kroki, aby umożliwić ujednolicony punkt kontroli zasad. Aby uzyskać więcej informacji na temat tego procesu i koncepcji bezpiecznego koncentratora wirtualnego, zobacz Azure Firewall Manager.

1. Utwórz zasady Azure Firewall.
2. Połącz zasady zapory z usługą Azure Virtual WAN Hub. Ten krok umożliwia działanie istniejącego centrum Virtual WAN jako zabezpieczonego koncentratora wirtualnego i wdrażanie wymaganych zasobów Azure Firewall.

Uwaga

Istnieją ograniczenia związane z używaniem 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 przedstawia 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 teraz kierują ruch do Azure Firewall.

• Azure Firewall mogą 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 Azure Firewall lub wysyłany do usługi zabezpieczeń innej firmy w celu przeprowadzenia inspekcji.

Ścieżka 8

Ścieżka 8 przedstawia 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 Azure Firewall lub wysyłany do usługi zabezpieczeń innej firmy w celu przeprowadzenia inspekcji.

Następne kroki

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