フェイルオーバーは設定どおりに動き、それこそが問題でした。プライマリトンネルが落ちると、ルーターはデフォルトルートをケーブルモデムへ移し、ノートPCはブラウジングを続け、誰も電話してきませんでした。二日後、経理の共有フォルダが六時間にわたって開かれたインターネット経路から到達可能だったことに誰かが気づきました。ルーター上のVPNフェイルオーバーポリシーはルーティングの小技ではなく、優先経路が失われたときトラフィックをどうするかという決定であり、その決定は経路が消える前に存在していなければなりません。

検出器を選ぶ前に結果を決める

通常の候補は三つで、影響を受けるクライアントをバックアップトンネル経由で送るか、通常のWANを使わせるか、完全に遮断するかです。どのVLAN、SSID、デバイスクラスにどれを適用するかを書き出してください。単一の平板な「WANへ切り替える」ルールが、上の経理フォルダを公開経路に載せた原因です。

三つは互いに置き換え可能ではありません。WANへのフォールバックはサポートデスクの電話対応を保ちますが、内部名をローカルリゾルバーに露出します。バックアップトンネルはポリシーを保ちますが、相手側が受け入れない出口アドレスに着地することがあります。遮断は給与VLANには正しく、トンネルを一度も使っていないゲストネットワークには誤りです。

結果適する対象何が壊れるか
バックアップトンネルポリシーを保つ必要があり、リモートアクセスが必要新しい出口アドレス、戻りルート、遅い鍵更新
通常のWANゲストまたは公開のみのトラフィック内部名、DNSとIPv6の露出
遮断給与、管理、VPN専用のすべてユーザーはすべてのアクセスを失い、あなたに電話する

実際に恐れている障害に検出器を合わせる

ハンドシェイクの状態、インターフェースの状態、利用可能な転送は三つの異なる信号であり、ユーザーにとって重要なのは最後の一つだけです。WireGuardのピアが最近のハンドシェイクを示していても、プロバイダーの上流がパケットを黒穴に捨てていることがあります。 OpenVPN クライアントは、押し込んだルートが解決されなくなった後も「接続済み」のまま座っていることがあります。

pfSenseでは実務的な構成はdpingerに支えられたゲートウェイグループで、監視アドレスを探り、損失や遅延がしきい値を超えるとゲートウェイをダウンと印付けます。その監視はトンネルの外側、たとえば遠隔LANのホストや、そこを通って到達する公開アドレスに向けてください。トンネル自身のピアアドレスに向けると、すでに生きていると分かっている部分を測ることになります。

バックアップが最後の手段であり続けるようにグループを組む

平板なメンバー一覧ではなく階層を使います。プライマリを階層1に、バックアップトンネルを階層2に、WANを階層3に、ポリシーが許すVLANだけ。pfSenseではこれは System > Routing > Gateway Groups の下にあり、両方のゲートウェイを追加し、異なる階層を与え、Trigger Levelをmember down plus packet lossに設定して保存し、その後グループをインターフェースの既定値として、または必要とするファイアウォールルールのGateway欄に適用します。

pfSense 2.5以降のOpenVPNクライアントインスタンスでは、インスタンスのDefault Gateway設定が、トンネルがシステムの既定ルートを置き換えるかどうかを決めます。 ルールによるポリシールーティングは、想定しているルートが実際にインストールされているときだけ期待どおりに動きます。変更後は Status > Gateways を確認し、トンネル状態アイコンを信じないでください。

二つの設定がほとんどのフラッピングを起こします。一つはプロバイダー自身の再収束より短いプローブ間隔です。もう一つはプライマリとバックアップが階層を共有するグループで、その場合どちらも常に適格なままです。ユーザーがあなたの代わりに遷移を感じる前に、損失と遅延のしきい値でヒステリシスを追加してください。

トンネルが決して所有していなかった経路を閉じる

まずDNSリークです。リゾルバーはWAN上で応答を続け、そこから転送するので、トラフィックがトンネルに固定されていても名前はISP経由で解決され続けます。リゾルバーの外向きインターフェースを制限し、内部リゾルバーをクライアントへ押し込み、VPN専用VLANの他のすべてに対してポート53を遮断します。

IPv6には独自の決定が必要です。デュアルスタックのLANはトンネルを失っても動作するグローバルIPv6既定ルートを保てるため、ブラウザーはIPv6を好み、IPv4が完全に閉じ込められているように見える一方でWANから出ていきます。IPv6をトンネルに流すか、トンネルが落ちている間はグローバルプレフィックスの広告を止めるかです。半分のポリシーは、動いているように見えるので何もないより悪いです。

次に戻り経路です。バックアップ出口が別の送信元アドレスを使うなら、相手側はトラフィックをそこへ戻す方法を知っている必要があり、古いアドレスに紐づいた状態はすでに死んでいます。プライマリが落ちたときに開いていたセッションは移行せず、タイムアウトするまで止まり、アプリケーションがどうするかを決めます。

落ちる場合、フラップ、戻り道をテストする

無害なトラフィックを流したままプライマリを抜いたうえで、次の四つを確認します:Status > Gateways でグループのメンバー状態、 pfctl -ss で古いゲートウェイに固定されたままの状態、クライアントからのtracerouteで出口経路、リゾルバーへの問い合わせでどのサーバーが答えたか。

次にフラップさせます。プライマリを三十秒上げ、三十秒下げるのを二回。トラフィックがすべての遷移を追うなら、しきい値が厳しすぎるか階層が間違っています。自分の予定で直してください、そうでなければプロバイダーがその予定で直します。

最後に、ルーターをまだ管理できることを確認します。コンソールケーブル、管理VLAN、セルラーモデムといった帯域外の経路を用意してください。あなたを締め出すフェイルオーバーテストは完了できないテストであり、到達不能なルーターは自力で戻れません。

ポリシーを完了と呼ぶ前に、端末を開かずに四つの問いに答えられるべきです:トンネルが落ちている間どのVLANがWANを使えるか、検出器は何を見てどれだけ待つか、どのネームサーバーとIPv6ルートが経路とともに動くか、バックアップも失敗したときどう戻るか。どの答えかが「既定値が何であれ」なら、ポリシーはまだあなたのものではなくルーターのものです。

関連記事