Azure P2S: VNet 変更後に Windows クライアント一台だけルートが欠ける

二台のノート PC が同じ Azure point-to-site ゲートウェイに認証し、新しく接続された VNet に届くのは一台だけです。どちらも Connected と表示されるので、認証は違いではありません。違いは保持している宛先ルートです。失敗するクライアントから始め、一つの宛先を比較し、その後でゲートウェイ パッケージとローカル ルート テーブルのどちらに欠落があるかを判断します。

ゲートウェイではなく、失敗するクライアントから始める

ノート PC を疑う前にトポロジを確認します。どの VNet がゲートウェイ VNet に接続されているか、新しいネットワークが直接ピアリングされているのか、別の site-to-site トンネル経由で到達するのかを調べます。新しい VNet がゲートウェイ VNet にまったく接続されていなければ、どのクライアント パッケージもそこへルーティングできず、動作しているノート PC こそが説明すべき異常です。答えを書き留めてください。クライアントをデバッグしているのか、ゲートウェイをデバッグしているのかが決まります。

トポロジが正しければ、二台のノート PC を並べます。同じゲートウェイ、同じアドレス プール、同じプロトコル、同じクライアント ビルドが望ましい比較です。それ以外は後で排除すべき第二の変数になります。

route print で一つの宛先を比較する

許可されたリソース IP を選び、二台のノート PC を二回比較します。切断時と接続時です。Windows では route print -4 が宛先プレフィックス、インターフェイス、次ホップ、メトリック付きで IPv4 ルートを一覧します。VPN という語を含むエントリを数えるのではなく、その宛先で実際に勝つ行を記録してください。

選択はまず最長プレフィックス、次にメトリックで行われるため、より具体的なローカル ルートが誤って見えずにトンネル ルートを上回ることがあります。目的の宛先が 10.24.0.0/16 の内側なら、正常なクライアントは VPN インターフェイスに対応するルートを示し、失敗するクライアントは同じアドレスを既定ゲートウェイへ送ります。

競合するローカル プレフィックスでも同じ症状が出ます。何かを追加する前に、二つのケースのどちらなのかを決めます。トンネル ルートがまったく無いのか、より具体的なルートに負けているのかです。

TTL expired はルート配布のバグではない

TTL expired in transit を返す ping は、パケットがホップ許容量を使い切ったことを示します。これは通常、VPN ドライバの故障ではなく転送ループを意味します。Windows の ping は 255 までの TTL を受け付け、値を上げてもループは直りません。同じエラーが遅れるだけです。このメッセージは経路の症状として扱い、ルート配布の証拠にはしないでください。

tracert -4 10.24.1.10 を使って経路がどこで繰り返されるかを確認します。同じ二つのホップが何度も現れるなら、トンネル向けのトラフィックを再びトンネルへ、あるいは送り返すローカル ルーターへ向けるルートを探します。

所有するゲートウェイでパッケージを再生成する

Microsoft は、関連するトポロジ変更の後は Windows クライアント パッケージを再度ダウンロードしてインストールする必要があると文書化しています。このプロファイルを提供する Azure ゲートウェイから現在のパッケージを取得し、そのクライアントでサポートされる手順で適用します。無関係な VPN アプリケーションの実行ファイルを置き換えることは、ゲートウェイ固有の設定を再生成する操作とは同じではありません。パッケージの再ダウンロードは安価ですが、ローカル ルートの推測はそうではありません。

再接続して元の宛先のルートを読み直します。変更記録とともに変更前後の行を残せば、結果はクライアントを再インストールしたという表現より正確になります。

Azure P2S のルーティング シナリオは、直接ピアリングされた VNet と他のトンネル経由で到達するネットワークを区別しており、新しいパッケージでピアリングを推移的にすることはできません。Windows の site-to-site や BGP のシナリオには手動で構成したリモート ルートが必要なものもあり、パッケージの更新は普遍的なルート配布の仕組みではありません。

一時ルートは一時のままにする

手動ルートは欠けたクライアント ルートを切り分けられますが、実際の設計から組み立ててください。route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42 を永続フラグなしで使い、再起動で消えるようにします。インターフェイス インデックスと次ホップは接続中の VPN アダプターから選び、推測しないでください。

実験用ルートを恒久的な競合所有者として残さないでください。将来のプロファイル更新が同じプレフィックスを別のメトリックで追加すると、手動エントリがどちらの経路が勝つかを黙って決めてしまいます。削除手順を変更に記録します。

正しいルートが有効になったら、ping ではなく対象アプリケーションを試します。パケットが Azure に届いてもサービスが失敗する場合は、ネットワーク セキュリティ グループと戻り経路を確認してください。それらはノート PC がプレフィックスを学習したかどうかとは別です。