DHCP更新後にVPNが切れる？アドレスを比較する

リース更新とVPN障害はログで一緒に現れることが多く、人は一方が他方を引き起こしたと結論づけます。タイミングの一致は事実ですが、因果関係は通常ありません。更新はリースを発行したサーバーへのユニキャスト要求で、同じバインディングの継続を求め、サーバーはクライアントがアドレスを一つも変えずに延長できます。事象の前後でクライアント自身の値を確認すれば、静かに更新されたリースと、稼働中のトンネルの下で本当に変化したネットワークを切り分けられます。

切断したクライアントから始める

まずクライアントの接続ログを開き、切断時刻を秒単位で記録したうえで、同じ分のOSのネットワークログを開き、インターフェースが何をしたかを順に読みます。この順序が調査のすべてです。切断前のDHCPイベント、DHCPイベント前の切断、間に何もない二つのイベントは、それぞれ別の所見です。トンネルがすでに再接続している最中にリースだけに触れたログ行は、飾りであって証拠ではありません。

タイムラインは記憶に留めず、その都度書き留めます。異なるツールのタイムスタンプはめったに完全には一致せず、そのずれ自体が説明になることもあります。

事象前後の四つの値を比較する

四つの値は、インターフェースのアドレス、デフォルトゲートウェイ、リゾルバーの一覧、インターフェースの動作状態という、接続のローカル側を実変化の検出に足る程度に表します。切断後一分以内に取得し、トンネルが健全だったときの取得結果と比較してください。

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

アドレスが変わらずゲートウェイも変わらずリゾルバーの一覧だけが変わった場合は、ルーティングではなく名前解決を示し、アプリケーションがホストを見つけられなくなっただけでトンネルは生き残っている可能性があります。ゲートウェイが変わった場合はローカルネットワークからの出口経路が移動しており、以前を指していたルートを無効にするのに十分です。四つの値すべてが健全時の取得結果と一致するなら、リースは原因ではなく、クライアント自身の再接続ロジックが主題になります。障害が見えている間に比較を取得してください（再起動後に取った健全な結果はアドレス履歴が異なり、一致しないためです）。

更新が変えられることと変えられないこと

RFC 2131 は更新を、リース時間の半分で元のサーバーへ送る要求として説明し、最初の試行に応答がなければ八分の七の時点で任意のサーバーへ再バインドするとしています。どちらの段階もクライアントが別のアドレスを取得することを要求せず、協力的なサーバーは通常既存のバインディングを延長します。実際のアドレス変更は通常別の経路で起こり、サーバーが更新を拒否する、クライアントが状態を失ってやり直す、ネットワークが機器を別のセグメントへ移す、のいずれかです。

接続の公開側はローカルの変化がまったくなくても変わり得ます。キャリアグレード変換の背後では、VPNのピアが見るアドレスがローカルのリースの動きとは無関係に再割り当てされることがあり、その再割り当てはクライアントの内側からはローカルネットワーク障害とまったく同じに見えます。ローカルで報告されたアドレスとピア側の観測を比較することだけが両者を切り分けます。

クライアントが適応できないとき

トランスポートを古いアドレスに結び付けたり、ピアへの古いルートをキャッシュしたり、インターフェース識別子を保存したりしたクライアントは、もはや存在しない経路を再試行し続けることがあります。これは適応の欠陥であり、ホストがもう到達できないアドレスへの再送が繰り返される形で現れます。設計上それを扱うクライアントもあり、たとえばWireGuardは、正しく認証されたパケットが新しい送信元から届くとピアのエンドポイントを更新します。

サービスを復旧させる手動再起動は、適応がどこで失敗したかの手がかりであり、リースとトンネルが相容れない証拠ではありません。試験中はブロック方針を維持してください、さもなければ試験自体が別の原因の障害になります。クライアントが自力で復旧したか、どれだけかかったか、どのアドレスを再試行したかを記録すると、その順序は、インターフェースに表示される切断理由より多くを語ります。

責める前に事象を再現する

スケジュールを待つのではなく、リースを解放して更新するか、同等の制御された事象を強制し、トンネルが生き残るか観察して条件を再現してください。管理されたネットワークでは、恣意的な静的割り当てがそのアドレスをすでに持つ機器と衝突する可能性があるため、アドレス変更は必ずネットワーク所有者と調整してください。

サポートされた修正の後、同じ事象を繰り返し、そのうえでアプリケーションと名前解決を試してください（再接続してもDNSを壊すトンネルは、重要な試験より弱い試験を通ってしまうためです）。予定されたリースを原因と名指しするのではなく、観測した具体的な変化をタイムスタンプとともに報告してください。二つの報告の違いは、次の人が障害を再現できるか、うわさだけしか再現できないかです。