Öffentliche IP des Azure-VPN-Gateways wechseln und Abonnement umziehen

In Azure tragen drei verschiedene Objekte den Namen Gateway-Adresse. Die private Adresse wird aus GatewaySubnet vergeben. Die öffentliche Adresse ist eine eigene öffentliche IP-Ressource, auf die die IP-Konfiguration des Gateways zeigt. Abonnement und Cloudumgebung sind der Kontext, mit dem Ihre Shell das eine oder das andere findet. Ändern Sie eines, bleiben die beiden anderen, wo sie waren — deshalb bleibt Adressarbeit so oft auf halbem Weg stehen.

Ich führe diese Änderungen in vier Stufen aus: Objekte inventarisieren, entscheiden, ob die öffentliche IP am bestehenden Gateway wandert oder das Gateway neu aufgebaut wird, die Änderung anwenden, solange die alte Adresse noch in Reichweite ist, und dann jeden Tunnel von beiden Enden prüfen, bevor etwas gelöscht wird. Die Stufe, die man überspringt, ist das Inventar.

Welches der drei Objekte Sie wirklich ändern

Benennen Sie das Objekt, bevor Sie das Portal öffnen. Ein VPN-Gateway bezieht seine private Adresse aus einem Subnetz, das exakt GatewaySubnet heißen muss, und Azure weist sie aus diesem Präfix zu; ein allgemeines Feld zum Festnageln gibt es nicht. Die Adresse wirkt nur stabil, weil das Subnetz stabil ist. Adressieren Sie das Subnetz neu oder bauen Sie das Gateway neu auf, wandert sie mit.

Die öffentliche Adresse ist editierbar, aber SKU-Regeln entscheiden, ob die Änderung zulässig ist. Ein Basic-Gateway passt zu einer dynamischen öffentlichen Basic-IP, VpnGw-SKUs brauchen eine statische Standard-IP, und ein zonenredundantes Gateway braucht eine öffentliche Standard-IP mit denselben Zonen. Die falsche SKU wird abgelehnt, bevor ein Tunnel fällt.

Inventar, bevor sich etwas bewegt

Beweisen Sie zuerst das Abonnement, denn ohne es ist der Rest des Inventars wertlos. Erfassen Sie das Gateway, seine IP-Konfigurationen und jede Verbindung, die darauf endet, und legen Sie die Ausgabe neben den Änderungsdatensatz.

Get-AzContext | Select-Object Subscription, Tenant, Environment
Get-AzVirtualNetworkGateway -ResourceGroupName rg-hub -Name gw-hub |
  Select-Object Name, Sku, EnableActiveActive, IpConfigurations
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName rg-hub |
  Select-Object Name, ConnectionStatus, ConnectionType

Ressourcen-IDs zählen mehr als Namen. Eine Verbindung hält Verweise auf das Gateway und auf ein lokales Netzwerkgateway, und diese IDs tauchen in Skripten, Alarmen und Richtlinienzuweisungen auf, an die sich niemand erinnert. Listen Sie auch auf, was außerhalb von Azure liegt: den DNS-Namen, der auf die Adresse zeigt, die Freigabeliste des Partners, die Filialfirewall, die die alte IP festhält.

Die öffentliche IP am laufenden Gateway tauschen

Erstellen Sie zuerst die Ersatzadresse, in derselben Region und mit dem Zonensatz, der zum Gateway passt, und lassen Sie die alte Ressource stehen. Bauen Sie dann die IP-Konfiguration neu auf und schieben Sie die Aktualisierung in einem Aufruf. Dieser Aufruf ersetzt die gesamte Konfigurationssammlung, also braucht ein aktiv-aktiv Gateway beide, sonst behalten Sie einen Tunnel und verlieren den anderen.

$gw = Get-AzVirtualNetworkGateway -ResourceGroupName rg-hub -Name gw-hub
$pip = New-AzPublicIpAddress -Name pip-gw-hub-2 -ResourceGroupName rg-hub `
  -Location westeurope -AllocationMethod Static -Sku Standard
$conf = New-AzVirtualNetworkGatewayIpConfig -Name gwipconfig1 `
  -SubnetId $gw.IpConfigurations[0].Subnet.Id -PublicIpAddressId $pip.Id
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -IpConfigurations $conf

Tunnel fallen, während das Gateway neu bereitgestellt wird. Die Gegenseite braucht die Planung: eine Partnerfirewall bietet die alte Adresse weiter an, bis jemand sie bearbeitet, und eine Verbindung, deren Gegenseite die vorige IP erwartet, bleibt unten, so gesund Azure auch aussieht. Senken Sie die DNS-TTL vor dem Fenster.

Point-to-Site-Clients brauchen ein neues Profil, weil das heruntergeladene Paket den Endpunkt trägt. Ein eigener DNS-Name vor dem Gateway erspart Ihnen die Neuverteilung: Namen behalten, Eintrag ändern.

Das Gateway in ein anderes Abonnement verschieben

Ein Ressourcenumzug verschiebt ein Set, und das Gateway allein ist dessen am wenigsten nützliches Mitglied. Virtuelles Netzwerk, öffentliche IP-Ressourcen, lokale Netzwerkgateways und Verbindungen reisen zusammen, weil jedes auf ein anderes verweist. Das Zielabonnement muss im selben Mandanten liegen, Microsoft.Network muss dort registriert sein, und Sie brauchen Schreibzugriff auf beiden Seiten.

Die Validierung läuft, bevor sich etwas ändert, ein abgelehnter Umzug lässt die Ressourcen also stehen. Deshalb verdient der Umzug einen Versuch vor einem Neuaufbau: ein erfolgreicher Umzug nimmt die öffentliche IP mit, Peers und Freigabelisten arbeiten weiter, während ein neu aufgebautes Gateway selten dieselbe Adresse zurückgibt.

az resource move --destination-group rg-hub `
  --destination-subscription-id 00000000-0000-0000-0000-000000000000 `
  --ids /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworkGateways/gw-hub

Lesen Sie einen Validierungsfehler, statt ihn zu wiederholen. Die üblichen Ursachen sind eine zurückgelassene Abhängigkeit, ein Ressourcentyp, der nicht umziehen kann, oder eine Sperre auf einer der Ressourcengruppen. Ist der Umzug unmöglich, bauen Sie im Ziel neu auf und schalten um: Routing und Authentifizierung aus einem Testsubnetz bestätigen, alte Verbindungen stoppen statt löschen, dann den alten Pfad in einem späteren Fenster entfernen.

Wenn das Gateway zu fehlen scheint, prüfen Sie den Kontext

Der Nicht-gefunden-Fehler ist meist ein Bereichsfehler. Ein Konto mit mehreren Abonnements richtet ein Cmdlet auf das falsche, und die Meldung beschuldigt die Ressource. Suchen Sie das Objekt stattdessen über seine vollständige Ressourcen-ID: die ID trägt ihr eigenes Abonnement, löst sie auf, fehlt nichts und Ihr Standardkontext ist falsch.

Zwei weitere Abweichungen lesen sich gleich. Ein kommerzielles Cloud-Gateway existiert nicht in einer Sitzung, die auf eine Behörden- oder China-Umgebung zielt, und ältere Modulversionen übersehen Ressourcenformen, die die API bereits liefert. Abonnement festnageln, Umgebung angleichen, dann einen Fall eröffnen.

Set-AzContext -SubscriptionId 11111111-1111-1111-1111-111111111111
Get-AzResource -ResourceId /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworkGateways/gw-hub

Von beiden Enden prüfen, bevor aufgeräumt wird

Verbunden ist ein Zustand, kein Beweis. Prüfen Sie den Tunnelstatus je Verbindung, den BGP-Peer-Status bei dynamischem Routing und die effektiven Routen in einem Workload-Subnetz. Schicken Sie dann eine echte Anfrage durch eine Anwendung, die vom Tunnel abhängt. Eine Verbindung kann verbunden melden, während das benötigte Präfix in der Routentabelle fehlt.

Get-AzVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName gw-hub -ResourceGroupName rg-hub
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-app -ResourceGroupName rg-app

Halten Sie die alte öffentliche IP getrennt statt gelöscht, bis das Rückfallfenster schließt, und schreiben Sie Peer- und Firewall-Änderungen auf, damit sie in Reihenfolge rückgängig gemacht werden können.

• Kontext auf das Abonnement festgelegt, dem das Gateway gehört
• Alte öffentliche IP behalten, ihre Abhängigkeiten notiert
• Jede Verbindung grün plus eine echte Anfrage hindurch
• Point-to-Site-Nutzer auf das erneuerte Profil umgestellt
• DNS-Eintrag geändert und sein vorheriger Wert festgehalten