二本目の WAN VPN エントリが失敗し、プライマリは動作し続ける

プライマリトンネルは上がったままで、ユーザーは作業を続け、二本目の ISP 回線は何を変えても遊んでいる。バックアップ回線のアドレスを公開し、そこへ名前を向け、場合によってはクライアントにバックアップエントリを追加しても、クライアントは決して試さないか、認証までは通ってから落ちる。私が追跡した事例では、フェイルオーバー機能自体はたいてい正常で、欠けていたのはエントリを使えるようにする五つの要素のうちの一つだった。そのインターフェースで何も待ち受けていないのに名前だけがバックアップアドレスに解決されることも、応答がプライマリ経由で出ていくのにリスナーが接続を受け付けることもある。各 WAN を独自の契約を持つ別のエントリとして扱えば、障害はクライアントのバグには見えなくなる。

各 WAN には独自のエントリ契約が必要

WAN ごとに五つの項目を記録する: 公開名とアドレス、トランスポートとポート、それを終端するインターフェースまたはコンテキスト、提示すべきピア ID、そして応答が出ていく場所だ。 回線が二本なら完全なセットも二組。二組目に終端インターフェースも戻り経路もなければバックアップエントリは存在せず、意図を記述した DNS レコードがあるだけだ。

機器とそのバージョンもこの構成を支える必要がある。DNS レコードは別のインターフェースでサービスを開くことはできず、多くのプラットフォームではリスナーはデバイス単位ではなくアドレス単位で設定される。ASA のインターフェースベース IPsec は暗号マップとトンネルグループを外側インターフェースに結び付けるため、二本目のアップリンクにはパケットが実際に到着する場所でポリシーが必要になる。ルートベースの設計は挙動が異なり、リスナーはすべてのアドレスにも一つの名前付きアドレスにもバインドでき、その選択が ISP B が応答できるかどうかを決める。

二本目の WAN が本当に応答するか確認する

ゲートウェイの内側のマシンではなく、両方の回線の外側からテストし、クライアントプロファイルが使う名前をそのまま試す。TLS リスナーなら手早い確認は openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts をネットワーク外のホストから実行することだ。必要なのはプロファイルの名前と一致するチェーンを持つ完了したハンドシェイクであり、接続を受け付けるだけの TCP ポートではない。

RFC 9525 はクライアントが何を確認するかを説明している: 到達しようとした ID を、サービスが提示する証明書と比較する。プライマリエントリの証明書を返す二つ目のエントリや、どちらの名前も載っていない既定の証明書は、ポートが開いていてファイアウォールが許可していてもこのテストに失敗する。

ここでの障害の大半は二つのパターンで説明できる。接続がぶら下がる場合は、そのインターフェースにリスナーがない、プライマリのサブネットだけを許可するアクセスルールがある、または二本目の回線の手前のキャリア装置がポートを落としている。誤った ID でハンドシェイクが終わる場合は、別のトラストポイント、既定の仮想ホスト、または ID を調整せずにプライマリからコピーした設定が原因だ。

応答を追い、要求だけを見ない

二本目の WAN は戻りで壊れることが多い。要求は ISP B から届き、機器が応答し、その応答は ISP A の既定ルートを通り、クライアントが一度も要求していない送信元アドレスで出ていく。ステートフル変換はさらに悪化させる: マッピングがプライマリインターフェース向けに作られていれば、戻りのパケットは変換に当たらず、クライアントのファイアウォールが捨てる送信元を持つ。プロバイダーは自分が渡した回線に属さない送信元アドレスも捨てるので、きれいなプロトコルエラーではなく片方向のブラックホールに見える。

二つ目のエントリを送信元とするトラフィックのルーティング判断を確認する。応答は要求が到着したインターフェースから出るか、少なくとも遠端がその経路のものとして受け入れるアドレスを持つべきだ。ポリシールーティングのプラットフォームでは、受信インターフェースまたは変換後の送信元に紐づくルールと、外側インターフェースごとに結び付いた変換ステートメントが必要になる。クライアント接続中に両方のインターフェースで同時にキャプチャすれば、ISP B に届く SYN と ISP A から出る SYN-ACK で一回の実行で決着する。

クライアントが二つ目のエントリを知る手段を用意する

フェイルオーバーはクライアント側の判断であり、代替の学び方はクライアントファミリーごとに違う。ASA ではグループポリシーの webvpn 属性でバックアップサーバー一覧が配られ、他のクライアントはプロファイル内の一覧か、ユーザーが選ぶ手動の二つ目のプロファイルを期待する。Cisco の接続ポリシーガイドはクライアント設定とゲートウェイ提供の両方のバックアップ情報を説明しており、そのプロトコル固有の詳細をすべてのクライアントやトンネルモードに一般化してはいけない。誤った仕組みの上に二つ目のエントリを築く前に、配備済みクライアントがどちらを実装しているか確認する。

どの仕組みであれ、クライアントはプライマリ経路を失う前に代替名を解決できなければならない。見落とされやすいのがこの依存関係だ: 代替名が、たった今失敗したトンネル経由でしか届かないリゾルバーで解決されるなら、フォールバックは始まりもしない。二つ目の名前はローカルまたはインターネット経由で応答するリゾルバーに公開する。切り替え後には新しい認証と新しいアプリケーションセッションを想定するべきで、クライアントのフェイルオーバーはステートフルではなく長時間のセッションは生き残らない。

一つのアドレスを二社のプロバイダーで使うのは別製品

一つの公開アドレスを両方の回線から到達可能に保つのはルーティングサービスであり、VPN のチェックボックスではない。両プロバイダーが運ぶことに同意するアドレス空間が必要で、相手のネットワークが受け入れる形で広告し、プロバイダー非依存の空間と BGP によるマルチホーミングがそれを提供する。ISP A のアドレスを ISP B のインターフェースに割り当ててもそこには届かず、パケットはプレフィックスを一度も広告していないネットワークに到着し、上流で捨てられる。

二つのエントリを公開するのにそのどれも要らない。クライアントが二つの名前を保持して切り替えられるなら、独立した二つのエントリで足り、AS 番号、ピアリング契約、どこでも受け入れられるプレフィックスを避けられる。可搬アドレスの選択肢は、クライアントを再設定して置き換えることができない安定した入口が本当に必要なとき、または TTL 遅延を伴う DNS ベースのフェイルオーバーが想定する障害に対して遅すぎるときだけ検討する。

次に確認すること

失敗しているエントリから外側へ、この順に進める: 二つ目のアドレスが外から応答するか、クライアントが期待する ID を提示するか、要求が来た経路で応答が出るか、クライアントが必要になる前に名前を学べるか。答えが否ならその層を直し、テストホストではなく配備済みプロファイルで再試験するべきで、実験室のハンドシェイクは実クライアントの完了した接続より証拠として弱い。

WAN ごとにアドレス、ポート、終端インターフェース、証明書名、戻り経路、変換ルールを短く記録し、回線、NAT 装置、クライアントのバージョンが変わるたびに見直す。遊んでいるバックアップ経路は静かに腐り、誰も使わないエントリについて、全員がそれに依存する日まで何も警告しない。