サイト間トンネルは接続済み、VM は正常、しかしオンプレミスのクライアントには何も届かない。Network Watcher を開いて IP フロー検証を実行すると Access allowed と返るため、チケットは VPN の問題として閉じられる。この結果は見た目どおりの意味を持たない。IP フロー検証は記述したフローのセキュリティ規則を評価するだけで、Azure にオンプレミスのプレフィックスへのルートがあるかは決して検査しない。

フィルタリングの問いとルーティングの問いは別物であり、Network Watcher は異なる道具で答える。どちらを尋ねたかを知ることが診断の大半である。

IP フロー検証が実際に決めること

IP フロー検証は VM、ネットワークインターフェイス、方向、五つの組の値、プロトコルを受け取り、そのフローに対する NSG とセキュリティ管理者の規則の判定を報告する。TCP と UDP で動作するため ICMP 規則の試験器ではなく、遮断された ping はサービスの何も証明しない。推測ではなく実際のフローを与えること。オンプレミスからデータベースのポートへの内向き接続は、VM が開始する外向き接続とは別の記述である。

ゲートウェイがアドレスを変換する場合は、評価している境界に到達する送信元アドレスを使い、クライアント構成のものを使わない。結果もそのまま読むこと。Access allowed は、パケットが届けばフィルタ層が許可するという意味にすぎない。

答えられないのは、Azure が選んだルート、ゲストのファイアウォールがポートを許可するか、何かが待ち受けているかである。それらは別の層にある。

次ホップと有効なルートが加えるもの

次ホップは転送の問いに答える。この宛先に対し Azure がどの次ホップ種別を、どのアドレスで、どのルートテーブルから選ぶかである。有効なルートは NIC が実際に持つものを一覧する。両方を実行すれば、緑の IP フロー検証が空白のまま残す Azure 側の経路が得られる。

Microsoft の IP フロー検証の概要 はフィルタリングの範囲を直接示し、次ホップとルート診断のページは転送側を扱う。所見を書くときは正しいページを引用すること。

コマンドはシェルから実行できるほど短い。az network nic show-effective-route-table はインターフェイスに適用されたルートを一覧する。az network watcher show-next-hop は送信元と宛先を指定すると選択されたホップを返す。気になるプレフィックスをその表と照合し、どの項目が優先されるかを確認する。

VM の NIC から戻り経路をたどる

対象 VM の NIC から、オンプレミスのクライアントプレフィックスについて行う。インターネット向けではない。戻り経路はサイト間の障害が潜む場所である。トンネル状態の確認はセキュリティアソシエーションが確立していることしか報告しない。

期待するルートがない場合は、ゲートウェイ構成が提供する遠隔プレフィックス、VNet 接続の設計、ルート伝播の設定を確認する。ローカルネットワークゲートウェイのオブジェクトはオンプレミス側を記述するもので、その存在は必要なプレフィックスがすべて NIC にあり優先されていることを証明しない。それらは別の事実であり、ポータルの概要に現れるのは一方だけである。

例を写すのではなく次ホップ種別を読む

管理された VPN ゲートウェイの経路は通常、次ホップ種別として VirtualNetworkGateway を示す。VirtualAppliance は別の転送設計を表し、通常はファイアウォールやネットワーク仮想アプライアンスである。

古い掲示板の回答がその種別を使っていたからといって、推測した VPN エンドポイントに向けたアプライアンスルートを作らないこと。ユーザー定義ルートが意図した経路を上書きしているなら、変更する前に所有者と目的を突き止める。二枚目の NIC もゲストが使うインターフェイスを変えうるし、外すとこのルートを直すどころか別のサービスを壊すことがある。

まだ失敗している境界へ移る

フィルタリングとルーティングがどちらも設計どおりなら、障害は別の場所にある。ゲスト自身のルートテーブル、ファイアウォール、待ち受けが期待するアドレスに束縛されているかを確認する。次に VPN の保護トラフィックセレクターとオンプレミスの応答経路を確認する。どれも別の結果を持つ別の試験である。

許可されたアプリケーション要求と両端の観測で締めくくる。許可の結果と正しい次ホップは二つの証拠であり、接続が成功した証明ではない。

関連記事