UDP の VPN がアイドルで止まる：ファイアウォールがフローを忘れていた

VPN は接続してしばらく動いたあと、クライアントがセッションを表示したままトラフィックを通さなくなる。再接続すると直るので、クライアントの不具合に見える。たいていはファイアウォールか NAT 機器がアイドル状態の UDP マッピングを破棄し、トンネルがまだ存在することを知らないのだ。

症状は診断できるほど一貫しており、負荷時ではなく無通信のあとに現れる。

アイドルによる停止の見え方

説明するのではなく測定する。トラフィックが止まるまでトンネルがどれだけアイドルだったか、新しい外向きパケットで復活するか、クライアントのインターフェースがまだアドレスを保持しているかを記録する。クライアントからの新しい要求は通るのに既存フローへの応答が通らないなら、疑わしいのはマッピングだ。再接続するまで何も通らないなら、クライアントのセッション状態も失われている。

どちらもアイドルが関係しており、必要な対処は異なる。

何かを変える前に時間を書き留める。アイドル約十分で止まるという報告は検証できるが、ランダムに切れるという報告は検証できない。この違いが、タイマーを追うのか経路変更を追うのかを決める。

忘れた機器を特定する

同じフローの状態を保持できる機器は複数あり、ローカルルーター、上流の変換装置、クラウドの境界、ホストのファイアウォールだ。それぞれに独自のタイマーがあり、最短のものが勝つ。五分の停止は通常、一台だけ他より極端に短く設定されていることを意味する。

文書化された既定値が自分の経路のタイムアウトだと思わないこと。それは一台の機器の既定値にすぎない。

• 家庭用ルーター：多くの場合数分、ときにはそれよりずっと短い。
• クラウド NAT やロードバランサー：UDP 専用のアイドルタイムアウトの文書値を調べる。
• ホストのファイアウォール：netfilter の追跡タイマーはフローごとに適用される。

実際の経路でタイマーを確認する

Linux では netfilter の追跡タイマーは表示も調整もできる： sysctl net.netfilter.nf_conntrack_udp_timeout と net.netfilter.nf_conntrack_udp_timeout_stream。二つ目は両方向でトラフィックが見られたあとに適用されるため、確立済みのトンネルは単なるプローブより長く生きられる。

RFC 4787 は UDP NAT の挙動と推奨最小値を定めている。ベンダーの既定値が異常に短く見えるときに引用する典拠だ。

Keepalive と再接続は別の道具

Keepalive はマッピングを生かし続け、再接続は死んだセッションを作り直す。両者は別の障害を解くもので、入れ替え可能な速度設定ではない。WireGuard の PersistentKeepalive は一定間隔でパケットを送り、NAT の紐付けを開いたままにする。OpenVPN の keepalive オプションも独自のやり方で同じ役割を果たす。途中の機器がすでにフローを忘れて両方向を捨てているなら、どちらも役に立たない。

極端に頻繁なプローブは、間違った境界を直さないまま作業を増やすだけだ。

ページの再読み込みではなく新しい要求で検証する

タイマーを変えたり keepalive を足したりしたら、アイドルのシナリオを以前とまったく同じに繰り返す。そのうえで、対象アプリケーションから本当に新しい要求を出す。すでに読み込まれていたブラウザーのタブはキャッシュから描画されることがあり、何も教えてくれない。

停止が続くなら、一ホップ外側へ移ってその機器の状態テーブルを確認する。