vpnc が 24 分で切断される理由と変更すべき設定

トンネルが繰り返し同じ間隔で切れるなら、それは回線の不良ではなくタイマーが自らを報告しているのです。二十四分は 1440 秒で、プロファイルやヘッドエンドのポリシーが持つような丸い値です。すると同じ設定が毎回同じコンセントレータに対して失敗し、他のネットワークはすべて動作し、リンク試験をいくらしても変わりません。

どのタイマーが自分のものかは三つの条件で決まります：クライアントがアイドルセッションを諦めるか、鍵更新の交換が拒否されるか、変換ゲートウェイがカプセル化を書き換えたかです。

どのタイマーが切断を支配しているか

設定に触れる前に、少なくとも三回の再接続で間隔を測ります。数秒のばらつきはリンク損失や無線ローミングを示し、毎回同じ目印の数秒以内に収まる値はポリシー値を示します。セッションの長さはどちらが終了させたかも教えますが、それはクライアント側のタイムアウトとサーバ側の削除では、デバッグ出力の最終行が異なるからです。三回の再接続は、間隔がそもそもずれるかどうかも明らかにしますが、これは一回の測定ではわかりません。

話していたヘッドエンドの横にその数値を書き留めます。間隔が安定したら、残る作業は三つの原因からの選択であり、再接続ごとに一つだけ設定を変えることがそれらを区別可能に保ちます。

ケース一：クライアントがアイドルセッションを諦める

vpnc は独自のデッドピアチェックを実行し、そのチェックはコンセントレータがまだ生きていると考えるセッションを殺すことがあり、特に両者の間に変換ゲートウェイがある場合に起こります。ドキュメントにあるクライアント側の対処は、タイマーをローカルで無効にし、ピアが消えたかどうかをヘッドエンドに決めさせることです。以下の二行はどちらも vpnc プロファイルかコマンドラインに入れるもので、どちらも暗号化設定とは独立しています。

DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

クライアント DPD を無効にすると誤検知がなくなり、唯一のローカル検出もなくなるので、単独で適用し、間隔がそもそも変わるかを見ます。

ケース二：鍵更新が拒否される

DPD の変更後も間隔が残るなら、フェーズ 1 の鍵更新が候補になります。古い vpnc ビルドは現在のものより鍵更新の扱いが雑で、通常の不一致は Diffie-Hellman グループです。ヘッドエンドがすでに受け入れるグループを強制するには 一行と一回の再接続で済むため、ポリシー変更ではなく安価な実験になります。

IKE DH Group dh5

有効なグループ名は dh1、dh2、dh5 です。コンセントレータが拒否するグループは即座に失敗しますが、それも情報で、ヘッドエンドがうるさく、元のグループがおそらく正しかったことを示します。

ケース三：変換がカプセル化を書き換える

変換ゲートウェイの背後では、Cisco の UDP カプセル化と標準準拠モードは互換ではありません。誤った選択は、確立して通信を通し、負荷がかかるとタイムアウトするトンネルをしばしば生み、これは帯域の問題のように読めて実際にはそうではありません。モードだけを変え、再接続して切断までの時間を測り直します。もう一方のモードは最初の二つのケースを除外した後にだけ試します。

フロントエンドもここで混乱を加えます。NetworkManager はプラグインパッケージがインストールされるまで vpnc 接続タイプを提供せず、プラグインがない場合はエラーではなく灰色の「追加」ボタンとして現れます。KDE のフロントエンドは同じ値を独自のプロファイルに保持するので、デーモンが編集した内容を読んでいるか確認します。

コマンドラインからは問題なく接続できるのにデスクトップからできないプロファイルは、タイマーではなくフロントエンドの問題です。

三回目の変更の前に失敗する交換を確認する

デバッグ出力付きでクライアントを実行し、切断前の最後の交換を読みます。切断直前にフェーズ 1 の削除があれば、クライアントが鍵を更新して拒否されたことを意味します。同じ地点でフェーズ 2 の削除があれば、トンネルが反対側から破棄されたことを意味し、クライアント設定は原因ではありません。

vpnc --debug 3 office

トンネルは生きているのに通信が止まる場合は、二つ目のネットワークデーモンも確認します。ルーティングテーブルを書く 二つのマネージャは、デスクトップから同じ症状とまったく別のログを生みます。