Informacje o migrowaniu publicznego adresu IP z SKU Podstawowego do SKU Standardowego

W tym artykule wyjaśniono proces migracji z publicznego adresu IP jednostki SKU w warstwie Podstawowa do publicznego adresu IP jednostki SKU w warstwie Standardowa dla wdrożeń VPN Gateway. Istnieją oddzielne osie czasu migracji, w zależności od jednostki SKU VPN Gateway, która jest obecnie skonfigurowana do użycia przez bramę.

Ważne

Aby zapoznać się z przewidywanymi harmonogramami migracji, zobacz VPN Gateway — Co nowego.

Zagadnienia dotyczące migracji

Aby przeprowadzić migrację bramy, najpierw należy sprawdzić, czy zasób jest w stanie przeprowadzić migrację. Oto kilka typowych sytuacji, o których należy pamiętać:

  • Dla wariantu SKU bramy podstawowej VPN Gateway:

    • Jeśli brama sieci VPN o jednostce SKU Podstawowa ma odniesienie do publicznego adresu IP jednostki SKU Podstawowa, nie używasz procesu migracji. Musisz usunąć tylko referencję do publicznego adresu IP SKU Basic z Twojej bramy.
    • Aby uzyskać instrukcje dotyczące usuwania odniesienia do publicznego adresu IP Basic SKU, zobacz Jak usunąć odniesienie do publicznego adresu IP Basic SKU z bramy VPN Basic SKU.

  • W przypadku jednostek SKU bramy VPN o SKU VpnGw1-5 oraz starszych jednostek SKU (SKU High-Performance i SKU Standard):

    • Przed zainicjowaniem migracji dla bramy sieci VPN sprawdź, czy podsieć bramy ma co najmniej trzy dostępne adresy IP w bieżącym prefiksie.

    • Podczas konfigurowania trzeciego adresu VIP w trybie Aktywny-aktywny dla połączenia punkt-lokacja (P2S) należy użyć innego niż strefowy publiczny adres IP.

    • Narzędzie migracji wymaga, aby podsieć bramy miała co najmniej przestrzeń adresową /27. Jeśli podsieć bramy jest obecnie /28 lub mniejsza, migracja kończy się niepowodzeniem i zwraca błąd. Przed rozpoczęciem migracji rozwiń podsieć bramy do /27 lub większej. Aby dodać wiele prefiksów dla podsieci, zobacz dodawanie wielu prefiksów dla podsieci.

    • Jeśli masz współistniejącą usługę ExpressRoute i sieć VPN: zalecamy najpierw przeprowadzenie migracji podstawowych zasobów IP do standardowego adresu IP w sieci VPN .

Często zadawane pytania

W zależności od bieżącej jednostki SKU usługi VPN Gateway mogą występować różne pytania dotyczące procesu migracji. Poniżej przedstawiono kilka często zadawanych pytań, które pomogą Ci lepiej zrozumieć migrację.

Jednostki SKU bramy sieci VPNGw1-5

Jak długo zwykle trwa kompleksowa migracja?

Cały proces migracji zwykle trwa do 2 godzin, w zależności od rozmiaru i konfiguracji wdrożenia.

Jak długo trwa każdy krok migracji?

Czasy trwania kroku migracji mogą się różnić w zależności od złożoności środowiska. Średnio:

  • Przygotowanie: Zazwyczaj do 40 minut, maksymalnie 1 godzina.
  • Wykonanie: trwa około 5–10 minut. (Jest to jedyny krok, w którym oczekiwano krótkiego przestoju).
  • Zatwierdzanie: zazwyczaj do 30 minut, maksymalnie 1 godzina.

Jak długo mogę poczekać przed zatwierdzeniem zmian migracji?

Walidacja migracji jest zwykle zakończona w krótkim przedziale czasu. Klienci powinni ukończyć walidację i zatwierdzić zmiany związane z migracją w ciągu kilku dni, ponieważ pozostawienie migracji oczekujących na dłuższe okresy nie jest rekomendowane. Rzeczywisty czas trwania różni się w zależności od potrzeb środowiska i walidacji.

Jaki będzie wpływ migracji publicznego adresu IP dla SKU Podstawowa na moją jednostkę SKU bramki?

Po uaktualnieniu z publicznego adresu IP SKU Podstawowa do publicznego adresu IP SKU Standardowa, Twoja jednostka SKU bramy VPN VPNGW1-5 zostanie zmigrowana do VPNGW1AZ-5. W rezultacie możesz zauważyć, że jednostka SKU zmieniła się z typu nie-AZ na typ AZ-SKU. Aby uzyskać więcej informacji na temat wpływu jednostki SKU, zobacz artykuł Migracja jednostki SKU bramy .

Czy mój adres IP bramy sieci VPN zmieni się po migracji mojego publicznego adresu IP?

  • Jeśli używasz środowiska migracji dostarczonego przez Microsoft, adres IP bramy nie ulegnie zmianie.
  • Jeśli ręcznie usuniesz bieżącą bramę sieci VPN z publicznym adresem IP jednostki SKU w warstwie Podstawowa i utworzysz nową bramę sieci VPN przy użyciu publicznego adresu IP jednostki SKU w warstwie Standardowa, zmieni się adres IP bramy.

Czy wystąpi jakiś przestój?

Podczas środowiska migracji zapewnianego przez Microsoft oczekuje się do 10 minut przestoju.

Czy muszę wykonać jakiekolwiek działania w celu przeprowadzenia migracji?

Środowisko migracji zapewniane Microsoft to migracja zainicjowana przez klienta. Należy zainicjować proces migracji. Proces migracji powinien potrwać do 10 minut.

Czy istnieją jakieś wymagania wstępne dotyczące migracji?

Upewnij się, że podsieć bramy ma odpowiednią przestrzeń adresową IP oraz właściwy rozmiar podsieci. Przed przeprowadzeniem migracji potrzebne będą co najmniej trzy dostępne adresy IP w bieżącym prefiksie.

Czy mogę ręcznie zmienić publiczny adres IP SKU Standard?

Tak, możesz. Jeśli zdecydujesz się to zrobić ręcznie, musisz usunąć starą bramę, a następnie utworzyć nową bramę w sieci wirtualnej. Podczas tworzenia nowej bramy będzie ona automatycznie używać publicznego adresu IP w klasie Standard. Jeśli jednak zdecydujesz się użyć tego procesu, nastąpi przestój podczas usuwania starej bramy i utworzenia nowej bramy.

Czy w przypadku usunięcia i ponownego utworzenia bramy mój adres IP ulegnie zmianie?

Tak, adres IP zmienia się przy użyciu tego podejścia. Oznacza to, że w razie potrzeby należy upewnić się, że nowy adres IP zostanie zaktualizowany we wszystkich narzędziach wewnętrznych.

Czy migracja bramy sieci VPN wpłynie na ruch usługi ExpressRoute w współistniejącej konfiguracji?

No. Przy wykonywaniu zalecanej kolejności migracji, przeprowadzenie migracji bramy sieciowej VPN (VPN gateway) jako pierwszego kroku nie powoduje przemieszczania, zakłócenia ani wpływu na ruch usługi ExpressRoute. Łączność usługi ExpressRoute pozostaje nienaruszona podczas migracji bramy sieci VPN. Klienci nie powinni oczekiwać problemów z łącznością usługi ExpressRoute podczas pierwszej migracji bramy sieci VPN.

Czy mogę włączyć ochronę przed atakami DDoS podczas migracji bramy?

No. Podczas migracji bramy (między wykonaniem i zatwierdzeniem) nie wprowadzaj żadnych zmian w publicznym adresie IP, bramie lub połączeniach. Włączenie ochrony przed atakami DDoS lub innych zaawansowanych funkcji w tej fazie może blokować migrację lub zapobiegać wycofywaniu. Włącz takie funkcje dopiero po zakończeniu migracji (po zatwierdzeniu).

Czy mogę zmodyfikować mój adres IP, VPN Gateway, podsieć lub połączenia podczas migracji?

No. Podczas gdy VPN Gateway jest w trakcie migracji (między wykonaniem i zatwierdzeniem), nie można wprowadzać żadnych zmian w następujących kwestiach:

Publiczny adres IP Konfiguracja bramy sieci VPN Podsieć bramy Połączenia

Wprowadzanie zmian w tej fazie może umieścić bramę w nieobsługiwanym lub zablokowanym stanie, ponieważ przepływ pracy migracji nie obsługuje współbieżnych aktualizacji.

Co się stanie, jeśli wprowadzim zmiany podczas migracji, a brama zostanie zablokowana?

Jeśli brama wejdzie w stan zawieszenia lub nieodwracalny stan migracji z powodu zmian wprowadzonych podczas migracji:

System może nie być w stanie ukończyć lub wycofać migracji. W takich przypadkach jedyną opcją odzyskiwania może być usunięcie i ponowne utworzenie bramy.

Jednostki SKU bramek Active-Active VpnGw1-5

Dlaczego moja brama sieci VPN Active‑Active z połączeniem typu punkt-lokacja (P2S) wymaga trzeciego publicznego adresu IP?

W przypadku bram sieci VPN Active-Active z włączonymi połączeniami typu punkt-lokacja (P2S) wymagany jest trzeci publiczny adres IP do obsługi punktu końcowego połączeń P2S, oprócz dwóch adresów IP używanych przez wystąpienia Active-Active.

Dokumentacja twierdzi, że trzeci publiczny adres IP musi być inny niż strefowy. Czy jest to nadal wymagane?

Tak.
W tym scenariuszu trzeci publiczny adres IP musi być skonfigurowany bez stref (non-zonal), aby zapewnić zgodność z konfiguracją bramy VPN i przyszłymi operacjami aktualizacji.

Kiedy należy utworzyć trzeci publiczny adres IP podczas migracji?

Trzeci publiczny adres IP należy utworzyć i dołączyć do VPN Gateway w przypadku rozpoczęcia migracji (podstawowy adres IP → Standard).

Zapewnia to:

  • Konfiguracja bramy została ukończona przed migracją
  • Proces migracji przebiega bez problemów z walidacją lub aktualizacją

Jak utworzyć wymagany niestrefowy publiczny adres IP?

W regionach, w których adresy IP strefowo nadmiarowe są domyślne, należy utworzyć trzeci publiczny adres IP za pomocą Azure CLI lub programu PowerShell interfejs API rest w wersji 2020-08-01 lub nowszej, który ustawia publiczny adres IP inny niż strefowy/bez strefy, zapewniając, że no określono strefy dostępności.

Dzięki temu publiczny adres IP można utworzyć w konfiguracji innej niż strefowa, która jest wymagana w tym scenariuszu.

Czy mogę użyć nadmiarowego strefowo publicznego adresu IP zamiast niestrefowego adresu IP dla trzeciego adresu IP P2S?

No.

Wszystkie publiczne adresy IP skojarzone z VPN Gateway muszą używać konfiguracji consistent. Użycie strefowo nadmiarowego publicznego adresu IP dla trzeciego adresu IP może spowodować niepowodzenie wdrożenia lub aktualizacji.

Czy to zachowanie ma wpływ na wszystkie migracje VPN Gateway?

No.

To wymaganie dotyczy w szczególności:

  • Bramy sieci VPN Active-Active
  • Z włączonym połączeniem punkt-lokacja (P2S)

Jak działa migracja bramy VPN Active-Active przy użyciu podstawowego publicznego adresu IP? Czy powoduje to pełną awarię bramy?

No. Podczas migracji z podstawowego publicznego adresu IP do standardowego publicznego adresu IP brama sieci VPN zostanie przeniesiona jako jednostka i ponownie ustanawia łączność w ramach procesu migracji. Migracja nie przenosi ruchu z jednej instancji bramy do innej instancji i nie powoduje całkowitej awarii bramy. Krótkie przerwy w łączności mogą wystąpić podczas migracji, ponieważ połączenia są odnawiane, ale brama nie jest całkowicie przełączona w tryb offline.

Czy podczas migracji przerwy dotyczą tylko tuneli w konkretnym wystąpieniu bramy, podczas gdy inne wystąpienie pozostaje aktywne?

No. Oczekuje się, że tunele sieci VPN zostaną ponownie ustanowione w ramach procesu migracji, ale nie są one migrowane ani przełączane w tryb awaryjny indywidualnie dla każdej instancji. Tunele nie powinny flapować z powodu migrowania poszczególnych wystąpień bramy, a migracja nie jest ograniczona do określonych wystąpień w bramie Aktywne-aktywne.

Jak należy opisać przestój w przypadku migracji bramy sieci VPN Active-Active?

Migracja jest operacją destrukcyjną i może spowodować krótkie przerwy w łączności podczas aktualizowania konfiguracji bramy sieci VPN i ponownego nawiązywania połączeń. Te przerwy zwykle trwają kilka minut i w większości przypadków kończą się w ciągu około 10 minut, chociaż nie można zagwarantować dokładnych czasów i mogą się różnić w zależności od konfiguracji i warunków sieciowych. Klienci powinni zaplanować przeprowadzenie migracji w oknie obsługi i zapewnić odporność aplikacji na krótkie przerwy w łączności.

Widzę zmianę adresu IP sąsiada BGP po migracji. Czy muszę zaktualizować adresy IP peerów BGP po migracji bramy VPN w trybie aktywny-aktywny na standardowy adres IP?

No. Mimo że portal Azure wyświetla nowe adresy IP elementu równorzędnego BGP po migracji, istniejące lokalne konfiguracje protokołu BGP nadal działają bez zmian. Azure automatycznie przekierowuje ruch z pierwotnych adresów IP partnera BGP na adresy IP partnera BGP, zachowując łączność i sesje protokołu BGP.

Trasy utworzone przez klienta i moduły równoważenia obciążenia podczas migracji bramy VPN

Czy muszę przejrzeć konfigurację sieci niestandardowej przed migracją?

Tak. Przejrzyj wszelkie tabele tras utworzone przez klienta (UDR), moduły równoważenia obciążenia, zapory lub wirtualne urządzenia sieciowe (NVA), które mogą odwoływać się do prywatnych adresów IP wystąpień usługi VPN Gateway (CA bramy). Propagacja tras protokołu BGP jest włączana przed migracją. Jeśli środowisko korzysta z peeringu sieci wirtualnych, upewnij się, że podczas migracji włączono opcję Sync VNet Peering.

Kiedy należy zaktualizować te konfiguracje?

Po wykonaniu kroku Execute zaktualizuj wszystkie trasy utworzone przez klienta, moduły równoważenia obciążenia, reguły zapory sieciowej lub konfiguracje NVA, które odwołują się do starych adresów IP instancji bramy.

Podstawowa jednostka SKU usługi VPN Gateway

Czy mogę utworzyć bramę VPN z SKU Basic oraz publicznym adresem IP SKU Basic?

Nie, nie można utworzyć bramy sieci VPN podstawowej jednostki SKU z publicznym adresem IP jednostki SKU w warstwie Podstawowa. Nowe bramy VPN w warstwie Podstawowa SKU wymagają Standardowa SKU publicznego adresu IP.

Czy muszę przeprowadzić migrację, jeśli mam bramę sieci VPN w podstawowej wersji SKU?

Podstawowe bramy sieci VPN jednostki SKU, które obecnie używają podstawowego publicznego adresu IP SKU nie korzystają z procesu migracji do jednostki SKU adresu IP publicznego w warstwie Standardowej. Jedyną czynnością, którą musisz wykonać, jest usunięcie z bramy odniesienia do publicznego adresu IP z Basic SKU.

Aby uzyskać instrukcje dotyczące usuwania odniesienia do publicznego adresu IP Basic SKU, zobacz Jak usunąć odniesienie do publicznego adresu IP Basic SKU z bramy VPN Basic SKU. Brama nadal używa tego samego publicznego adresu IP. Tylko odwołanie do zasobu publicznego IP typu Basic SKU jest usuwane z Twojej bramy.

Migracja zaplecza

Kiedy Microsoft przeprowadzi migrację zaplecza mojej bramy sieci VPN?

Począwszy od sierpnia 2026 r., Microsoft automatycznie migruje kwalifikujące się bramy sieci VPN, które nie zostały jeszcze zmigrowane za pośrednictwem samoobsługi. Ponieważ ta operacja jest zarządzana przez firmę Microsoft, nie otrzymasz oddzielnego powiadomienia o migracji dla każdej bramy przed jej przeprowadzeniem. Microsoft przeprowadza migrację poza godzinami pracy, zgodnie z regionalnym czasem lokalnym bramy, aby zminimalizować wpływ na klientów.

Czy podczas migracji zmieni się publiczny adres IP bramy sieci VPN?

No. Migracja aktualizuje zasób publicznego adresu IP z warstwy Basic SKU do Standard SKU, ale istniejący publiczny adres IP zostaje zachowany. Nie musisz podejmować żadnych działań dotyczących uaktualnienia publicznego adresu IP.

Czy migracja spowoduje przestój lub zakłócenia ruchu?

Tak. Migracja powoduje krótką przerwę w połączeniu, trwającą do 10 minut, podczas gdy brama przełącza się na nową infrastrukturę backendową. Jednak niektóre konfiguracje bramy, takie jak niestandardowe selektory ruchu, Active-Active P2S, P2S oparte na usłudze CloudApp, zdalny serwer RADIUS i inne zidentyfikowane szczególne przypadki graniczne, mogą wymagać działań ze strony klienta i mogą powodować zakłócenia łączności, jeśli nie zostaną wcześniej usunięte.

Czy muszę wykonać jakiekolwiek działania przed migracją zaplecza?

Tak. Przed rozpoczęciem migracji zaplecza ukończ migrację samoobsługową (wyzwalaną przez klienta). Ten proces pomaga zweryfikować określone wzorce ruchu, aplikacje i topologię sieci, która Microsoft nie może w pełni przetestować w Twoim imieniu. Jeśli nie przeprowadzisz migracji samoobsługowej, firma Microsoft może automatycznie przeprowadzić migrację bram spełniających wymagania w trakcie migracji po stronie zaplecza. Ta migracja nie jest odwracalna. Microsoft mogą również wykonywać testy krzyków na niektórych bramach. Bramy uznane za nieaktywne mogą zostać usunięte w ramach procesu wycofywania. Ponadto przed migracją należy przejrzeć i skorygować wszystkie znane konfiguracje, takie jak selektory ruchu niestandardowego, Active-Active P2S, P2S oparte na usłudze CloudApp i zdalny protokół RADIUS, aby uniknąć potencjalnych problemów z łącznością.

Co się stanie, jeśli nie ukończym migracji do 30 czerwca 2026 r.?

Migracja zainicjowana przez klienta została zakończona 30 czerwca 2026 r. Oczekiwano ukończenia migracji do tej daty. Jeśli pozostaniesz na starszej platformie po 30 czerwca 2026 r., umowa SLA usługi VPN Gateway nie obejmuje cię do czasu zakończenia migracji. Żądania rozszerzeń do 31 lipca 2026 r. są automatycznie zatwierdzane i nie wymagają indywidualnego przeglądu. Od sierpnia 2026 r. Microsoft planuje zmigrować pozostałe kwalifikujące się do migracji bramy sieci VPN, które nie zostały jeszcze zmigrowane. Microsoft przeprowadza migracje systemów zaplecza w poszczególnych regionach po godzinach pracy i mogą one powodować krótkotrwałą przerwę w łączności, podobną do tej występującej podczas migracji inicjowanej przez klienta.

Następne kroki

  • Last updated on