Azure の VPN アプライアンス VM が戻り経路を失う理由

VPN アプライアンスを動かす Azure VM は、互いに独立した二つの意思決定システムの中に置かれています。パケットがどのサブネットから出るのかは、ルート テーブルと NIC の転送設定を使って Azure が決めます。復号されたパケットを先へ転送するかどうかは、アプライアンス自身の OS が決めます。完璧に確立したトンネルでも二つ目のシステムで失敗することがあり、こうした導入の多くはそこで止まります。

一本の経路を所有する三者

ブランチ ネットワークを 192.168.50.0/24 、ワークロード サブネットを 10.0.10.0/24、アプライアンスは独自のサブネット内の 10.0.0.4 とします。一つの要求が三つの別々の設定に触れます。

ほとんどの組織では行ごとに別のチームが所有しているため、この障害は通常一件ではなく三件のチケットとして届きます。

アプライアンスを指すルート

ルート テーブルをワークロード サブネットに関連付け、ブランチのプレフィックスに Virtual appliance タイプの次ホップを指定し、アドレスは 10.0.0.4 を使います。アプライアンスの到達可能なプライベート アドレスを使い、決して そのパブリック VPN エントリ ポイントを使わないでください。次ホップは、ワークロード サブネットがすでに到達できるアドレスでなければなりません。既定のルートを意図的に置き換えると決めたのでなければ、ワークロードの他のルーティングには手を触れないでください。

アプライアンスは独自のサブネットに置いたまま、ブランチのトラフィックをアプライアンスへ送るルートがアプライアンス自身の外向き経路まで巻き込まないようにします。そのようなループは応答がゼロの健全なトンネルに見え、深夜 2 時にデバッグするにはあまりに厄介なものです。

誰もが忘れる NIC フラグ

Azure には NIC ごとの IP 転送設定があり、既定ではオフです。これは、転送する NIC が自分以外を宛先とするパケットを受け取るためで、それを黙って捨てるのが他のすべてにとって安全な既定値です。

az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true 一つのインターフェイスに対してこれを有効にします。Microsoft の NIC 転送のガイダンス は、トラフィックを転送する接続済みの各 NIC にこの設定を求めているため、NIC が一枚だけのアプライアンスでもその一枚に設定する必要があります。

このフラグはルートではなく、ファイアウォール規則でもありません。有効にすると許可が与えられるだけで、それ以外は何もありません。

ゲストは復号されたパケットをどう扱うか

トンネルが終わると、アプライアンス自身のスタックが次の判断をします。Linux ゲストでは IPv4 転送は実行時の設定であり、 sysctl -w net.ipv4.ip_forward=1 次の起動までしか持ちません。代わりに /etc/sysctl.d/ 配下のファイルに保存してください。ベンダーのアプライアンスには独自の同等機能があり、ベンダーのプラットフォームに貼り付けた Linux の手順は通常まったく何もしません。

ゲストのファイアウォール ポリシーも、ワークロードのネットワーク セキュリティ グループも、また別です。VM のパブリック アドレスへ UDP 500 と 4500 を許可することはトンネルを守りますが、復号されたブランチ要求がワークロードのポートに届くかどうかについては何も語っていません。

一つの要求とその応答を追う

許可されたフローを一つ選び、最初から最後まで追跡します。ブランチには 10.0.10.0/24 向けのルートがサイト接続経由で必要であり、アプライアンスにはワークロード サブネットへの配信経路が必要で、ワークロード サブネットにはブランチへ戻るルートが必要です。

設計がブランチの送信元アドレスを保持するのか、変換するのかを早めに決めます。NAT はワークロードに見えるものを変えるため、アクセス ルールは推測したゲートウェイ アドレスではなく、実際に選んだモデルを記述すべきです。

ハンドシェイクの成功はその連鎖の一つの環を証明するだけです。応答が同じアプライアンスを通って戻り、ワークロード自身のポリシーがそれを許可したときに、経路は完成します。