サイトトンネル復旧後のフォールバックリース：更新するか待つか

サイト回線は稼働し、トンネルも確立しているのに、支店の PC はファイルサーバーに到達できません。障害の間には二つの時計が動いており、そのうち一つだけが終わっています。暗号化された経路が戻ったときにトンネルは復旧し、各クライアントのアドレスは、現在のリースが終了するか置き換わったときに復旧します。この二つの時間軸を比べれば、ファイアウォールのログを読むより速くずれを説明できます。

二つの時計、そのうち一つはトンネルではない

VPN 上の DHCP とローカルフォールバックを併用すると、リモートの DHCP 経路が使えない間、機器は一時的なローカルリースを配布できます。一時的な期間は通常分単位で数えられ、問題を隠すには十分短く、短い障害を乗り切るには十分長くなっています。トンネルが戻ると、フォールバックはそのリースの提供を止めます。ただしクライアントに入り込んで、すでに保持しているリースを取り消すことはしません。そのクライアントは更新か期限切れまでアドレス、マスク、ゲートウェイ、リゾルバーを保持し続けるため、健全なトンネルと壊れたデスクトップがリースの残り期間だけ共存できます。

実装とソフトウェアのバージョンはこの記述に紐づけておいてください。タイマー名や既定値は SonicOS のリリースごとに異なり、古いインターフェースは新しいものが何をするかの証明にはなりません。

二つの復旧手段を比較する

手段 A は待つことです。コストもリスクもなく、各クライアントに自分の予定で更新させます。手段 B は影響を受けたクライアントで強制的に解放と更新を行うことで、目的のアドレスはすぐに得られますが、クライアントの作業をすべて中断します。単一のデスクトップなら、強制更新が通常は速い経路で、正当化も容易です。ラボや取引の途中にある POS 端末では待機が安全な選択であり、営業時間外に予定した更新はどちらよりも優れています。

ipconfig /all
ipconfig /release
ipconfig /renew

何かを解放する前に出力を読んでください。アドレス、ゲートウェイ、DNS がすでに通常のスコープと一致していれば、クライアントは自力で復旧しており、残る問題は別の場所にあります。Linux クライアントでは、そうしないとマネージャーが次のイベントで変更を書き戻してしまうため、手で書き換えたアドレスではなくネットワークマネージャー経由のリース解放と更新が相当します。

アドレスだけでなくオファーを読む

アドレスだけでは誰が提供したかは分かりません。重要なのはオファー内のサーバー識別子、リース時間、そしてゲートウェイとリゾルバーがフォールバックのスコープと一致するか通常のスコープと一致するかです。

tcpdump -ni any 'port 67 or port 68'

静かなインターフェースはクライアントが一度も要求しなかったことを示すので、更新の間にキャプチャしてください。トンネルが稼働しているのにオファーがローカルフォールバックから来るなら、選択ロジックは依然としてリモート経路を利用不可と見ており、クライアントで更新を強制しても同じ結果を繰り返すだけです。キャプチャは同じ時計の上でトンネルのイベントと相関させてください。クライアントの要求の数秒前に終わる鍵更新や短い切断はもっともな原因であり、きれいなトンネルなのにフォールバックの応答が返るのは選択経路の設定問題です。

比較が逆転する場所

多くのクライアントが一度に影響を受けるなら、クライアントごとの更新は中断の列とサポートへの電話になります。その場合は、集団がまとめて復旧したのであり、またまとめて復旧するのだから、クライアントではなくフォールバックのスコープと復旧手順を見てください。

近隣が正常なのに一つのクライアントだけが影響を受けているなら逆で、そのクライアントのリース、予約、あるいは自身の DHCP クライアントの挙動が変数であり、サイト全体の変更は誤った道具です。

静的アドレスと予約には第三の答えが必要です。アドレスに固定されたクライアントは更新では救えませんし、フォールバックのスコープと衝突する予約は、二つのアドレス計画を比べるまでルーティング障害のように見える重複を生みます。

出口の手順を書き留める

フォールバックが何のためのものか、クライアントが一時アドレスをどれだけ保持できるか、営業時間中に誰が更新を強制できるかを前もって決めてください。答えは、当番のエンジニアが見つけられる場所、スコープ定義の隣に書いてください。そのうえで一度だけ意図的に、トンネルを落としてクライアントが何を受け取るかを見、トンネルを戻し、通常の設定を取り戻すまでの時間を記録します。その一度の演習が、次にサイト回線が揺らぐときの推測の大半を置き換えます。

最後に確認するのはアドレスではなくリソースです。ファイルサーバーに到達すること、その名前を解決すること、インターネットに到達することは三つの独立した確認であり、疑われなかったのは最後の一つだけです。