VPN が何度も切断される？この順番で切り分ける

クライアントを再インストールする前に、三つのことを書き留めます：トンネルがどれだけ維持されたか、切断時にクライアントが何を言ったか、その間にマシンがスリープしたかネットワークを切り替えたか、です。このメモが後で手元に残る唯一の証拠であり、再インストールはたいていそれを消します。繰り返し同じ間隔で切れるならタイマーか状態の失効、ランダムな時点で切れるなら経路の問題です。以下の順番なら、三つを同時に変えて何も学べない事態を避けられます。

第一段階：間隔とエラー文言を記録する

ベンダーのダッシュボードではなく、クライアント自身のログから始め、Linux クライアントなら、サービスのログとトンネルの現在の状態で大半が分かります。

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

アイコンが色を変えた瞬間だけでなく、最後に成功したハンドシェイクの時刻と通信が止まった瞬間を記録します。後から切断と言う GUI クライアントは、カーネルが数秒前に到達した状態を報告しているだけかもしれません。

エラーの文言はそのまま残します。タイムアウト、認証の拒否、アダプターやドライバーのエラーはそれぞれ別の層を指しており、この問題で無駄になる作業の多くは、それらを一つとして扱うことから生まれます。その行をそのままメモにコピーします。

第二段階：変えるのは一つだけ、プロファイルではない

デバイスとプロファイルは固定したまま、マシンを別のアクセスネットワーク（スマートフォンのテザリングなど）へ移します。クライアントを経路から切り離す最も安いテストであり、元の失敗間隔を覆うだけの時間をかけて実行します。安定した二分では、三十分目に起きる切断は何も証明できません。

Ethernet ポートのあるノート PC なら、Wi-Fi を完全に排除した第二の比較ができます。両方の代替経路でトンネルが持つなら、元のアクセスネットワークに注目すべきです：アクセスポイント間のローミング、変換テーブルが期限切れになる家庭用ルーター、長寿命フローをリセットする上流リンクなどです。

どの変数を変えたのかを書きます。比較が意味を持つのは他がすべて同じままであった場合だけで、そこにはサーバーのエンドポイントと時間帯も含まれます。

第三段階：間隔を層に対応づける

良好なセッションの長さは、手元にある最も情報量の多い単一の数字であり、タイマーに触る前にこの一覧と照らし合わせてください。

• スリープや復帰の後に切れる： トンネルの状態はサスペンドを越えたが、インターフェースは越えていません。復帰時の再接続の挙動と、サービスがトンネルを再起動するのか通信を待つのかを確認します。
• アイドル時だけ切れる： 途中の何かがフローの期限を切らしています。keepalive はまさにこの場合のためにあります。
• セッションの一定年齢で切れる： 再認証や鍵の更新のイベントであり、経路の障害ではありません。ちょうどその間隔でログに明示的な拒否があれば、それが手がかりです。
• 大きな転送や大きなページの間に切れる： MTU と分割を疑うべきで、アイドルタイマーではありません。

アイドルの場合は設定がプロトコルごとに異なり、両端の設定が重要です。サーバー側の OpenVPN の keepalive 10 60 は 10 秒ごとに ping を送り、ping がないまま 60 秒たつと接続を再開し、NAT の背後の WireGuard クライアントはピアブロックで PersistentKeepalive = 25 を使います。OpenVPN また、タイマーでデータチャネルを再ネゴシエートし、reneg-sec は 2.x では既定で 3600 秒です。

他のプロバイダーのガイドから攻撃的な値をコピーしないでください。損失のあるモバイル回線で短いタイムアウトは、防ぐはずだった切断をまさに生み、またサーバーから押し出される値は、クライアントプロファイルで設定した値を上書きします。

第四段階：対応している代替を一つ比較する

事業者が UDP と TCP の両方のプロファイルを公開しているなら、同じデバイスと同じネットワークで他方を試します。コピーしたプロファイルのトランスポートを編集するのではなく、実際に対応するファイルを使います。UDP がリセットされる経路で TCP プロファイルが安定していれば問題はその経路に絞られますが、TCP がどこでも優れたトランスポートだという証明にはなりません。

同じ論理はエンドポイントにも当てはまります。別のサーバーを試し、元の結果をその横に置いておきます。一つの出口だけでセッションがリセットされるなら、それはそのエンドポイントについての証拠であり、ノート PC のすべてのアダプターを作り直す理由ではありません。

切り替えた後は必ず元のトリガーを再現して通信が実際にどこへ行くのかを確認し、インターネットアクセスが戻ったことはトンネル内の通信と同じ結果ではないと心得てください。黙って直接経路に落ちたクライアントは ブラウザーからは正常に見えます。

修正を検証し、ロールバックを残す

修正は接続の成功ではなく元のトリガーの再現で検証し、そのうえで古い失敗間隔を超えてトンネルをアイドルにし、一度サスペンドと復帰を行ってから、ハンドシェイクの経過時間と出口アドレスを確認します。

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

新しい挙動が丸一日持ちこたえるまで、以前のプロファイルと以前のタイマー値を残します。切断が戻ったらバックアップを復元し、二回目の試行が既知の状態から始まるよう、変更を一つずつ再適用します。

ログがきれいなままで、トンネルが繰り返し同じ間隔で切れるなら、次の行き先はそのセッションのサーバー側です。クライアントのセッション識別子と正確な切断時刻を持って行きます。この二つが揃って初めてサーバーログを検索できるからであり、プロトコルのリンクオプションは OpenVPN 2.6 のマニュアル に記載されており、値の正確な意味が必要なときに参照できます。