Azure VPN VM でパブリック IP が二つあるとき: どちらが何を担うか

Azure VPN VM 一台にパブリック IP を二つ持たせると、ほとんど成り立たない期待が生まれる。クライアントが接続するアドレスが、Web サイトから見えるアドレスにもなる、という期待である。この結果は三つの独立した決定から生まれ、トンネルのリスナーに関わるのは最初の一つだけだ。二つ目は転送されたクライアント通信に使うゲスト側の送信元で、三つ目はその送信元に適用される Azure の送信方法である。一つを変えても残り二つはそのままなので、それぞれを明示的に決める必要がある。

決定 1: トンネルはどこで終わるか

Azure のパブリック IP は NIC 上のプライベート IP 構成に紐づく。ゲスト OS の中で追加するアドレスではない。推測せずに対応関係を読むこと: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'。このクエリが返すプライベートアドレスこそ、ゲストが実際に持つべきアドレスだ。

NIC 一つが複数の IP 構成を持てるため、パブリックアドレスが二つあっても NIC は二つ要らない。設計が本当に NIC を二つ使うなら、それぞれが独自のゲストルートとネクストホップを持ち、単純化ではなくルーティングの決定を一つ増やしたことになる。

明示的なローカルバインドを持つサービスでは、実際のゲスト側プライベートアドレスにバインドし、パブリックのプレースホルダーには決してバインドしない。すべてのアドレスを受け付けるリスナーは、到達するすべての IP 構成から通信を受けるので、バインド順に任せず、ネットワークセキュリティグループとホストのファイアウォールで入口を制限する。

決定 2: 転送されたクライアントはどの送信元を使うか

ゲートウェイがクライアントのリクエストを復号したあと、転送するパケットは VPN リスナーに届いたパケットとは別物だ。ゲストには転送の有効化、通信を許可するファイアウォールポリシー、そしてクラウド設計が許す送信元アドレスが必要になる。クライアントの内側アドレスを変換するなら、Azure が評価するのはその変換後の送信元であり、クライアントの内側アドレスではない。

狭い SNAT ルールはゲスト側プライベートの送信元を選べるが、後段の Azure 変換を覆すことはできない。VM の内側でクライアントごとの説明責任が必要なら SNAT を選ぶ。サブネットの送信設計がすでに安定したパブリック送信元を提供し、二度目の変換が状態を増やすだけなら省く。

決定 3: どの Azure 送信方法が優先されるか

Microsoft は送信の優先順位を文書化している。アプライアンスやゲートウェイへの該当ルートが優先され、該当する経路ではサブネットの NAT Gateway 接続がインスタンスレベルのパブリック IP より優先される。この順序があるため、10.20.0.5 に変換しても、Web サイトが 198.51.100.20 を見る証明にはならない。出口設計を受け入れる前に、有効なルートテーブル、NAT Gateway の関連付け、NIC のパブリック IP をまとめて読むこと。

次の設定をAzure NIC の転送設定として、Linux の転送とは別に扱う。クラウド側のフラグは送信元や宛先が NIC に割り当てられていないパケットを許可するが、net.ipv4.ip_forward を有効にはせず、ゲスト側の設定がクラウドの許可を与えるわけでもない。

トンネルソケットには独自の送信元の決定がある

wg-quick 配下の WireGuard の Address は WireGuard インターフェースにアドレスを割り当てるもので、外側 UDP のバインド指示ではない。暗号化ソケットの送信元はルートテーブルに従うため、ポリシールートや二つ目のデフォルトルートがインターフェースのアドレスに触れずに動かすことができる。OpenVPNの local オプションと UDP の multihome も同じように振る舞う。これらはリスナーとその応答に関わるもので、転送される各クライアントのインターネット送信元には関わらない。

トンネルを運ぶアンダーレイルートを維持し、クライアントが想定した入口構成から認証済みの応答を依然として受け取ることを確認する。アドレスリストの順序を恒久的な送信元選択ポリシーとして頼ってはいけない。NIC に次に追加されるアドレスで、どちらが勝つかが変わりうる。

何を、どの順序で受け入れるか

三つの結果を別々に受け入れる。第一に、外部クライアントが想定した VPN 入口に到達する。第二に、その VPN クライアントからの新しい許可済みリクエストが、文書化されたインターネット出口を通る。第三に、意図しないリスナー経路と転送経路が拒否されたままである。パブリックからプライベートへの対応と、各決定のゲスト側・クラウド側の責任者を同じ場所に記録する。

トンネルの成功は最初の部分を証明するにすぎない。出口は新しいフローで試すこと。キャッシュされた接続は、ルート変更後も長く古い送信元を使い続けることがある。