アイドル時のVPN切断を直す：Wi-Fi省電力のチェックリスト

ノートPCをしばらく触らずに置いておくとトンネルが切れ、トラックパッドに触れた瞬間に戻る。このパターンは、VPNゲートウェイが認証情報を拒否しているのではなく、無線リンクが省電力に入っていることを示している。同じプロファイルで忙しい朝はその証拠で、トラフィックが流れている間はトンネルが生き、無線が静かになると切れる。以下のチェックを順番に進め、最初に失敗したところで止まり、それから初めて設定を一つ変えてほしい。

チェック一：切断はアイドルに追随するか

まず相関を仮定せずに証明する。最後に送ったパケットの壁時計時刻、クライアントがトンネル断を報告した時刻、その間に画面が消えたかどうかを記録する。隔たりが毎回同じならアイドル経路の問題であり、アクティブ使用中に不規則に切れるならチェック五へ進む。

元に戻すのに何もかからない安いテストとして、二十分間ゲートウェイへ低レートのpingを一定間隔で送り、マシンは放置する。その間ずっとトンネルが保てば、一定の小さなトラフィックが症状を直しているのではなく覆い隠していることになり、それも有用な証拠だ。私はそのping出力を下書き用ターミナルに残し、後でクライアントのログと突き合わせる。二つの時計はめったに一致しないからだ。

チェック二：VPNのトラフィックだけか

トンネルを疑う前に、リンク自体がまだ使えるかを確かめる。トンネルは死んでいるが画面はまだ消えている状態で、アクセスポイントのアドレスと公開ホストへIPで到達を試す。普通のpingも失敗するなら、無線かアクセスポイントがあなたを落としたのであり、VPNクライアントは傍観者にすぎない。

トンネルが黙っているのに通常のトラフィックが流れているなら、リンクは健全で、問題はトンネル自身のタイマーか、クライアントの復帰の扱いにある。これは別々の修正なので、この手順を飛ばさないでほしい。Wi-FiとEthernetの両方があるノートPCでは、ケーブルを抜いて同じアイドルテストを繰り返す。有線Ethernetで消えるアイドル切断は、無線層の強い証拠になる。

チェック三：省電力状態を読む

ほとんどのデスクトップ環境はチェックボックスを用意しているが、そのチェックボックスはドライバが実際にいる状態ではない。まずドライバ自身のレポートを読み、それから判断する。mac80211を使うLinuxでは、インターフェースが直接答えてくれる。

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

二つ目のコマンドはテストであって修正ではない。切断やサスペンド、再起動を越えて残らないので、恒久的な変更を残さずに仮説を確かめるきれいな方法になる。

Windows ではpowercfg /q SCHEME_CURRENTがアクティブな電源プランを出力し、無線アダプターのサブツリーはアダプターに省電力を指示できるかどうかを示す。同じ選択肢はデバイスマネージャーのアダプターの電源管理タブにもある。macOSではインターフェースごとの802.11省電力は公開されていないので、代わりにpmset -gでスリープとスタンバイの挙動を見てほしい。そこでは多くの場合、無線のアイドル挙動ではなくスリープと復帰の経路が原因だと分かる。

チェック四：一つだけ変えて、再テストする

一回の実行で変える変数は正確に一つにし、同じ作業負荷を繰り返す。省電力を切った状態でトンネルがアイドル一時間を耐えたなら、本当のことを学んだことになる。それでも切れるなら、次の案を試す前に元に戻す。そうしないと、重なり合う三つの設定だけが残り、どれが効くのか分からなくなる。

キープアライブはもう一つの独立変数で、省電力としょっちゅう混同される。WireGuardのPersistentKeepalive = 25はNATマッピングを温め続ける。OpenVPNは両端でkeepaliveとping-restartを使う。どちらも、そうでなければ静かなトンネルにトラフィックを流すので、切断を直したように見えるキープアライブが、無線の問題を解決するのではなく隠している可能性がある。別々に、一つずつ試してほしい。

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

チェック五：無線が無実のとき

省電力を切り、キープアライブを入れた状態でもアイドル切断が続くなら、ノートPCの外を見る。アクセスポイントや家庭用ルーターは、アイドル状態のNATやセッションのエントリを独自のスケジュールで失効させ、VPNサーバーはトラフィックのないセッションを落とすことがある。同じSSIDを共有するアクセスポイント間のローミングも、クライアントがはっきり言わないままリンクをリセットしうる。

次に、同じネットワークで同じアイドルテストをする二台目の機器と比べる。二台が同じ間隔で切れるなら経路かサーバーの話であり、一台だけ切れるならローカルのドライバか電力の話だ。この比較は十分で済み、間違った設定を書き直す手間を省いてくれる。

恒久化する前に

何を残すかを決める。切断が見られたネットワークでだけ省電力を切るプロファイル別スクリプトは妥当だ。どのネットワークでもバッテリー時間を代償に全部を切るグローバルな調整は、たいてい妥当ではない。

• 元の省電力値をスクリプトのそばに記録し、復元できるようにする。
• ドライバやクライアントを更新するたびにアイドルテストをやり直す。既定値は変わる。
• 問題を報告するときは、pingのログとクライアントのログを一緒に残す。
• 二つ目の手順が失敗したなら、VPN設定の変更をやめ、ローカルのリンク障害として扱う。

一つだけやるなら、チェック二をやってほしい。このリストの残りが自分に当てはまるかを決めるのはこれであり、答えは省電力だと決めつけた人が飛ばすのもこの手順だ。