Azure Point-to-Site VPN でパブリック IP が変わらない理由
ポイント対サイト トンネルは仮想ネットワークのルートだけを運ぶため、強制トンネリングとファイアウォールの SNAT が出口を Azure に移すまで、パブリック IP はローカルのままです。
Windows ノート PC で Azure VPN クライアントを接続し、アドレス確認ページを開くと、自宅のルーターが割り当てたものと同じパブリック アドレスが見えます。一方で 10.20.0.4 のジャンプ ボックスは応答し、プライベート エンドポイント名も解決するので、トンネルは壊れていません。ポイント対サイト ゲートウェイは、既定の構成が言うとおりの動作をしているだけです。プライベート プレフィックスを運び、それ以外はすべてローカル リンクに残します。Azure 所有の出口アドレスを得るのはルーティング設計の変更であり、修理ではありません。
ゲートウェイが既定で広告するもの
ゲートウェイは仮想ネットワークのアドレス空間のルートに加え、ゲートウェイ トランジットが許可されたピア ネットワークと、サイト間接続や BGP で学習したオンプレミス プレフィックスをプッシュします。その集合に 0.0.0.0/0 はありません。OS は既定ルートを Wi-Fi または Ethernet 上に保持するため、パブリック API 宛てのパケットはそもそもトンネルに入りません。
クライアントがトンネル内で受け取るアドレスは、ポイント対サイト プールからのプライベート リースです。これは VNet 内のリソースに対してクライアントを識別するもので、インターネットから見えるアドレスではなく、SaaS API への外向き要求の送信元として現れることもありません。そのリースを前提にした許可リストの登録は機能しません。ベンダーのログに現れるのをどれだけ待っても同じです。
スプリット トンネルと強制トンネリングの比較
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
リモート サービスから見えるアドレスが変わるのは二番目の行だけです。この表のほかのすべては、出口を Azure 内で検査または変換する必要があるときに受け入れるコストと運用面です。誰かがパブリック IP を変えろと言うとき、求めているのは右の列全体であり、クライアントの小さな調整ではありません。
何かを再構築する前に、名前を付けておく価値のある中間案があります。VNet 内のプロキシまたはゲートウェイ VM を使えば、そこへ向けられるアプリケーションに制御された送信元アドレスを与えられ、クライアントの既定ルートは動かしません。通常の閲覧はローカルのまま、Azure から API 呼び出しが一つ届けばよいパートナーも満たせます。要件が本当にすべてのトラフィックに関するものだと失敗します。プロキシ設定を無視するものは、やはりローカルから出ていくからです。
トンネルに既定ルートを運ばせる
仮想ネットワーク ゲートウェイでクライアントのインターネット トラフィックをすべてトンネルへ向ける、サポートされた方法はポイント対サイト構成にカスタム ルートを追加することです。二つの半分で IPv4 空間全体を覆い、どちらもローカルの既定ルートより具体的なので、クライアントは何も削除せずにそれらを優先します：
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1この行は例示であり、そのままコピーできる完全なものではありません。まず Get-AzVirtualNetworkGateway でゲートウェイ オブジェクトを取得して GWOBJ の代わりに入れ、実行前に SKU とデプロイ モデルがカスタム ルートを受け入れることを確認してください。同じプレフィックスはポータルのポイント対サイト構成ページにもあり、ゲートウェイをまだスクリプト化していないなら、そちらで設定するほうが安全です。
これらのプレフィックスを変えるとクライアント パッケージは無効になります。ルートはプロファイルの中を移動するため、VPN クライアント パッケージを再ダウンロードして再インストールしてください。古いプロファイルのまま再接続したクライアントは古いルート セットを保持し、届かなかった変更のデバッグに一時間を失うことがあります。
保護された Virtual WAN ハブでは、同等のものはポイント対サイト ゲートウェイに関連付けられたハブ ルート テーブルの既定ルートで、トラフィックはハブの Azure Firewall が引き受けます。ファイアウォールはインターネット向けの接続を自身のパブリック IP アドレスに変換し、その変換から新しい出口アドレスが生まれます。ファイアウォールに複数のパブリック IP がある場合、どれでも送信元として現れる可能性があるため、許可リストにはすべてを含める必要があります。
上記の設計はどちらも IPv4 です。二つの /1 プレフィックスは IPv6 には何の効果もなく、ポイント対サイトの IPv6 サポートは狭いので、同等性を約束する前に組み合わせをテストしてください。
ルートを確認し、次に出口を確認する
パッケージを再インストールして再接続したら、クライアントが実際に半分をインストールしたことを確認します。Windows では Get-NetRoute -DestinationPrefix 0.0.0.0/1 と同じ問い合わせを 128.0.0.0/1 に対して行うとトンネル インターフェイスが示され、route print は元の既定ルートの隣に両方を表示します。Linux では ip route show が二つのプレフィックスを一覧する必要があります。出なければ、プロファイルはそれらを運んでいません。
次にクライアントからパブリック アドレスを再確認し、同じ接続についてファイアウォール ログを読みます。送信元は変換されたポートを持つファイアウォールのパブリック IP であるはずです。両方のルートがあるのにクライアントがローカルから出ているなら、パケットは Azure に到達して別の経路で出ています。ゲートウェイ サブネットのユーザー定義ルート、それ自体がオンプレミスへ強制トンネルされているファイアウォール、変換前にフローを落とすポリシーのいずれかです。
同じセッションでプライベートな宛先を一つ再テストします。変更後に応答しなくなるジャンプ ホストは、新しいプレフィックスが何かを押しのけた通常の兆候です。以前に広告されていたより狭いローカル ルートか、プライベート ゾーンのフォワーダーがないリゾルバーへ向かうようになった名前解決のどちらかです。
スプリット トンネルをそのままにする場合
目的がプライベート API、プライベート エンドポイント、社内管理ページへの到達だけなら、既定の動作のほうが安く静かです。強制トンネリングはファイアウォールの時間とデータ処理料金、より長い経路、すべてのクライアント フローが失敗しうる場所を一つ増やします。気にしていた一つの宛先よりはるかに多くのトラフィックも捕捉します。
要件が出口の観点で語られるときに使います。パートナーが固定の Azure アドレスを見る必要がある、セキュリティが接続のログと検査を求める、データが一つの制御点から出る必要がある、といった場合です。その場合でも設計は全ユーザーに共有の出口を与えるので、ユーザーごとの説明責任は送信元アドレスではなくアプリケーションの ID から取る必要があります。
変更を閉じる前に、インストールされたクライアント パッケージが新しいこと、二つの /1 ルートがトンネル インターフェイス上にあること、プライベートな宛先がまだ応答すること、リモート サービスのログにファイアウォールのアドレスが表示されることの四点を確認します。