Azure S2S VPN が接続済みなのに通信がない：IKE ログを読む

ポータルには Connected と表示され、トンネルには稼働時間のカウンターがあり、仮想マシンからの trace は二番目のホップで途切れます。接続状態が示すのは IKE と IPsec のネゴシエーションであり、どちらの側でもポリシー層を一つのパケットが通過するかどうかではありません。これらのチケットのほとんどは二つの不具合で説明でき、どちらも Azure のルートを変えても直りません。どちらもゲートウェイが出力したログにすでに書かれているので、私はルートテーブルではなくそこから読み始めます。

Connected が実際に証明するもの

サイト間接続が接続済みであるとは、フェーズ 1 とフェーズ 2 が完了し、セキュリティアソシエーションが稼働しているという意味です。これはネゴシエーションについての記述です。両方のピアが提案に合意し、鍵を交換し、SA の組をインストールしました。保護されていると考えているサブネットとトラフィックセレクターが一致するかどうかは何も語りませんし、復号した後に相手側がパケットをどこかへルーティングするかどうかも語りません。トンネルは何週間も稼働したままで、興味のあるフローをすべて落とし続けることがあり、それが健全なゲートウェイを作り直させる原因そのものです。

まず確認すべき二つの不具合は、ESP ではなく AH を提案するピアと、ゲートウェイが内部として扱わない空間で番号付けされた仮想ネットワークです。

ルートに触れる前にエクスポートしたログを開く

ポータルで仮想ネットワークゲートウェイを開き、接続に対して VPN troubleshoot 操作を実行し、生成されるバンドルをダウンロードして展開します。中にはフェーズ 1 とフェーズ 2 の交換を含む IKE ログがあり、タイムスタンプ付きでプレーンテキストとして読めます。上から下へ読むのではなく transform の行を検索してください。興味のある項目はたいてい数百行の奥にあります。ポータルにアクセスできない場合も、診断設定が有効であれば同じ診断情報がゲートウェイのログ出力先に現れます。

価値の大半を担う項目は二つです。一つ目はおおよそ expected ESP with combined authentication and cipher, received AH と書かれています。二つ目は IKE 交換中の invalid payload エラーで、通常は不正な形式か未対応の提案フィールドを意味します。

どちらもオンプレミス側の機器が何を提案したかを示しているので、どちらもピア側の設定です。Azure 側を作り直してもファイアウォールが送る提案は変わらず、それでもやってしまうのがこの作業で最もよく失われる一時間です。ピア側でフェーズ 2 を結合認証と暗号の ESP に設定し、アルゴリズムはネゴシエーションに任せ、そのうえで combined mode のような名前のベンダーのチェックボックスが、その下で AH の提案を黙って選んでいないか確認してください。

仮想ネットワークのアドレス空間を確認する

ゲートウェイは仮想ネットワークがプライベート範囲にあることを前提としています。パブリックブロックで番号付けされたネットワーク、たとえば 111.x で始まるものは、トンネルを上げても Azure がその空間を内部として扱わないため、接続は健全に見えてフローは一切受け入れられません。セレクターに半日を費やす前に、アドレス空間を確認してください。その番号付けが古い割り当てからの厳格な要件なら、対処は別のゲートウェイではなくアドレス計画の変更です。

アドレス空間のブレードにいる間に、オンプレミスの範囲との重複を記録してください。重複するプレフィックスは、クライアントから見ると似て見える別の障害を生みます。

両方向でプレフィックスを確認する

ローカルネットワークゲートウェイのリソースにはオンプレミスのプレフィックスが入っており、リモート機器が実際に保護しているサブネットと一致していなければなりません。機器が落とすアドレスを含む集約は、一部のフローを通し、別のフローでは失敗します。これは設定の不一致ではなく、断続的なルーティング障害のように見えます。相手側も確認してください。片端が /16 を挙げ、もう片端がその中の三つの /24 を挙げるのは典型的な部分障害です。どちらの一覧も単独では正しいとは限らないので、目に見えるほうを信じるのではなく並べて比較してください。

プレフィックスの変更は自動で反映されないことがあるので、接続オブジェクトを保存し直すか作り直す予定を立て、その後で新しいプレフィックスが両側に現れることを確認してください。

ping ではなく経路を試す

動作するトンネルと動作するルートを分ける trace は次のとおりです。最初のホップがオンプレミスのゲートウェイ、次に応答しないホップがいくつか、その後にリモートホストが応答します。trace がホストに届かない場合は、アプリケーションが実際に使う TCP ポートを試してください。ICMP は十分な頻度でフィルタされるため、失敗した ping が証明するものはごくわずかです。同じ trace をリモートホストから Azure の仮想マシンに向けて実行してください。二つの結果の非対称性が、戻りルートの欠落や片方向だけを許可するルールを見つける最短の方法です。

ピアの提案、両方のアドレス空間、接続の作成時刻をチケットに書いてください。次のエンジニアが、どの値を作り直し、どれに一切触れていないかを知れるようにするためです。

ログが空で返ってくる場合、ゲートウェイがそもそも接続を終端していない可能性があります。ローカルネットワークゲートウェイのピアアドレスが、ログを読んでいる機器と一致することを確認してください。同じサブスクリプション内の二つのゲートウェイは、作り直しの最中に取り違えやすいからです。その間違いは一日を費やし、どのログにも痕跡を残しません。