Łączność hybrydowa: Połącz się lokalnie z Azure

Ten artykuł ułatwia wybranie i zaplanowanie odpowiedniej opcji łączności w celu połączenia sieci lokalnej z sieciami wirtualnymi Azure.

Co opisano w tym artykule

W tym artykule opisano decyzje projektowe dotyczące łączenia sieci lokalnych z sieciami wirtualnymi Azure przy użyciu Azure VPN Gateway lub Azure ExpressRoute. Dowiesz się, kiedy używać każdej opcji, jak współpracują ze sobą i jak planować wdrożenie bramy. Ogólny przegląd usług łączności hybrydowej można znaleźć w artykule Czym jest łączność hybrydowa?

Kto potrzebuje tego artykułu

Przeczytaj ten artykuł, jeśli ma zastosowanie co najmniej jeden z następujących warunków:

  • Obciążenia Azure muszą komunikować się z systemami lokalnymi, użytkownikami lub centrami danych.
  • Musisz wybrać między VPN Gateway i usługą ExpressRoute na podstawie przepustowości, opóźnienia, odporności lub kosztów.
  • Potrzebujesz prywatnej lub zaszyfrowanej ścieżki dla tożsamości, danych, zarządzania lub zależności aplikacji, które pozostają poza Azure.
  • Należy zaplanować topologię bramy sieciowej, nadmiarowość lub współistnienie sieci VPN i usługi ExpressRoute.

Tip

Podążasz ścieżką scenariusza? Wybierz swój scenariusz w górnej części strony, aby uzyskać dostosowane wskazówki. Poniższe podstawowe wskazówki dotyczą wszystkich czytelników.

Podejście lift-and-shift: Twoje zmigrowane obciążenia robocze muszą komunikować się z systemami lokalnymi. Łączność hybrydowa to najważniejszy element warunkujący migrację. Bez połączenia sieci VPN lub usługi ExpressRoute zmigrowane maszyny wirtualne w Azure nie mogą uzyskiwać dostępu do lokalnych baz danych, udziałów plików ani usług tożsamości, od których zależą aplikacje.

Fokus modernizacji: Zmodernizowane aplikacje mogą nadal potrzebować łączności lokalnej w okresie przejściowym. Podczas migrowania obciążeń do usług PaaS niektóre zależności pozostają w środowisku lokalnym do momentu ukończenia pełnej migracji. Zaplanuj łączność hybrydową jako most, który możesz stopniowo zmniejszać lub usuwać, eliminując zależności lokalne.

Komunikacja między chmurami: Potrzebujesz tuneli VPN IPsec między platformą Azure a AWS lub Google Cloud na potrzeby szyfrowanej komunikacji między chmurami. Aplikacje z zależnościami między chmurami wymagają bezpiecznych, niezawodnych ścieżek sieciowych między dostawcami chmury. Ten model łączności używa usługi Azure VPN Gateway do zakańczania tuneli z bram AWS Virtual Private Gateways i punktów końcowych Google Cloud VPN.

Usługi i funkcje platformy Azure

Azure oferuje kilka usług łączności hybrydowej. Każda usługa odpowiada różnym wymaganiom dotyczącymi przepustowości, opóźnień, kosztów i zabezpieczeń.

Service Co zapewnia Kiedy należy go używać
Azure VPN Gateway (site-to-site) Zaszyfrowany tunel IPsec/IKE za pośrednictwem publicznego Internetu. Łączy lokalne urządzenia sieci VPN z Azure. Mniejsze organizacje, środowiska deweloperskie/testowe, zapasowa ścieżka łączności lub scenariusze hybrydowe z ograniczonym budżetem.
Azure VPN Gateway (point-to-site) Pojedyncze połączenia klienta z siecią wirtualną Azure. Obsługuje protokoły OpenVPN, SSTP i IKEv2. Administratorzy zdalni lub deweloperzy, którzy potrzebują indywidualnego dostępu do zasobów Azure. Zobacz artykuł o dostępie zdalnym, aby uzyskać szczegółowe wskazówki dotyczące połączenia P2S.
Azure ExpressRoute Prywatne dedykowane połączenie za pośrednictwem dostawcy łączności. Ruch nie przechodzi przez publiczny Internet. Produkcyjne obciążenia hybrydowe, aplikacje wrażliwe na opóźnienia, duże transfery danych oraz wymagania dotyczące zgodności lub przepisów.
Usługa ExpressRoute z trybem failover sieci VPN ExpressRoute jako ścieżka podstawowa, a VPN Gateway jako zapasowa ścieżka przełączania awaryjnego. Wymagania dotyczące wysokiej dostępności, w których przestój usługi ExpressRoute nie jest tolerowany.
ExpressRoute Global Reach Łączy dwie lokalne lokalizacje przez szkielet Azure, korzystając z ich odpowiednich obwodów ExpressRoute. Sieci przedsiębiorstwa obejmujące wiele lokacji, które używają Azure jako sieci szkieletowej tranzytowej. Aby uzyskać szczegółowe informacje, zobacz artykuł dotyczący wielu chmur i wielu regionów .
ExpressRoute Direct Łączność dedykowana 10 Gb/s, 100 Gb/s lub 400 Gb/s bezpośrednio do krawędzi sieci Microsoft. Obsługuje szyfrowanie warstwy 2 protokołu MACsec. Wymagania dotyczące najwyższej przepustowości, wymagania dotyczące szyfrowania MACsec lub gdy trzeba pominąć obciążenie dostawcy łączności. Opcja 400 Gb/s jest dostępna w ograniczonych lokalizacjach i wymaga rejestracji.

Note

Sieć VPN typu „point-to-site” (P2S) zapewnia poszczególnym klientom dostęp, co nakłada się na zakres artykułu o dostępie zdalnym. Ten artykuł koncentruje się na P2S w ramach środowiska łączności hybrydowej. Aby uzyskać wskazówki dotyczące wdrażania P2S, integrację tożsamości i konfigurację klienta, zapoznaj się z artykułem dostęp zdalny dla deweloperów i administratorów.

Jak działa VPN Gateway

Azure VPN Gateway tworzy zaszyfrowany tunel IPsec/IKE między lokalnym urządzeniem sieci VPN i bramą sieci wirtualnej Azure. Poniżej opisano proces konfiguracji tunelu site-to-site (S2S):

  1. Aprowizacja bramy: Wdrażasz zasób VPN Gateway w podsieci GatewaySubnet centralnej sieci wirtualnej. Platforma Azure udostępnia dwa lub więcej wystąpień bramy (w zależności od SKU i konfiguracji aktywna-aktywna). Aprowizowanie trwa około 30–45 minut.
  2. Definicja bramy sieci lokalnej: W Azure utworzysz zasób bramy sieci lokalnej, który reprezentuje sieć lokalną. Ten zasób określa publiczny adres IP lokalnego urządzenia VPN oraz lokalne zakresy adresów, które platforma Azure powinna kierować przez tunel.
  3. Tworzenie zasobu połączenia: Utworzysz zasób połączenia, który łączy VPN Gateway z bramą sieci lokalnej. Należy określić klucz współużytkowany (klucz wstępny) i parametry protokołu IPsec/IKE dla tunelu.
  4. Faza 1 IKE (tryb główny): Brama Azure i urządzenie lokalne negocjują bezpieczny kanał. Wymieniają propozycje dotyczące algorytmów szyfrowania, algorytmów integralności, grup Diffie-Hellman i metod uwierzytelniania. Wynikiem jest skojarzenie bezpieczeństwa IKE (SA).
  5. Faza 2 IKE (Tryb Szybki): Korzystając z bezpiecznego kanału z fazy 1, obie strony negocjują parametry IPsec SA: algorytm szyfrowania, algorytm integralności oraz czas życia klucza. Ten proces ustanawia tunel IPsec.
  6. Przepływy ruchu: Po zakończeniu obu faz tunel jest aktywny. Ruch zgodny ze zdefiniowanymi zakresami adresów jest szyfrowany, hermetyzowany w pakietach IPsec ESP i wysyłany przez publiczny Internet do zdalnego punktu końcowego.

W przypadku konfiguracji aktywne-aktywne Azure aprowizuje dwa wystąpienia bramy, z których każdy ma własny publiczny adres IP. Urządzenie lokalne ustanawia tunele dla obu wystąpień, zapewniając automatyczne przejście w tryb failover, jeśli jedno wystąpienie stanie się niedostępne.

Jak działa usługa ExpressRoute

Azure ExpressRoute tworzy połączenie prywatne między siecią lokalną a Azure za pośrednictwem dostawcy łączności. W przeciwieństwie do sieci VPN ruch nigdy nie przechodzi przez publiczny Internet. Model łączności obejmuje trzy krawędzie sieci:

  • Urządzenie brzegowe klienta (CE): Twój router lokalny w Twoim centrum danych lub obiekcie kolokacyjnym. To urządzenie jest równorzędne z routerem brzegowym dostawcy przy użyciu protokołu BGP.
  • Krawędź dostawcy (PE): Router dostawcy łączności w lokalizacji meet-me (obiekt komunikacji równorzędnej). Dostawca ustanawia połączenie warstwy 2 lub 3 między Twoim CE a jego PE.
  • Microsoft edge (MSEE): routery Microsoft Enterprise Edge w zakładzie komunikacji równorzędnej. Dostawca łączy swoje urządzenie PE z urządzeniem MSEE, domykając prywatną ścieżkę do platformy Azure.

Podczas aprowizowania obwodu usługi ExpressRoute dostawca konfiguruje nadmiarowe połączenia między wszystkimi trzema krawędziami. Platforma Azure rozgłasza prefiksy adresowe sieci VNet do routera CE przy użyciu protokołu BGP, a urządzenie CE rozgłasza trasy z sieci lokalnej z powrotem do platformy Azure. Ta dwukierunkowa wymiana tras umożliwia przepływ ruchu przez ścieżkę prywatną.

ExpressRoute obsługuje dwa typy komunikacji równorzędnej:

  • Prywatna komunikacja równorzędna platformy Azure: Łączy z sieciami wirtualnymi platformy Azure (IaaS i PaaS z prywatnymi punktami końcowymi). Ten typ połączenia równorzędnego jest najczęstszy w przypadku łączności hybrydowej.
  • Komunikacja równorzędna firmy Microsoft: Łączy z usługami publicznymi Microsoft 365 i platformy Azure (takimi jak publiczne punkty końcowe usługi Azure Storage). Wymaga filtrów tras, aby wybrać określone prefiksy usługi.

Porównanie jednostek SKU usługi ExpressRoute

Funkcja Local Standard Premium
Lokalizacje peeringowe Jedna lub dwie wyznaczone lokalizacje metra Wszystkie lokalizacje punktów peeringowych w regionie geopolitycznym Wszystkie lokalizacje peeringowe na całym świecie
Połączenia VNet na obwód Zależy od SKU bramy 10 100
Prefiksy tras (komunikacja równorzędna firmy Microsoft) N/A 4,000 10,000
Łączność między regionami Tylko ten sam obszar metra Ten sam region geopolityczny Każdy region Azure na całym świecie
Obsługa usługi Global Reach No Yes Yes
Cennik transferu danych Nielimitowany transfer przychodzący i wychodzący (plan rozliczany według użycia); wliczone w plan nielimitowany Ruch przychodzący wolny; ruch wychodzący mierzony według strefy Ruch przychodzący wolny; ruch wychodzący mierzony według strefy
Najlepsze dla Obciążenia o wysokiej przepustowości działające w jednym regionie w pobliżu lokalizacji peeringowej Wiele lokacji w jednym regionie geopolitycznym Globalne przedsiębiorstwo z obciążeniami w wielu regionach Azure

Tip

Lokalny SKU oferuje znaczne oszczędności, ponieważ cena obwodu obejmuje zarówno transfer danych przychodzących, jak i wychodzących. Wybierz pozycję Lokalny, gdy region platformy Azure znajduje się w tej samej aglomeracji co lokalizacja komunikacji równorzędnej lub w jej pobliżu.

Porównanie wersji VPN Gateway

SKU Maksymalna liczba tuneli S2S Maksymalna liczba połączeń P2S Test porównawczy łącznej przepływności Nadmiarowość strefowa
VpnGw1 / VpnGw1AZ 30 250 650 Mb/s Tylko wariant AZ
VpnGw2 / VpnGw2AZ 30 500 1,0 Gb/s Tylko wariant AZ
VpnGw3 / VpnGw3AZ 30 1 000 2,0 Gb/s Tylko wariant AZ
VpnGw4 / VpnGw4AZ 100 5,000 5,0 Gb/s Tylko wariant AZ
VpnGw5 / VpnGw5AZ 100 10,000 10,0 Gb/s Tylko wariant AZ

Note

Testy porównawcze przepływności są agregowane we wszystkich tunelach i połączeniach. Rzeczywista przepływność zależy od wzorców ruchu, rozmiarów pakietów i liczby aktywnych tuneli. Zawsze wybieraj wariant AZ dla wdrożeń produkcyjnych, aby uzyskać dostępność strefowo nadmiarową.

Jak wybrać

Skorzystaj z poniższych tabel decyzyjnych, aby wybrać odpowiednią opcję łączności i określić, gdzie należy umieścić bramę.

VPN Gateway kontra ExpressRoute

Rozważenie Wybierz VPN Gateway Wybierz usługę ExpressRoute
Budżet Niższe koszty. Godzinowa opłata za bramę plus opłaty za transfer danych. Wyższe koszty. Opłata za obwód dostawcy, opłata za bramę i opłaty za transfer danych.
Wymagana przepustowość Do 10 Gb/s łącznej przepustowości (SKU VpnGw5). Przepustowość pojedynczego tunelu jest niższa. Maksymalnie 100 Gb/s na obwód. Usługa ExpressRoute Direct obsługuje maksymalnie 400 Gb/s.
Tolerancja opóźnienia Większe opóźnienie jest dopuszczalne. Ruch przechodzi przez publiczny Internet. Wymagane jest małe, przewidywalne opóźnienie. Ruch odbywa się prywatną ścieżką.
Umowa SLA dotycząca niezawodności Wyższa z konfiguracją bramy aktywne-aktywne. Wyższy dla obwodu i najwyższy przy użyciu wdrożenia bramy strefowo nadmiarowej (SKU AZ). Zobacz umowy SLA platformy Azure.
Prywatność i zgodność Ruch pozostaje szyfrowany, ale przechodzi przez publiczny internet. Ruch nigdy nie przechodzi przez publiczny Internet.
Szybkość implementacji Od godzin do dni. Konfigurowanie bramy trwa około 45 minut. Tygodnie do miesięcy. Zakup łącza operatora wymaga przygotowania infrastruktury fizycznej.
Istniejący obwód usługi ExpressRoute Użyj VPN Gateway jako ścieżki kopii zapasowej obok usługi ExpressRoute. Użyj jako podstawowej ścieżki łączności.

Diagram porównujący ścieżkę VPN site-to-site przez publiczny internet z prywatną ścieżką peeringową ExpressRoute, obie kończące się na hubie GatewaySubnet.

Gdzie mieszka brama?

Topology Lokalizacja bramki Uzasadnienie
Model piasty i szprych Brama w centralnej sieci wirtualnej Wszystkie obciążenia szprych kierują ruch lokalny przez koncentrator. Centralizuje zarządzanie łącznością. Zobacz artykuł o architekturze piasty i szprych.
Pojedyncze obciążenie (płaskie) Brama w sieci wirtualnej obciążenia Prostsza architektura dla autonomicznych obciążeń, które nie współużytkują łączności z innymi sieciami wirtualnymi.

Opcje odporności usługi ExpressRoute

Poniższa tabela zawiera podsumowanie sposobu zwiększania dostępności usługi ExpressRoute. Aby uzyskać informacje o aktualnych wartościach procentowych SLA, zobacz Umowy SLA platformy Azure.

Poziom odporności Konfiguracja SLA
Standard Pojedyncze łącze ExpressRoute z nadmiarowymi połączeniami krzyżowymi. Umowa SLA na poziomie obwodu
Brama nadmiarowa między strefami Wdroż bramę ExpressRoute za pomocą SKU AZ (ErGw1AZ, ErGw2AZ lub ErGw3AZ). Wystąpienia obejmują strefy dostępności. SLA na poziomie bramy
Maksimum Dwa obwody w różnych lokalizacjach peeringowych z bramami nadmiarowymi między strefami oraz automatycznym przełączaniem awaryjnym sieci VPN. Najwyższa dostępność złożona

Schemat pokazujący połączenia lokalne przez główną ścieżkę ExpressRoute oraz przerywaną ścieżkę VPN do bram huba i zapory.

Decyzja o wdrożeniu: Przykład rozmieszczenia bram

Załóżmy, że przedsiębiorstwo dysponuje siecią typu hub-and-spoke, która ma trzy sieci VNet typu spoke dla środowisk produkcyjnego, testowego i deweloperskiego. Obciążenia produkcyjne wymagają usługi ExpressRoute na potrzeby replikacji bazy danych o małych opóźnieniach, podczas gdy programowanie korzysta z VPN Gateway w celu zwiększenia wydajności kosztów.

Zalecane umieszczanie:

  1. Wdroż zarówno bramę ExpressRoute, jak i VPN Gateway w GatewaySubnet huba VNet (wymaga podsieci /26 do współistnienia).
  2. Połącz szprychy produkcyjne i stagingowe z centrum (hubem) za pomocą komunikacji równorzędnej sieci wirtualnych (VNet peering) z włączonym tranzytem bramy. Te szprychy używają ścieżki ExpressRoute do łączności ze środowiskiem lokalnym.
  3. Połącz sieć development typu spoke z hubem przy włączonej transmisji bramy. Skonfiguruj tablice tras, aby ruch deweloperski w pierwszej kolejności korzystał z tunelu VPN, zmniejszając koszty przesyłu danych w usłudze ExpressRoute.
  4. Skonfiguruj połączenie sieci VPN jako ścieżkę przełączania awaryjnego na potrzeby środowiska produkcyjnego, jeśli po stronie dostawcy wystąpi awaria obwodu ExpressRoute.

To podejście centralizuje zarządzanie bramami w jednym centralnym węźle, minimalizuje liczbę potrzebnych zasobów bram i przypisuje każdy segment podrzędny do odpowiedniego poziomu łączności zgodnie z wymaganiami danego obciążenia.

Zagadnienia dotyczące kosztów

VPN Gateway i ExpressRoute mają różne modele cenowe. Zrozumienie tych modeli ułatwia optymalizowanie wydatków.

Składnik kosztu brama VPN ExpressRoute
Godzinowa opłata za bramę Opłata naliczana za godzinę zależnie od jednostki SKU (VpnGw1 jest najtańszą opcją) Opłata naliczana za godzinę w zależności od jednostki SKU bramy (ErGw1AZ jest najtańsza)
Opłata za łącze/połączenie Brak opłaty za łącze; tylko brama sieciowa i transfer danych Miesięczna opłata za port zapłacona Microsoft oraz opłaty dostawcy za obwód fizyczny
Transfer danych: przychodzący Bezpłatna Bezpłatna
Transfer danych: wychodzący Opłata naliczana za każdy GB przy standardowych stawkach za ruch wychodzący w usłudze Azure Plan taryfowy: opłata za GB. Plan bez ograniczeń: stawka miesięczna zryczałtowana. Lokalna jednostka SKU: uwzględniona
Opłaty za dostawcę Brak (korzysta z publicznego Internetu) Miesięczna opłata dla dostawcy połączenia dla portu i połączenia krzyżowego
Typowy zakres miesięczny $140–$2,500 (tylko brama; transfer danych różni się) $500–$15,000+ (bramka + łącze + dostawca; zależy od przepustowości i SKU)

Porady dotyczące optymalizacji kosztów:

  • Użyj lokalnego SKU dla usługi ExpressRoute, gdy obciążenia znajdują się w tym samym obszarze metropolitalnym co lokalizacja peeringu. Ten wybór eliminuje opłaty za transfer danych wychodzących.
  • Wybierz plan taryfowy dla usługi ExpressRoute, jeśli transfer danych wychodzących jest mniejszy niż około 10 TB/miesiąc. Użyj planu bez limitu do obciążeń o większej skali.
  • Wdróż VPN Gateway na potrzeby przełączania awaryjnego zamiast drugiego łącza ExpressRoute, jeśli masz ograniczony budżet, ale nadal potrzebujesz redundancji.
  • Dopasuj odpowiednio jednostkę SKU usługi VPN Gateway. Zacznij od VpnGw2AZ dla większości obciążeń produkcyjnych i zwiększaj skalę tylko wtedy, gdy zauważysz stałe wysycenie przepustowości.
  • Sprawdzaj wykorzystanie bramy co miesiąc. Metryki usługi Azure Monitor pokazują przepustowość tunelu i liczbę połączeń, pomagając identyfikować nadmiernie aprowizowane bramy.

Uwagi dotyczące projektowania

W przypadku migracji metodą „lift-and-shift” brama sieci VPN w centralnej sieci wirtualnej jest zazwyczaj pierwszym zasobem łączności, który się wdraża:

  • Brama sieci VPN w centralnej sieci wirtualnej VNet. Wdroż VPN Gateway w hubieGatewaySubnet. Wszystkie obciążenia w sieciach szprychowych uzyskują dostęp do zasobów lokalnych przez tranzyt bramy. Sieć VPN typu site-to-site jest zazwyczaj pierwszym wyborem, ponieważ można ją wdrożyć w ciągu kilku godzin, zamiast czekać tygodniami na udostępnienie obwodu ExpressRoute.
  • Ustalanie rozmiaru przepustowości na podstawie wymagań aplikacji. Zbierz wymagania dotyczące przepustowości z każdego migrującego obciążenia. Zsumuj wymagania dotyczące szczytowej współbieżnej przepływności i wybierz jednostkę SKU VPN Gateway, która obsługuje agregację. Zacznij od VpnGw2AZ dla większości obciążeń produkcyjnych. Jeśli agregacja przekracza 1 Gb/s, oceń usługę ExpressRoute lub wyższą warstwę VPN Gateway.
  • Zaplanuj usługę ExpressRoute jako kontynuację. Wiele organizacji rozpoczyna się od sieci VPN podczas początkowych fal migracji, a następnie dodaje usługę ExpressRoute dla obciążeń produkcyjnych, które wymagają przewidywalnego opóźnienia lub większej przepustowości. Hub GatewaySubnet obsługuje oba typy bram jednocześnie.

W przypadku zmodernizowanych architektur z wdrożeniami w wielu regionach planowanie strefowo nadmiarowych bram w obu regionach:

  • Strefowo nadmiarowe bramy sieci VPN w obu regionach. Wdróż VPN Gateway przy użyciu jednostki SKU AZ (VpnGw2AZ lub nowszej) zarówno w centrum podstawowym, jak i w regionie kopii zapasowej. Wdrożenie nadmiarowe między strefami rozmieszcza wystąpienia bramy w strefach dostępności, zapewniając wyższy poziom SLA dostępności dla komponentu bramy. Aby sprawdzić konkretne wartości procentowe w umowie SLA, zobacz Umowy dotyczące poziomu usług na platformie Azure.
  • Zdolność na wypadek awarii jednego regionu. Dobierz rozmiar każdej bramy regionalnej tak, aby mogła niezależnie obsłużyć pełne obciążenie ruchem. W przypadku awarii jednego regionu cały ruch hybrydowy jest kierowany przez bramę pozostałego regionu. Nie przydzielaj zbyt małych zasobów bramie regionu zapasowego.
  • Planowanie przejścia. Łączność hybrydowa w scenariuszu modernizacji jest często tymczasowa. Ponieważ usługi PaaS zastępują zależności od zasobów lokalnych, można zmniejszyć przepustowość bram lub całkowicie je usunąć, gdy wszystkie obciążenia robocze działają natywnie w chmurze.

W przypadku łączności między chmurami VPN Gateway ustanawia szyfrowane tunele dla innych dostawców usług w chmurze:

  • Połączenia sieci VPN z wirtualną bramą prywatną platformy AWS. Utwórz połączenia sieci VPN typu lokacja-lokacja z Azure VPN Gateway do wirtualnych bram prywatnych platformy AWS. Skonfiguruj protokół BGP na potrzeby dynamicznej wymiany tras między sieciami wirtualnymi Azure i wirtualnymi sieciami VPN platformy AWS. Każdy tunel VPN platformy AWS obsługuje maksymalnie 1,25 Gb/s (limit po stronie platformy AWS); użyj wielu tuneli lub ECMP w celu uzyskania wyższej zagregowanej przepływności.
  • Połączenia VPN do Google Cloud VPN. Utwórz połączenia sieci VPN typu lokacja-lokacja z Azure VPN Gateway do sieci VPN w chmurze Firmy Google (HA VPN). Google Cloud HA VPN zapewnia dwa punkty końcowe tunelu w celu zapewnienia nadmiarowości. Skonfiguruj peering BGP w celu automatycznej propagacji tras między platformami Azure i Google Cloud.
  • Wdróż w Virtual WAN lub w centrum. Jeśli wybrano usługę Virtual WAN jako model tranzytowy, wdróż połączenia VPN z koncentratora Virtual WAN, a nie z samodzielnej bramy VPN. Jeśli wybrałeś tradycyjny hub ze szprychami, wdroż go w hubie GatewaySubnet. Oba podejścia obsługują te same tunele IPsec/IKE do AWS i Google Cloud.

Prerequisites

Przed wdrożeniem łączności hybrydowej upewnij się, że obowiązują następujące wymagania:

  • GatewaySubnet Sieć wirtualna musi zawierać dedykowaną podsieć o nazwie o minimalnym rozmiarze /27 (lub /26, jeśli planujesz jednocześnie korzystać z bram ExpressRoute i VPN). Aby uzyskać wskazówki dotyczące planowania sieci wirtualnej i podsieci, zobacz artykuł Sieci wirtualne i podsieci.
  • Lokalne urządzenie sieci VPN (dla VPN Gateway): zgodne urządzenie sieci VPN obsługujące protokół IKEv2 i IPsec. Microsoft utrzymuje listę zweryfikowanych urządzeń sieci VPN.
  • Relacja dostawcy łączności (dla usługi ExpressRoute): Kontrakt z dostawcą łączności usługi ExpressRoute lub alokacją portów usługi ExpressRoute Direct. Aprowizowanie dostawcy wymaga wymiany kluczy usługi i konfiguracji fizycznego połączenia krzyżowego.
  • Planowanie adresów IP: Nie nakładające się przestrzenie adresowe między sieciami lokalnymi i Azure. Zaplanuj adresację podsieci bramy w ramach ogólnej strategii adresacji IP. Zobacz artykuł dotyczący planowania adresów IP.
  • Wsparcie dla protokołu Border Gateway (BGP): ExpressRoute wymaga BGP i jest zalecany do dynamicznego routowania VPN Gateway. Upewnij się, że sprzęt lokalny obsługuje protokół BGP.

Zagadnienia dotyczące zabezpieczeń

Łączność hybrydowa wprowadza granice zabezpieczeń, które wymagają starannego planowania. Każdy typ łączności ma różne profile zagrożeń i strategie ograniczania ryzyka.

Ruch usługi ExpressRoute nie jest domyślnie szyfrowany

ExpressRoute zapewnia ścieżkę prywatną, ale domyślnie nie szyfruje ruchu na warstwie sieciowej. Brak szyfrowania oznacza, że teoretycznie każdy mający fizyczny dostęp do infrastruktury dostawcy mógłby przechwytywać ruch. Rozważ następujące opcje szyfrowania na podstawie profilu ryzyka:

  • MACsec (warstwa 2): Dostępne tylko w usłudze ExpressRoute Direct. Szyfruje ruch na fizycznym łączu między routerami brzegowymi a infrastrukturą brzegową firmy Microsoft. Musisz wyraźnie włączyć MACsec po przydzieleniu portu. Ta opcja zapewnia szyfrowanie z szybkością łącza przy minimalnym narzucie opóźnień.
  • Protokół IPsec za pośrednictwem usługi ExpressRoute (warstwa 3): Uruchom tunel VPN za pośrednictwem połączenia prywatnej komunikacji równorzędnej usługi ExpressRoute w celu kompleksowego szyfrowania. Takie podejście działa z dowolnym obwodem usługi ExpressRoute i szyfruje ruch zarówno w sieci dostawcy, jak i w sieci szkieletowej Microsoft. SKU VPN Gateway ogranicza przepustowość.
  • Szyfrowanie warstwy aplikacji: Użyj protokołu TLS/HTTPS na poziomie aplikacji. Takie podejście jest niezależne od typu łączności i chroni dane niezależnie od bazowego transportu. Jest to najbardziej typowe i zalecane minimalne szyfrowanie dla wszystkich obciążeń hybrydowych.

W przypadku większości organizacji połączenie ścieżki prywatnej usługi ExpressRoute i protokołu TLS warstwy aplikacji zapewnia wystarczającą ochronę. Dodaj protokół MACsec lub IPsec za pośrednictwem usługi ExpressRoute tylko wtedy, gdy wymagania prawne nakazują szyfrowanie warstwy sieciowej dla danych przesyłanych.

Asymetryczny routing zakłóca działanie zapór stanowych

W przypadku korzystania z wielu ścieżek łączności, takich jak usługa ExpressRoute i sieć VPN, ruch może podążać za różnymi ścieżkami ruchu przychodzącego i wychodzącego. Stanowe zapory usuwają ruch powrotny, który dociera do innego interfejsu niż oryginalne żądanie. Zaplanuj routing, aby zapewnić ścieżki symetryczne lub użyć tabel tras i atrybutów protokołu BGP do sterowania przepływem ruchu.

Strategie ograniczania ryzyka obejmują:

  • Ustaw w protokole BGP poprzedzanie ścieżki AS na ścieżce zapasowej, aby była mniej preferowana.
  • Użyj tabel tras (UDR) w podsieciach, aby wymusić kierowanie ruchu przez określoną bramę.
  • Skonfiguruj społeczności protokołu BGP i preferencje lokalne , aby wpływać na wybór trasy deterministycznie.
  • Przetestuj scenariusze przełączania awaryjnego, aby sprawdzić, czy ruch wraca tą samą trasą, którą dotarł.

Przestroga dotycząca NSG dla GatewaySubnet

Caution

Nie należy stosować sieciowych grup zabezpieczeń do podsieci GatewaySubnet, chyba że w pełni zrozumiesz wpływ. Błędnie skonfigurowane reguły sieciowej grupy zabezpieczeń w podsieci GatewaySubnet mogą spowodować przerwanie całej łączności hybrydowej. Brama wymaga określonej komunikacji w płaszczyźnie sterowania, którą reguły NSG mogą nieumyślnie blokować.

Jeśli musisz zastosować sieciowe grupy zabezpieczeń do podsieci GatewaySubnet, zezwól co najmniej na ruch z tagu usługi GatewayManager oraz z tagu usługi AzureLoadBalancer. Zapoznaj się z dokumentacją bramy, aby uzyskać pełną listę wymaganych reguł przed wprowadzeniem zmian.

Szyfrowanie VPN typu site-to-site

IKEv2/IPsec zawsze szyfruje ruch VPN site-to-site podczas transportu. Algorytmy szyfrowania i długości kluczy konfiguruje się w zasadach protokołu IPsec/IKE dla połączenia. Użyj zasad niestandardowych, aby wymusić określone algorytmy kryptograficzne, a nie polegać na wartościach domyślnych.

Zalecane niestandardowe ustawienia zasad dla obciążeń produkcyjnych:

  • Faza 1 IKE: szyfrowanie AES-256, integralność SHA-256, grupa DH 14 lub nowsza
  • Faza 2 IKE (IPsec): szyfrowanie AES-256-GCM, grupa PFS 14 lub nowsza
  • Domyślny okres istnienia skojarzenia zabezpieczeń: 28 800 sekund (IKE), 3600 sekund (IPsec)

Unikaj używania przestarzałych algorytmów (DES, 3DES, MD5, SHA-1, DH Group 1/2), mimo że Azure nadal obsługuje je w celu zapewnienia zgodności z poprzednimi wersjami.

Uwierzytelnianie sieci VPN typu punkt-lokacja

Sieć VPN P2S obsługuje uwierzytelnianie Microsoft Entra ID z integracją uwierzytelniania wieloskładnikowego (MFA). Ta opcja zapewnia kontrolę dostępu opartą na tożsamościach dla poszczególnych klientów łączących się z Azure. P2S VPN obsługuje również uwierzytelnianie oparte na certyfikatach oraz RADIUS.

Wybierz metodę uwierzytelniania na podstawie wymagań:

Metoda Najlepsze dla Stan zabezpieczeń
Microsoft Entra ID Organizacje, które już korzystają z Microsoft Entra ID i Dostęp warunkowy usługi Microsoft Entra Najsilniejszy: obsługuje uwierzytelnianie wieloskładnikowe, zgodność urządzeń i zasady oparte na ryzyku
Oparte na certyfikatach Środowiska bez Microsoft Entra ID lub połączeń maszynowo-maszynowych Silne: wymaga infrastruktury PKI i zarządzania cyklem życia certyfikatów
PROMIEŃ Integracja z istniejącymi lokalnymi systemami tożsamości (NPS, innej firmy) Różni się: zależy od konfiguracji serwera RADIUS i uwierzytelniania zaplecza

Learn more

Następne kroki

Tip

Eksplorowanie na własną rękę? Wróć do nawigatora przeglądu , aby znaleźć następny artykuł według możliwości.

Kolejny etap w procesie migracji typu lift-and-shift:

Skonfiguruj bezpieczny dostęp administracyjny do swoich maszyn wirtualnych: wdroż Azure Bastion w centralnej sieci wirtualnej, aby administratorzy mogli łączyć się z migrowanymi maszynami wirtualnymi przez RDP/SSH bez konieczności przypisywania publicznych adresów IP.

Kolejny etap procesu modernizacji:

Zaprojektuj wzorce ruchu przychodzącego z Internetu: określ, jak ruch od klientów dociera do punktów końcowych Front Door, Traffic Manager i Application Gateway.

Kolejny krok w Twojej wielochmurowej podróży:

Zaplanuj przełączenie DNS i rozwiązywanie nazw: zinwentaryzuj istniejące rekordy DNS, obniż wartości TTL i skonfiguruj usługę Prywatna strefa DNS Resolver na potrzeby rozwiązywania nazw między chmurami.

  • Last updated on