Azure VPN ゲートウェイのパブリック IP 変更とサブスクリプション移行

VPN ゲートウェイのパブリック IP を差し替え、サブスクリプション間で移すための手順。トンネルを維持する棚卸し、切り戻し、コンテキスト確認を含む。

Azure では三つの異なるオブジェクトが「ゲートウェイのアドレス」と呼ばれます。プライベートアドレスは GatewaySubnet から割り当てられます。パブリックアドレスは、ゲートウェイの IP 構成が指す別個のパブリック IP リソースです。サブスクリプションとクラウド環境は、シェルがどちらかを見つけるためのコンテキストです。一方を変えても残り二つはそのままなので、アドレスの作業はよく途中で止まります。

私はこの変更を四つの段階で進めます。オブジェクトの棚卸し、パブリック IP を既存ゲートウェイ上で移すかゲートウェイを作り直すかの判断、古いアドレスを手元に残したままの変更適用、そして何かを削除する前に両端から全トンネルを検証する段階です。飛ばされがちなのが棚卸しです。

実際に変えているのは三つのうちどれか

ポータルを開く前にオブジェクトを名指しします。VPN ゲートウェイのプライベートアドレスは、正確に GatewaySubnet という名前のサブネットから取られ、Azure がそのプレフィックスから割り当てます。固定するための汎用フィールドはありません。アドレスが安定して見えるのはサブネットが安定しているからだけです。サブネットを付け替えるかゲートウェイを作り直せば、それに従って動きます。

パブリックアドレスは編集できますが、編集が許されるかは SKU の規則が決めます。Basic ゲートウェイは Basic の動的パブリック IP と組み合わせ、VpnGw SKU は Standard の静的が必要で、ゾーン冗長ゲートウェイは同じゾーンを持つ Standard のパブリック IP を必要とします。誤った SKU はトンネルが落ちる前に拒否されます。

ObjectWhere it livesWhat a change forces
Private addressGatewaySubnet prefix, assigned at deploymentSubnet resize or rebuild, then routes, NSGs and peer review
Public addressPublic IP resource referenced by the IP configurationGateway reprovision, peer and allowlist edits, new client profiles
Subscription contextYour PowerShell or CLI sessionNothing in Azure, and it clears most not-found errors

何かが動く前の棚卸し

まずサブスクリプションを証明します。それがなければ残りの棚卸しは無意味です。ゲートウェイ、その IP 構成、そこで終端する全接続を記録し、出力を変更記録のそばに置きます。

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

リソース ID は名前より重要です。接続はゲートウェイとローカルネットワークゲートウェイへの参照を保持し、その ID は誰も覚えていないスクリプト、アラート、ポリシー割り当てに現れます。Azure の外にあるものも列挙します。アドレスに解決する DNS 名、パートナーの許可リスト、古い IP を固定する拠点ファイアウォールです。

稼働中のゲートウェイでパブリック IP を差し替える

まず置き換え用アドレスを、同じリージョンでゲートウェイに合うゾーン構成で作成し、古いリソースはそのまま残します。次に IP 構成を作り直し、一回の呼び出しで更新を送ります。この呼び出しは構成コレクション全体を置き換えるため、アクティブ-アクティブのゲートウェイは両方の構成が必要で、片方だけだとトンネルを一つ失います。

$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

ゲートウェイの再プロビジョニング中にトンネルは落ちます。対向側には段取りが必要です。パートナーのファイアウォールは誰かが編集するまで古いアドレスを提示し続け、前の IP を期待する接続は Azure がどれほど健全に見えても落ちたままです。作業時間の前に DNS の TTL を下げます。

ポイント対サイトのクライアントは新しいプロファイルが必要です。ダウンロードしたパッケージがエンドポイントを含むからです。ゲートウェイの前に独自の DNS 名を置けば再配布が不要になります。名前は保ち、レコードを変えます。

ゲートウェイを別のサブスクリプションへ移す

リソースの移動はひとまとまりを移し、ゲートウェイ単体はその中で最も役に立たない構成要素です。仮想ネットワーク、パブリック IP リソース、ローカルネットワークゲートウェイ、接続は互いに参照するため一緒に移動します。移行先のサブスクリプションは同じテナントにあり、Microsoft.Network が登録済みで、両側に書き込み権限が必要です。

検証は何かが変わる前に実行されるので、拒否された移動はリソースをそのまま残します。だからこそ作り直す前に移動を試す価値があります。成功すればパブリック IP も一緒に移るためピアと許可リストが機能し続けますが、作り直したゲートウェイは同じアドレスをほとんど返しません。

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

検証の失敗はやり直さずに読みます。よくある原因は取り残された依存関係、移動できないリソースの種類、どちらかのリソースグループのロックです。移動が不可能なら移行先で作り直して切り替えます。テストサブネットからルーティングと認証を確認し、古い接続は削除せず停止し、古い経路は次の作業時間に外します。

ゲートウェイが見当たらないときはコンテキストを確認する

「見つからない」エラーはたいていスコープの誤りです。複数のサブスクリプションを持つアカウントが cmdlet を誤った先に向け、メッセージはリソースのせいにします。代わりに完全なリソース ID でオブジェクトを探します。ID は自身のサブスクリプションを含むので、解決できれば何も欠けておらず、既定のコンテキストが誤っています。

さらに二つの不一致も同じように読めます。商用クラウドのゲートウェイは政府機関向けや中国の環境を向いたセッションには存在せず、古いモジュール版は API がすでに返すリソース形状を取りこぼします。サブスクリプションを固定し、環境を合わせ、それからケースを開きます。

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

片付けの前に両端から検証する

「接続済み」は状態であって証拠ではありません。接続ごとのトンネル状態、動的ルーティングなら BGP ピアの状態、ワークロードサブネットの有効なルートを確認します。そのうえでトンネルに依存するアプリケーションから実際のリクエストを一本通します。必要なプレフィックスがルートテーブルにないまま、接続が接続済みと報告することはあります。

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

古いパブリック IP は削除せず切り離したままフォールバックの期間が終わるまで残し、ピアとファイアウォールの編集は順に戻せるよう記録します。

  • コンテキストはゲートウェイを所有するサブスクリプションに固定
  • 古いパブリック IP を保持し、依存先を記録
  • すべての接続が緑で、実際のリクエストを一本通した
  • ポイント対サイトの利用者を更新済みプロファイルへ移行
  • DNS レコードを変更し、以前の値を記録

関連記事