VPNが何度も切れる：サーバーより先に無線を調べる

VPNの切断は、通信がサーバーに届くよりずっと前に始まることがある。Wi-Fiの喪失、Wi-Fiから携帯網への切り替え、ローカルアクセスポイントの混雑、端末のスリープは、いずれも外側の経路を途切れさせうる。トンネルソフトがきれいな失敗を報告していても、端末から外へ向かって歩くべきで、まずリンク、次にクライアント自身のイベント、その次に統制された比較、そして最後にサーバーだ。その順序なら、部屋の中にある問題のために出口ノードを変えずにすむ。

信号アイコンではなくリンクを見る

信号のバーではなく、リンクの切り替わりを見よう。アクセスポイントが飽和しているとき、ローミングの切り替えが進行中のとき、画面オフ中に省電力ポリシーが無線を止めているときにも、端末は強い信号を表示しうる。

インターフェースの状態、現在のゲートウェイ、各変化の時刻を記録する。そのうえで、切断が切り替わりと一致するか確認しよう。電話が部屋間を移動するたびに起きる切断は、アプリがどのサーバーを表示していても、反証がない限りリンクの問題だ。

クライアント自身の再接続イベントを読む

ほとんどのクライアントは、切断の理由と次の試行の時刻を記録する。数秒で再交渉してから動くトンネルは、手動で切り替えるまで落ちたままのトンネルとは別の出来事だ。

短い再接続の繰り返しは、クライアントがサーバーに届き続けてセッションを失うため、外側の経路を指す。落ちたままのトンネルは、クライアントが何かを失うほど遠くまで届かないため、認証、エンドポイントの変更、ポリシーを指す。設定に触れる前に、二つのパターンを別々に読もう。

二つ目のエンドポイントを慎重に比較する

二つ目のエンドポイントは有用な比較であり、それ自体は統制された実験ではない。経路、インフラ、そして多くの場合に国まで変わるので、二つのエンドポイントの差は、最初のサーバーが故障している証拠にはならない。

端末、アクセス網、作業負荷を固定し、切り替えたときに他に何が変わったかを記録する。両方のエンドポイントが同じ場所で同じ時刻に失敗するなら、ローカル経路が共通因子だ。片方だけが失敗するなら、サーバーまたはそこへの経路が有力候補になる。結論が証拠を追い越さないよう、交絡因子を書き留めておこう。

運用中のサーバーと相関させる

エンドポイントを運用しているなら、試行時刻をリスナーと関連付けの記録に照合する。同じゲートウェイで複数の無関係なクライアントが失敗することは、移動のたびに一台の電話が落ちることとは別の証拠だ。

ピアの応答が一つあるだけではアプリケーションの継続的な健全性は確立できず、復旧後は実際に必要なリソースを試すべきだ。ハンドシェイクの成功と到達可能なサーバーは、壊れたアプリケーション経路と共存しうる。

範囲を絞る報告書を書く

四つの命題、すなわちローカルのリンク喪失、外側への到達性、トンネルの交渉、アプリケーション自身の状態を分けよう。それぞれに独自の証拠があり、それらを分けたままにする報告書は、次に読む人へどこを見るべきかを伝える。

比較の限界も記録しよう。ポリシーが直接経路の試験を妨げたなら、エンドポイント比較を証拠として示すのではなく、そう述べる。アプリの国ラベルは完全な経路を示さず、地理的に近いサーバーでも混雑した経路を通って到達することがある。

WireGuardプロジェクトの既知の制限のページは、プロトコルが正しくてもリンクの挙動をオペレーティングシステムに委ねうることを思い出させてくれるので、次の切断のあとに同じ試験を繰り返して締めくくろう。単一の出来事はデータ点であり、パターンは診断なのだから。