Azure P2S VPN の戻りトラフィックが片方向しか通らない理由

トンネルのアイコンは緑で、NSG も許可しているように見え、有効なルートも正しく見えます。それでも VM は接続済みのクライアントへ向けた接続を開けません。よくある思い込みは、動作している point-to-site トンネルは対称的だというものです。クライアントが VM に到達できるなら、VM もクライアントに到達できるはずだ、と。その思い込みこそが推論の誤りであり、構成の誤りではありません。トンネルは、要求のないフローの片方向だけを運び、もう片方を落とすことがあります。修正は、どちらの層が落としているかで変わります。

誤解: 接続済みのトンネルは双方向トンネルである

VPN トンネルはケーブルではなくポリシーの経路です。各方向はセレクター、ルート、フィルターと照合され、そのどれもが片方向を許可しながらもう片方を遮断できます。

実際には非対称性はよくあるため、方向は最後ではなく最初のテストに入れるべきです。クライアントが開始し、ゲートウェイがフローを追跡し、応答は作成された状態に従います。新しいフローを開始する VM にはその状態がないため、戻り経路が明示的にルーティング可能で許可されているかに依存します。その経路がない場合、接続の試行はどのアプリケーションにも見られる前に失敗します。

到達性をテストする前に方向をテストする

クライアントのアドレスを一つ、VM のアドレスを一つ、プロトコルを一つ選びます。クライアントから接続して結果を記録し、次に同じテストを VM から開始してそれも記録します。一つ目が成功して二つ目が失敗するなら、クライアントプール、ゲートウェイの関連付け、クライアントから VNet への経路はすべて機能しています。

次の手順はルールを増やすことではなく、証拠を集めることです。VM サブネットの NSG を両方向で確認し、VM の NIC の有効なルートを読み、クライアントがトラフィックを送っている間に VM でパケットを取得します。応答なしで届く要求はフィルターか戻りルートの問題で、まったく届かない要求は経路の問題です。失敗した ping を VM が到達不能である証拠とみなさないでください。TCP が動いていても ICMP ポリシーが応答を落とすことがあります。

IKEv2 point-to-site の戻り経路がよくある容疑者です

この記事の背景にある Azure の報告では、クライアントは IKEv2 で VM に到達できましたが、VM からクライアントへの受信 ICMP は、ゲートウェイのトンネルの種類を OpenVPN に切り替えるまで失敗しました。報告者は、Microsoft が IKEv2 point-to-site 経路の制限を確認したと述べています。クライアントがセッションを開始していない限り、VM からクライアントへの戻りトラフィックは対称的にルーティングされない、というものです。IKEv2 はトラフィックセレクターに依存しており、その場合ゲートウェイは戻り方向を尊重しませんでした。

だからといって、OpenVPN が一般に優れたトンネルの種類というわけではありません。このワークロードのテストマトリックスでは、トンネルの種類が変数になる、ということです。

トンネルの種類の切り替えはサービス変更であり、スイッチの切り替えではありません。すべてのクライアントに互換性のあるプロファイルが必要で、ゲートウェイには別の証明書や認証設定が必要になることがあります。テスト用クライアント一つとテスト用 VM 一つで一方向の動作を再現し、承認されたスケジュールで種類を変更し、その後で同じ方向テストを繰り返します。切り替え後も動作が残るなら、トンネルの種類は原因ではなく、本番環境に触れずに問題を絞り込めたことになります。

誤解: ブロードキャストによる探索は VNet の境界を越える

二つ目の思い込みは、無関係な理由で成り立ちません。Azure の仮想ネットワークはブロードキャストトラフィックを運ばないため、VM は site-to-site や point-to-site 接続を経由してオンプレミスネットワークからブロードキャストフレームを受け取れません。古いファイル閲覧や一部のデバイス探索プロトコルのように、ブロードキャストでピアを見つけるアプリケーションは、ルートをどう書いてもリモート側を見ることはありません。

ブロードキャストによる探索を、DNS 名、ディレクトリサービス、または明示的なピア一覧に置き換えてください。アプリケーションにユニキャストの代替がない場合、設計にはより広いトンネルではなく、別の探索メカニズムが必要です。

何を変更し、どう証明するか

方向テストが IKEv2 だけで失敗する場合は、ゲートウェイのトンネルの種類、クライアントアドレスプール、正確な ICMP または TCP のテストを記録し、影響を受けるクライアント向けに承認済みの OpenVPN プロファイルを評価します。すべてのトンネルの種類で失敗する場合は、戻り経路に取り組みます。クライアントアドレスは VM サブネットからルーティング可能でなければならず、ユーザー定義ルートは有効な次ホップを指し、クライアントのファイアウォールは受信フローを受け入れる必要があります。NSG とルートの証拠をチケットに添付してください。

ping ではなくアプリケーションで検証してください。変更後の ICMP のやり取りが成功しても、サービスポート、その認証、名前解決については何も分かりません。再接続後にテストを繰り返してください。プールから別のアドレスを受け取ったクライアントは結果を変えられるからです。さらに、クライアントがスリープして復帰した後にもう一度繰り返してください。再開されたセッションで一方向の動作が再び現れることがよくあるからです。