Informationen zum Migrieren einer öffentlichen Basic-SKU-IP-Adresse zu einer Standard-SKU-IP-Adresse

In diesem Artikel wird der Migrationsprozess von einer öffentlichen Standard-SKU-IP-Adresse zu einer öffentlichen Standard-SKU-IP-Adresse für VPN Gateway Bereitstellungen erläutert. Je nach der aktuellen VPN Gateway SKU-Konfiguration Ihres Gateways gibt es separate Migrationszeitpläne.

Von Bedeutung

Informationen zu den vorgesehenen Migrationszeitleisten finden Sie im Artikel VPN Gateway – Neuigkeiten.

Überlegungen zur Migration

Um Ihr Gateway zu migrieren, müssen Sie zuerst überprüfen, ob Ihre Ressource in der Lage ist, zu migrieren. Im Folgenden finden Sie einige häufige Situationen, die Sie beachten müssen:

  • Für VPN Gateway Basic Gateway SKU:

  • Für VPN-Gateway-SKUs VpnGw1-5 und Legacy-SKUs (High-Performance SKU und Standard SKU):

    • Bevor Sie die Migration für Ihr VPN-Gateway initiieren, stellen Sie sicher, dass Ihr Gatewaysubnetz mindestens drei verfügbare IP-Adressen im aktuellen Präfix aufweist.

    • Beim Konfigurieren eines dritten VIP im Active-Active-Modus für Point-to-Site (P2S) muss eine nicht zonale öffentliche IP verwendet werden.

    • Das Migrationstool erfordert, dass das Gatewaysubnetz mindestens einen /27-Adressraum hat. Wenn ihr Gatewaysubnetz derzeit /28 oder kleiner ist, schlägt die Migration fehl und gibt einen Fehler zurück. Erweitern Sie vor dem Starten der Migration das Gatewaysubnetz auf /27 oder höher. Informationen zum Hinzufügen mehrerer Präfixe für ein Subnetz finden Sie unter Hinzufügen mehrerer Präfixe für subnetz.

    • Wenn ExpressRoute und VPN koexistieren: Es wird empfohlen, zuerst die Grundlegenden IP-Ressourcen zu Standard-IP auf VPN zu migrieren.

Häufig gestellte Fragen

Je nach ihrer aktuellen VPN-Gateway-SKU haben Sie möglicherweise unterschiedliche Fragen zum Migrationsprozess. Hier sind einige häufig gestellte Fragen, die Ihnen helfen, die Migration besser zu verstehen.

VPN-Gateway-SKUs VpnGw1-5

Wie lange dauert die End-to-End-Migration in der Regel?

Je nach Größe und Konfiguration Ihrer Bereitstellung dauert der gesamte Migrationsprozess in der Regel bis zu 2 Stunden.

Wie lange dauert jeder Migrationsschritt?

Die Dauer von Migrationsschritten kann je nach Komplexität der Umgebung variieren. Durchschnittlich:

  • Vorbereiten: Normalerweise bis zu 40 Minuten mit maximal 1 Stunde.
  • Ausführung: Dauert etwa 5 bis 10 Minuten. (Dies ist der einzige Schritt, in dem kurze Ausfallzeiten erwartet werden.)
  • Commit: In der Regel bis zu 30 Minuten, mit maximal 1 Stunde.

Wie lange kann ich warten, bevor ich meine Migrationsänderungen begehen kann?

Die Migrationsüberprüfung ist in der Regel innerhalb eines kurzen Zeitrahmens abgeschlossen. Kunden werden empfohlen, die Überprüfung abzuschließen und Migrationsänderungen innerhalb weniger Tage zu übernehmen, da das Verlassen von Migrationen, die für längere Zeiträume ausstehen, nicht empfohlen wird. Die tatsächliche Dauer variiert je nach Umgebungs- und Validierungsanforderungen.

Wie wird meine Gateway-SKU nach der Migration der öffentlichen IP-Adresse der Basic-SKU betroffen sein?

Nachdem Sie ein Upgrade von einer öffentlichen IP-Adresse der Basic SKU auf eine öffentliche IP-Adresse der Standard SKU durchgeführt haben, wird Ihr VPN-Gateway-SKU VPNGW1-5 zu VPNGW1AZ-5 migriert. Daher wird möglicherweise die SKU von einer Nicht-VZ zu einer VZ-SKU geändert. Weitere Informationen zu SKU-Auswirkungen finden Sie im Artikel zur Gateway-SKU-Migration .

Ändert sich die IP-Adresse meines VPN-Gateways, nachdem meine öffentliche IP-Adresse migriert wurde?

  • Wenn Sie die Microsoft bereitgestellte Migrationsumgebung verwenden, ändert sich Ihre Gateway-IP-Adresse nicht.
  • Wenn Sie Ihr aktuelles VPN-Gateway, das über eine öffentliche Standard-SKU-IP-Adresse verfügt, manuell löschen und ein neues VPN-Gateway mit einer öffentlichen Standard-SKU-IP-Adresse erstellen, ändert sich Ihre Gateway-IP-Adresse.

Gibt es Ausfallzeiten?

Bis zu 10 Minuten Ausfallzeiten werden während der Microsoft bereitgestellten Migrationserfahrung erwartet.

Muss ich Maßnahmen ergreifen, um zu migrieren?

Die Microsoft bereitgestellte Migrationserfahrung ist eine vom Kunden initiierte Migration. Sie müssen den Migrationsprozess initiieren. Der Migrationsprozess wird voraussichtlich bis zu 10 Minuten dauern.

Gibt es Migrationsvoraussetzungen?

Stellen Sie sicher, dass Ihr Gatewaysubnetz über den richtigen IP-Adressraum und die Subnetzgröße verfügt. Sie benötigen mindestens drei verfügbare IP-Adressen in Ihrem aktuellen Präfix, bevor Sie die Migration durchführen.

Kann ich manuell zu einer öffentlichen Standard-SKU-IP-Adresse wechseln?

Ja, das können Sie. Wenn Sie sich dafür entscheiden, dies manuell zu tun, müssen Sie das alte Gateway löschen und dann ein neues Gateway in Ihrem virtuellen Netzwerk erstellen. Wenn Sie ein neues Gateway erstellen, verwendet Ihr Gateway automatisch eine öffentliche Standard-SKU-IP-Adresse. Wenn Sie sich jedoch dafür entscheiden, diesen Prozess zu verwenden, entstehen Ausfallzeiten, während das alte Gateway gelöscht wird und das neue Gateway erstellt wird.

Wenn ich mein Gateway lösche und neu erstelle, ändert sich meine IP-Adresse?

Ja, die IP-Adresse ändert sich mit diesem Ansatz. Dies bedeutet, dass Sie sicherstellen müssen, dass die neue IP-Adresse bei Bedarf in allen internen Tools aktualisiert wird.

Wirkt sich die Migration des VPN-Gateways auf ExpressRoute-Datenverkehr in einer vorhandenen Einrichtung aus?

No. Wenn Sie der empfohlenen Migrationsreihenfolge folgen, beeinträchtigt die Migration des VPN Gateways zuerst nicht den ExpressRoute-Datenverkehr. Die ExpressRoute-Konnektivität bleibt während der VPN-Gatewaymigration nicht betroffen. Kunden sollten beim ersten Migrieren des VPN-Gateways keine ExpressRoute-Konnektivitätsprobleme erwarten.

Kann ich den DDoS-Schutz während der Gatewaymigration aktivieren?

No. Während sich das Gateway in der Migration befindet (zwischen Execute und Commit), nehmen Sie keine Änderungen an der öffentlichen IP, dem Gateway oder den Verbindungen vor. Das Aktivieren des DDoS-Schutzes oder anderer erweiterter Features während dieser Phase kann die Migration blockieren oder ein Rollback verhindern. Aktivieren Sie diese Features erst, nachdem die Migration vollständig abgeschlossen ist (nach Commit).

Kann ich meine IP-, VPN Gateway-, Subnetz- oder Verbindungen während der Migration ändern?

No. Solange sich das VPN-Gateway in der Migration befindet (zwischen Execute und Commit), dürfen Sie an den folgenden Punkten keine Änderungen vornehmen:

Öffentliche IP-Adresse VPN Gateway-Konfiguration Gatewaysubnetz-Verbindungen

Änderungen während dieser Phase können das Gateway in einen nicht unterstützten oder hängenden Zustand versetzen, da der Migrationsworkflow keine gleichzeitigen Updates verarbeitet.

Was geschieht, wenn ich während der Migration Änderungen vorfüge und das Gateway hängen bleibt?

Wenn das Gateway aufgrund von Änderungen, die während der Migration vorgenommen wurden, in einen hängen gebliebenen oder nicht wiederherstellbaren Migrationsstatus wechselt:

Das System kann die Migration möglicherweise nicht abschließen oder zurücksetzen. In solchen Fällen kann die einzige Wiederherstellungsoption darin bestehen, das Gateway zu löschen und neu zu erstellen.

Active-Active VpnGw1-5 Gateway SKUs

Warum erfordert mein Active-Active-VPN Gateway mit Point-to-Site (P2S) eine dritte öffentliche IP?

Für Active-Active VPN-Gateways mit aktiviertem P2S ist eine dritte öffentliche IP erforderlich, um den P2S-Endpunkt zusammen mit den beiden für Active-Active-Instanzen verwendeten IPs zu unterstützen.

Die Dokumentation besagt, dass die dritte öffentliche IP nicht zonal sein muss. Ist dies noch erforderlich?

Ja.
Für dieses Szenario muss die dritte öffentliche IP-Adresse ohne Zonen (nicht zonengebunden) konfiguriert werden, um die Kompatibilität mit der VPN-Gateway-Konfiguration und zukünftigen Updatevorgängen sicherzustellen.

Wann sollte ich die dritte öffentliche IP während der Migration erstellen?

Die dritte öffentliche IP muss erstellt und an das VPN-Gateway angefügt werden bevor die Migration gestartet wird (Basic → Standard IP).

Dadurch wird Folgendes sichergestellt:

  • Die Gatewaykonfiguration ist vor der Migration abgeschlossen.
  • Der Migrationsprozess wird ohne Überprüfungs- oder Aktualisierungsprobleme fortgesetzt.

Wie erstelle ich die erforderliche nicht zonengebundene öffentliche IP-Adresse?

In Regionen, in denen zonenredundante IPs die Standardeinstellung sind, sollten Sie die dritte öffentliche IP-Adresse mithilfe von Azure CLI oder PowerShell oder mit der REST-API in Version 2020-08-01 oder höher erstellen, die eine nicht zonale / No-Zone Public IP festlegt, und dabei sicherstellen, dass keine Verfügbarkeitszonen angegeben werden.

Dadurch kann die öffentliche IP in einer nicht zonalen Konfiguration erstellt werden, die für dieses Szenario erforderlich ist.

Kann ich eine zonenredundante öffentliche IP anstelle einer nicht zonalen IP für die dritte P2S-IP verwenden?

No.

Alle öffentlichen IPs, die einem VPN Gateway zugeordnet sind, müssen eine consistent-Konfiguration verwenden. Die Verwendung einer zonenredundanten öffentlichen IP für die dritte IP kann zu Bereitstellungs- oder Updatefehlern führen.

Wirkt sich dieses Verhalten auf alle VPN Gateway Migrationen aus?

No.

Diese Anforderung gilt speziell für:

  • VPN Gateways vom Typ „Aktiv/Aktiv“
  • Mit aktivierter Punkt-zu-Standort-Funktion (P2S)

Wie verhält sich die Migration für ein Active-Active VPN-Gateway mit einer grundlegenden öffentlichen IP? Verursacht er einen vollständigen Gatewayausfall?

No. Während der Migration von einer grundlegenden öffentlichen IP zu einer öffentlichen Standard-IP wird das VPN-Gateway als Einheit umgestellt und stellt die Konnektivität im Rahmen des Migrationsprozesses wieder her. Die Migration verschebt keinen Datenverkehr von einer Gatewayinstanz in eine andere Instanz und führt nicht zu einem vollständigen Gatewayausfall. Kurze Verbindungsunterbrechungen können während der Migration auftreten, da Verbindungen erneut hergestellt werden, das Gateway jedoch nicht vollständig offline genommen wird.

Treten während der Migration nur bei den Tunneln auf einer bestimmten Gatewayinstanz Unterbrechungen auf, während die andere Instanz aktiv bleibt?

No. VPN-Tunnel werden als Teil des Migrationsprozesses wiederhergestellt, aber sie werden nicht pro jeweiliger Instanz migriert oder übernommen. Tunnel sollten aufgrund einzelner Gateway-Instanzen, die migriert werden, nicht fluktuieren, und die Migration ist nicht auf bestimmte Instanzen innerhalb eines Active-Active-Gateways ausgerichtet.

Wie sollten Ausfallzeiten für die Migration von Active-Active VPN-Gateways beschrieben werden?

Die Migration ist ein störender Vorgang und kann zu kurzen Verbindungsunterbrechungen führen, während die VPN-Gatewaykonfiguration aktualisiert wird und Verbindungen neu eingerichtet werden. Diese Unterbrechungen sind in der Regel mehrere Minuten in der Dauer und in den meisten Fällen innerhalb von ca. 10 Minuten abgeschlossen, obwohl genaue Zeitangaben nicht garantiert sind und je nach Konfiguration und Netzwerkbedingungen variieren können. Kunden sollten planen, die Migration während eines Wartungsfensters durchzuführen und sicherzustellen, dass Anwendungen stabil für kurze Verbindungsunterbrechungen sind.

Ich sehe die Änderung der BGP-Peer-IP-Adresse nach der Migration. Muss ich meine BGP-Peer-IP-Adressen aktualisieren, nachdem ich eine aktiv aktive VPN Gateway zu Standard-IP migriert habe?

No. Obwohl das Azure Portal nach der Migration neue BGP-Peer-IP-Adressen anzeigt, funktionieren vorhandene lokale BGP-Konfigurationen weiterhin ohne Änderungen. Azure leitet automatisch Datenverkehr von den ursprünglichen BGP-Peer-IP-Adressen an die BGP-Peer-IP-Adressen weiter, wobei Konnektivität und BGP-Sitzungen erhalten bleiben.

Vom Kunden erstellte Routen und Lastenausgleichsgeräte während der VPN-Gatewaymigration

Muss ich vor der Migration eine benutzerdefinierte Netzwerkkonfiguration überprüfen?

Ja. Überprüfen Sie alle vom Kunden erstellten Routingtabellen (UDRs), Load Balancer, Firewalls oder NVAs, die möglicherweise auf die privaten IP-Adressen der VPN Gateway-Instanzen (Gateway CAs) verweisen. Und die Weitergabe von BGP-Routen wird vor der Migration aktiviert. Wenn Ihre Umgebung VNet-Peering verwendet, stellen Sie sicher, dass Synchronisierungs-VNet-Peering während der Migration aktiviert ist.

Wann sollte ich diese Konfigurationen aktualisieren?

Aktualisieren Sie nach dem Ausführungsschritt alle vom Kunden erstellten Routen, Lastenausgleichs-, Firewallregeln oder NVA-Konfigurationen, die auf die alten Gatewayinstanz-IPs verweisen.

VPN-Gateway – Basis-SKU

Kann ich ein Basic SKU-VPN-Gateway mit einer Basic SKU-öffentlichen IP-Adresse erstellen?

Nein, Sie können kein Basic SKU VPN-Gateway mit einer Basic SKU öffentlichen IP-Adresse erstellen. Für neue einfache SKU-VPN-Gateways ist eine Standard-SKU für öffentliche IP-Adressen erforderlich.

Muss ich migrieren, wenn ich über ein Basic-SKU-VPN-Gateway verfüge?

Basic SKU VPN-Gateways, die aktuell eine öffentliche IP-Adresse von Basic SKU verwenden, nutzen nicht den Migrationsprozess, um auf eine öffentliche IP-Adresse von Standard SKU umzustellen. Die einzige Maßnahme, die Sie ergreifen müssen, ist, den Verweis auf die öffentliche IP-Adresse der Basic SKU von Ihrem Gateway zu entfernen.

Schritte zum Entfernen der öffentlichen STANDARD-SKU-IP-Referenz finden Sie unter Entfernen der öffentlichen STANDARD-SKU-IP-Referenz von einem einfachen SKU-VPN-Gateway. Ihr Gateway verwendet weiterhin dieselbe öffentliche IP-Adresse. Nur der Verweis auf die öffentliche SKU-Standard-IP-Ressource wird von Ihrem Gateway entfernt.

Back-End-Migration

Wann führt Microsoft die Back-End-Migration meines VPN-Gateways aus?

Ab August 2026 migriert Microsoft automatisch berechtigte VPN-Gateways, die noch nicht über Self-Service migriert wurden. Da dieser Vorgang Microsoft verwaltet wird, erhalten Sie keine Benachrichtigung über die Migration pro Gateway, bevor die Migration erfolgt. Microsoft führt die Migration während außerhalb der Geschäftszeiten basierend auf der regionalen Ortszeit des Gateways aus, um die Auswirkungen der Kunden zu minimieren.

Ändert sich die öffentliche IP-Adresse meines VPN-Gateways während der Migration?

No. Die Migration führt bei der öffentlichen IP-Ressource ein Upgrade von der Basic-SKU auf die Standard-SKU durch, die vorhandene öffentliche IP-Adresse wird jedoch beibehalten. Sie müssen keine Maßnahmen für das öffentliche IP-Upgrade ergreifen.

Führt die Migration zu Ausfallzeiten oder Verkehrsunterbrechungen?

Ja. Die Migration verursacht eine kurze Verbindungsunterbrechung von bis zu 10 Minuten, während das Gateway zur neuen Back-End-Infrastruktur wechselt. Bestimmte Gatewaykonfigurationen, z. B. benutzerdefinierte Datenverkehrsselektoren, Active-Active P2S, CloudApp-basierte P2S, RemoteRADIus und andere identifizierte Edgefälle, erfordern möglicherweise eine Kundenaktion und können Auswirkungen auf die Konnektivität haben, wenn sie vorher nicht behoben werden.

Muss ich vor der Back-End-Migration Maßnahmen ergreifen?

Ja. Schließen Sie die Self-Service-Migration (vom Kunden ausgelöst) ab, bevor die Back-End-Migration beginnt. Mit diesem Prozess können Sie Ihre spezifischen Datenverkehrsmuster, Anwendungen und Netzwerktopologie überprüfen, die Microsoft in Ihrem Auftrag nicht vollständig testen können. Wenn Sie die Self-Service-Migration nicht durchführen, werden Microsoft während der Back-End-Migration möglicherweise automatisch berechtigte Gateways migrieren. Diese Migration kann nicht rückgängig gemacht werden. Microsoft können auch Schreitests auf einigen Gateways durchführen. Gateways, die als inaktiv festgelegt wurden, können als Teil des Einstellungsprozesses gelöscht werden. Überprüfen und beheben Sie darüber hinaus alle bekannten betroffenen Konfigurationen, z. B. benutzerdefinierte Datenverkehrsauswahlen, Active-Active P2S, CloudApp-basierte P2S und RemoteRADIUS, vor der Migration, um potenzielle Konnektivitätsprobleme zu vermeiden.

Was geschieht, wenn ich die Migration bis zum 30. Juni 2026 nicht abgeschlossen habe?

Die vom Kunden initiierte Migration endete am 30. Juni 2026. Es wurde erwartet, dass Sie die Migration bis zu diesem Datum abgeschlossen haben. Wenn Sie nach dem 30. Juni 2026 auf der Legacy-Plattform verbleiben, deckt die VPN Gateway Dienst-SLA Sie nicht mehr ab, bis die Migration abgeschlossen ist. Erweiterungsanforderungen bis zum 31. Juli 2026 werden automatisch genehmigt und erfordern keine individuelle Überprüfung. Ab August 2026 plant Microsoft, die verbleibenden infrage kommenden VPN-Gateways zu migrieren, die noch nicht migriert wurden. Microsoft führen Back-End-Migrationen in außerhalb der Geschäftszeiten regional aus, und sie können zu einer kurzen Verbindungsunterbrechung führen, die der vom Kunden initiierten Migrationserfahrung ähnelt.

Nächste Schritte

  • Last updated on