VPNでSSHが毎分切れる？原因はkeepaliveではない

SSHは接続して一分ほど動き、その後ほぼ同じ間隔で毎回固まります。よくある説明はアイドルタイムアウトなので、人はMTUを下げ、クライアントのkeepaliveを設定します。私が作業したWireGuardのリンクはすでにそのすべてを試していました。より小さいトンネルMTU、client-alive設定、設定済みのトンネルkeepaliveです。切断は変わらず続きました。原因は非対称なLANルートで、このパターンはタイマーに基づくあらゆる修正を打ち負かすため、見分ける価値があります。

keepaliveはホストがまだ送信する意思があることを証明します。しかし、決して通過しない応答を状態保持デバイスに見せることはできません。

神話：keepaliveは静かな切断を直す

SSHのkeepaliveには一つの役割しかありません。沈黙を数える何かがアイドル状態のセッションを回収するのを防ぐことです。それはうまく機能します。一方通行で最初のパケットを見た後、応答を一度も見なかった状態保持デバイスには効きません。クライアントが送るものは、応答がどのインターフェースを使うかを変えないからです。

MTUの変更もよく使われる修正で、同じ失敗の仕方をします。MTUを下げるとフラグメンテーションやパスMTUの問題には効きますが、ルートには何もしません。タイマーとMTUがすでに妥当で、切断が依然として同じ間隔で起きるなら、その間隔はどこかのタイムアウトを語っており、パケットサイズの話ではありません。間隔を書き留め、経路上の各デバイスの状態タイムアウトと比べてください。

手がかりは規則性と、その間隔の中でセッションが使える状態を保つことの組み合わせです。アイドルタイムアウトは何も起きないときに襲います。これは入力中に襲います。

余分なゲートウェイが実際に何をするか

ノートPCとVPNゲートウェイを同じLANに置き、別のLANファイアウォールをデフォルトゲートウェイにします。ノートPCはVPN向けのトラフィックをファイアウォールへ送り、ファイアウォールはそれをゲートウェイへ転送し、ゲートウェイの応答はLANをそのまま戻ってノートPCに届く。その二番目の区間はファイアウォールを通らないため、状態テーブルは接続の半分しか持ちません。

以下のアドレスはその配置を反映しています。

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

リダイレクトと状態処理が、機能するハンドシェイクを、即座ではなく後で死ぬ接続に変えます。遅延は状態エントリの失効か、より厳しい検査の失敗であり、だからこそ間隔がこれほど機械的に見えるのです。

これらいずれもクライアント設定には現れません。だからその調査はたいてい間違ったファイルから始まります。

意図した経路を一つ選ぶ

上の配置では、リモートサブネットをVPNゲートウェイへ直接ルーティングすれば半分の接続が消えます。

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

これらは例示アドレスです。次のホップはあなたのLANから到達可能でなければならず、プレフィックスは意図したリモートネットワークでなければならず、二番目のコマンドはそれを信頼する前に結果を示します。ゲートウェイがあなたのサブネットにないなら、このルートは望む修正ではありません。

ファイアウォールがそれらのシステム間のトラフィックを監視するためのものなら、それを迂回するルーティングは誤った設計です。代わりに両方向を境界に通し、戻り経路が一致するように各側のルートを設定してください。目的は状態検査を減らすことではなく、意図した単一の経路です。

Netgateの非対称ルーティングに関するメモは同じインターフェースレベルの非対称性とそれが生む状態問題を説明しているので、状態処理を全体で緩める前に読んでください。この事例に似た定時の切断はそれ自体では証拠になりません。記事を一つの失敗モードの説明として扱い、全体の状態ポリシーを変える前に自分のネットワークがそれに当てはまることを証明してください。

両端から試す

ノートPCから宛先へのルートと、宛先からノートPCへの戻りルートを読みます。これは二つの別々の判断で、おそらく片方だけが誤っています。ゲートウェイ自身からのpingが成功しても問題を完全に隠せます。経路がすでに正しい機械から出ているからです。実際のセッションの両端が見る両方向が必要です。

修正後はSSHを開き直し、以前失敗した間隔をはるかに超えてセッションを開いたままにします。その後、承認されたネットワーク設定でルートを永続化してください。一度きりのコマンドは再起動の計画ではなく、次回の再起動で問題が新しい謎を伴って戻ってきます。

非対称性が問題ない場合

非対称ルーティングは多くのネットワークで正常であり、定義上壊れているわけではありません。状態追跡、変換、ポリシーが見えない経路を見ることに依存するときに問題になります。それぞれに異なる対処法があります。その周りを再設計する前に、中間デバイスが実際に何を必要とするかを確認してください。

持続する答えは、二つの経路、両方を見る必要があるデバイス、それを可能にするルートを名指しします。デバイスを名指しできないなら、まだ原因を見つけていません。