VPN 起動後に Azure VM が IMDS や WireServer に到達できない

VM は起動しており、VPN クライアントは接続済みと表示しているのに、数分後に Azure エージェントが異常を報告し始めます。SSH は生きているのにポータルの Run Command が通らないことがあり、そのせいで人はルートテーブルではなくエージェントを見に行きます。トンネルが上がった時点でゲスト自身の転送判断が変わり、通常は二つのプラットフォームアドレスが最初の犠牲になります。私はこれをエージェントの故障として扱う前に、ルーティングの症状として扱います。

症状は壊れたエージェントに見える

以下の二つのアドレスはどちらも修正案として挙げられますが、同じサービスではありません。片方でうまくいったからという理由でもう片方に /32 をコピーするのは、一時的な回避策が誰も外せない恒久的な設定になる典型です。

うまくいく順序は、失敗している呼び出しが実際にどちらのアドレスを対象にしているかを確認し、次にゲストがそれをどう解決するかを読むことです。それ以外は手順が増えるだけの推測であり、変更の窓も長くなります。

168.63.129.16 は公開の宛先ではない

168.63.129.16 は Azure の特別な仮想プラットフォームアドレスで、その役割の一つが WireServer です。VM エージェントはこれを使ってファブリックと通信します。Microsoft は、エージェントの TCP 80 と 32526 への通信を利用可能に保つ必要があると文書化しています。これは通常のインターネットホストではなく、フルトンネル VPN が遠隔の出口へ運ぶべきものではありません。だからこそ、健全に見えるトンネルでもエージェントを飢えさせることがあります。

プラットフォームアドレスのドキュメント も、このアドレスがユーザー定義ルートの対象外であると述べています。これは Azure ファブリックの性質であり、あなたのゲストについての約束ではありません。ローカルのファイアウォール規則や VPN クライアント自身のルーティングポリシーは依然として経路を壊せますし、どちらも VNet のルートテーブルには存在しません。

問題を報告しているのがエージェントなら、何かを再インストールする前にサービスの状態とそのアドレスへの経路を確認してください。

169.254.169.254 には独自の規則がある

169.254.169.254 は Azure Instance Metadata Service の link-local アドレスです。そこへの要求には独自の条件があります。プライマリ NIC とプライマリ IP、このアドレスをサポートする DHCP 構成、そしてあらゆる HTTP プロキシの迂回です。遠隔の VPN 出口や任意のインターネットゲートウェイ経由で送るのは、Microsoft が説明するアクセスモデルではありません。

このプロキシの条件は、ルートを直したのにまだ失敗する人を捕まえます。ゲストの HTTP プロキシは IMDS を壊すことがあり、その間 ip route get は期待どおりのインターフェースを返します。だからルートだけでなくプロキシの除外も確認してください。

これをデバッグしている間、メタデータの応答をサポートチケットに貼り付けないでください。インシデントより長く残る資格情報やインスタンスの詳細を含むことがあります。

ゲストのポリシールーティングを読む。メインテーブルだけでは不十分

Linux ゲストでは、三つの読み取り専用コマンドが層を分けます。ポリシー規則には ip -4 rule show、そしてカーネルが実際に下す判断には ip -4 route get 168.63.129.16 と ip -4 route get 169.254.169.254 です。VPN 接続の前後で実行してください。その二つの出力の差があなたの変更セットであり、クライアントが何をしたかについてのどんな推測より有用です。

ポリシー規則をインストールする VPN クライアントは、メインテーブルを触らずにそれらの検索を転送し続けることがあります。だからメインテーブルだけを直す対処は、あるホストでは効いて次のホストでは何もしないように見えます。複数 NIC のゲストは同じ問題を逆方向から加えます。答えは規則がどの NIC と送信元アドレスを選ぶかによるからです。

古いゲートウェイ経由で両方の /32 ルートを追加するレシピに抗ってください。link-local のプラットフォーム経路と一般的な WAN のネクストホップは別のオブジェクトであり、一律の例外は本当のポリシー衝突を隠します。

管理と復旧を分けておく

SSH や RDP の応答もフルトンネルのデフォルトに捕らえられますが、それはプラットフォームのエンドポイントではなく管理者の観測アドレスを対象にします。それ自体の要求と応答の組で診断し、VPN ポリシーを変える前にシリアルコンソールのような独立した復旧経路を確保してください。デプロイが VM を再起動し、エージェントが異常を報告した場合は、ルート変更が再起動を招いたと決めつけず、記録された操作と担当サービスを調べてください。

次に三つの流れを別々に検証します。本当に必要だったプライベートリソース、サポートされるエージェントとプラットフォームの通信、そして管理経路です。一つを復旧したことは、他の二つが生き残った証拠ではありません。

承認された例外は、ゲストネットワークと VPN 構成の所有者の下に、再接続時と再起動時に何が起きるかを含めて書いてください。Azure の UDR はゲストのルートテーブルではなく、それを編集してもローカルのポリシー規則は直りません。