Azure P2S VPN の固定 IP：クライアントのアドレスが変わる理由

Azure point-to-site の各クライアントは、認証時にプールからアドレスを受け取り、その接続が続く間だけ保持します。予約テーブルも、ユーザーごとの対応表も、「この人には常に 172.16.0.10 を渡す」というゲートウェイ設定もありません。この一つの仕組みが、後になって人が出会う二つの症状を説明します。以前は一致していたユーザーと一致しなくなる NSG ルールと、誰も意図して追加していないマシンを黙って通してしまう許可リストです。ルールをもっと賢い IP ルールに置き換えてもどちらも直りません。ルールが名指ししているものは、あなたが制御していないスケジュールで再割り当てされるからです。

プールは容量であり、身元ではありません。同時接続のトンネルが一意のアドレスを得るために存在し、リースが切れた瞬間にそれらを再利用します。それが分かれば、有用な問いは「このクライアントをどう固定するか」ではなく「ゲートウェイが再利用しない何に対してルールを書けるか」になります。

クライアントが接続したとき、ゲートウェイは実際に何をするのか

ゲートウェイは設定されたクライアント アドレス プールを保持し、それをリース表として扱います。接続時には次の空きアドレス、実際には利用可能な最も低いものを取り、クライアントが切断するかリースが切れるまでトンネル アダプターに割り当てます。決めるのは順序であり、身元ではありません。静かな期間の後に最初に再接続した人が、その瞬間たまたま空いている最も低いアドレスを取ります。

プールの大きさが挙動を隠します。テスターの数より一つか二つ多いラボのプールは決定的に見えます。同じノート PC が毎朝同じ順序で再接続する傾向があるからです。三台目のマシンを加える、プールの大きさを変える、昼食の間セッションを接続したままにする、のいずれかでパターンは崩れます。アドレスは決して安定していませんでした。安定していたのは待ち行列です。

point-to-site の設定変更はリース空間もリセットします。別の認証方式、サイズ変更されたプール、新しいプール範囲、あるいは削除して作り直されたゲートウェイは、どれもクライアントを古いアドレスに対応しなくなったプールへ戻します。その変更のどこも NSG には触れません。だから故障は自然発生的に見えるのです。

一分ほどで観察できます。接続し、クライアントの接続詳細でトンネル アドレスを記録し、切断し、二台目のマシンを接続し、そのあと一台目を再接続します。戻ってくるアドレスは二台目が保持しているもの次第で、どのポータル設定も以前のアドレスを要求どおりに復元しません。

クライアント IP に基づく NSG は、実は接続順序についてのルールです

人が最初に書くルールは明白なものです。管理 VM の NIC またはそのサブネットに対する受信ルールで、送信元を VPN クライアントの内部アドレスにします。短く、書いた当日のテストには通り、プールに空きアドレスが二つ以上あるとすぐ破綻します。

そこから二つの故障の仕方が生まれ、バグに見えるのは片方だけです。正規のユーザーが拒否されるのは、ルールが名指しするアドレスを今ほかの誰かが持っているからで、面倒なサポート依頼として現れます。あるいは意図しないユーザーが通されるのは、ルールがまだ信じているアドレスを引き継いだからで、誰かがアクセスを監査するまで何も現れません。

ルールがリースに従う以上、実効的なポリシーは「最初に接続した人が管理アクセスを得る」と読めます。これは意図の衣を着た接続順序の記述であり、どんなルールの整理でも意図の表現にはなりません。

クライアントのリースとゲートウェイのアドレスは別のオブジェクトです

混乱の大半は一つの言葉から来ます。ゲートウェイには比較的安定したパブリック IP があります。クライアントにはプールから配られるプライベート アドレスがあり、それは安定していません。ゾーン冗長でない VPN ゲートウェイのパブリック IP は動的に割り当てられますが、サイズ変更、リセット、定例保守を生き延びます。変わるのはゲートウェイ自体が削除されて作り直されたときです。ゾーン冗長およびゾーン対応のゲートウェイ SKU は Standard SKU のパブリック IP を使い、その割り当ては静的でなければなりません。

その安定性こそがオンプレミスのピアが設定に必要とするもので、個々のクライアントを識別することについては何も言っていません。パートナーがどのアドレスを見るのかと尋ねたら、答えは site-to-site におけるゲートウェイのパブリック IP、または共有 NAT 範囲です。ノート PC のトンネル リースでは決してありません。

グループ プールは、ルールを書く価値のある範囲を与えます

Virtual WAN point-to-site はユーザー グループをサポートし、各グループに独自のクライアント アドレス プールを割り当てられます。所属は身元で決まるため、クライアントが落ちる範囲は予測可能になります。運用は一つの範囲に、委託先は別の範囲に、そしてその範囲はファイアウォールや NSG のルールが推測なしに名指しできるものです。

結果としてできるルール群は、見直せる形をしています。

• 対象ごとに一つのプール。人数ではなく同時接続のピークに合わせて大きさを決めます。
• グループ所属は身元で扱い、誰かが加わるたびにルールを編集するのではありません。
• NSG や Azure Firewall のルールはプール範囲に対して書き、個々のリースに対しては決して書きません。
• 決して範囲を共有してはならない対象には、別のハブまたはゲートウェイを用意します。

プール全体を許可リストに入れるのは正直ですが粗い方法です。その範囲の接続クライアントは全員同じアクセスを得ます。それはレビューで発見するのではなく、声に出して言う価値のあるポリシー判断です。それでも人ごとの答えが必要なものは、パケット フィルターではなく、ロールの割り当てを通じてリソース側に属します。

展開を Virtual WAN に移せない場合

多くのゲートウェイは素の VPN ゲートウェイのままで、Virtual WAN への移行は気軽な変更ではありません。実用的な答えは、ユーザーごとの判断をパケット フィルターから、ユーザーが誰かをすでに知っている何かへ移すことです。

リソース レベルの身元が最も安価な版です。Storage、SQL、Key Vault はいずれもユーザー単位またはグループ単位のロール割り当てを伴う Entra ID 認証をサポートするので、VPN はネットワーク到達性を示すだけで済みます。名前付きアカウントを持つジャンプ ホストは管理作業で同じ役割を果たします。ホストが人間を記録し、トンネルはパケットを運ぶだけだからです。クライアントを DNS に登録し、番号ではなく名前を許可すれば、ルールは一段上がります。アプリケーション層の身元、つまり証明書のサブジェクト、トークンのクレーム、グループ所属は、決めるよう求められるのがネットワークではなくアプリケーションであるときに機能します。

固定の送信元アドレスにこだわるパートナーには、定義されたピア プレフィックスを持つ site-to-site か ExpressRoute が答えです。相手はピア プレフィックスを許可し、こちら側に現れるアドレスはゲートウェイのもので、誰かがノート PC を再起動しても変わりません。

別の許可リストを編集する前にプールを確認する

プールの二つの性質が、人がクライアントのせいにする挙動の大半を生みます。小さすぎるプールはリースを速く再利用するので、アドレスは絶えず動いて見え、アドレスに基づくルールは設計からして不安定に見えます。オンプレミスの範囲や仮想ネットワークのアドレス空間と重なるプールは、どのファイアウォール ルールでも直せないルーティングの曖昧さを生みます。

ルールに触る前に三つを一枚にまとめてください。point-to-site のプール、仮想ネットワークのアドレス空間、オンプレミスの範囲です。これらは重なってはならず、プールには同時接続のクライアント全員分の余裕と、再接続のための余白が必要です。

そのうえで次の順でループを閉じます。

• 二台のマシンから両方の順序で接続し、アドレスを比べます。入れ替わりうるなら、アドレスに基づくルールは安全ではありません。
• ゲートウェイが Virtual WAN かどうかを確認します。そうなら、アドレスごとのルールではなくグループ プールを使います。
• ルールが誤った相手に一致したときに何が起きるかを尋ねます。答えがアクセス事故なら、制御を身元へ移します。
• どの範囲がどのグループのものかを、NSG の定義と同じリポジトリに記録します。
• プール、認証、ゲートウェイの変更のたびに再テストします。それらの変更は告知なしに対応を書き換えるからです。