毎時のOpenVPN切断：再ネゴシエーションか、本当の再接続か

六十分、三十分、あるいは百二十分：きりのよい間隔で起きる切断は、ほぼ決してネットワークのせいではない。OpenVPN はデータチャネルを保護する鍵素材をタイマーで更新しており、想定より短いタイマーは失敗し続ける回線とまったく同じに見える。利用者は切れた接続を報告するが、ログは鍵交換の成功を報告する。以下の手順はその更新を本当の再起動から切り分け、実際に有効な値を読み、コストを明示したうえで初めて変更する。

最初の手順がこのページの残りが自分に当てはまるかどうかを決めるため、手順は順番どおりに進めてほしい。先に飛ばすと、関係のない不具合のために一晩タイマーを調整することになる。

有効なタイマーを読む、自分のファイルではなく

ログ行が診断のすべてだ。再ネゴシエーションは同じトンネル内でソフトリセットを書き、続いて新しい鍵交換を行うため、インターフェースはアドレスを保ち、ルートは再追加されず、確立済みのTCPセッションは通常は一時停止で生き残る。本当の再起動はセッションを切り裂き、インターフェースを作り直し、別のクライアントアドレスを割り当てることがあり、長期間の接続をすべて殺す。どちらの出来事も普通のことであり、落ちた通話を説明するのはそのうち片方だけである。

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

バージョンの行が重要なのは、ログの文言がリリース間で変わり、2.3で覚えたメッセージが2.6では別の言い回しになっていることがあるからだ。他人のフォーラムの抜粋ではなく、自分のログを読んでほしい。助けを求めるときは、言い換えで出来事を特定する細部が失われるため、正確な行を引用してほしい。出来事の前後でインターフェースのアドレスが変わらず、セッション一覧が生き残っていれば、それは更新であり、残りの節が当てはまる。

ソフトリセットと再起動を見分ける

reneg-sec はデータチャネルの再ネゴシエーションの間隔を秒で表したもので、既定値は3600だ。各ピアが自分の値を持ち、実際に更新を起こすのは二つのうち小さいほうである。この一つの規則がほとんどの報告を説明し、大きな数を設定したクライアントプロファイルでも、サーバーが既定値を保っていれば毎時リセットされる。

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

クライアントのファイルから結論を出す前に、サーバーの有効な設定も、それがプッシュするものすべてを含めて読んでほしい。次に詳細度を上げて一つの間隔を最初から最後まで観察すると、レベル3でもう再ネゴシエーションの行が表示され、タイムスタンプはその出来事が3600秒ごとに繰り返すのか、それとも活動に従うのかを教えてくれる。

実際にプッシュされる場所で変える

出回っている処方はクライアントプロファイルの一行だが、およそ半分の場合は間違った場所だ。ピアの低い値が勝つため、タイマーをゼロにしたクライアントでも、変更していないサーバーによって再ネゴシエーションされ得る。

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

プロファイルを中央で生成している場合は、配備済みのコピーではなくテンプレートを編集してほしい、さもなければ次のプロビジョニング実行で、いま削除した値が復元されてしまう。確認は一つではなく二つの間隔で行い、静かな一時間だけでは7200に設定したタイマーとも矛盾しないことを確かめてほしい。

混在した配備で何が起きるかも決めてほしい。変更を先にクライアントへ展開すると、サーバーがまだ更新を起こす窓が残るが、それは無害なものの、確認のためにログを見ていると混乱する。小さい値を持つ側を先に変えれば、症状は期待した地点で消える。

再ネゴシエーションを無効化して何を手放すか

定期的な再ネゴシエーションは、データチャネルの鍵の一組がどれだけ長く通信を守るかを制限する。タイマーを切ってもトンネルは壊れず、家庭用ルーターや小規模オフィスのゲートウェイでは実際の露出は控えめだ。それでも交換であり、実行する前にその交換を明示する価値がある。変わるのは一組の鍵がセッションを守る長さであって、トンネルがそもそも動くかどうかではない。

無効化が妥当なのは、切れる通話、張り直しが必要なリモートデスクトップセッション、最初からやり直しになるバックアップなど、再開できないものを壊すリセットの場合だ。停止が利用者に見えないなら、既定値を残しても何も失わず、与えられた鍵のローテーションを保てる。

パターンが許すなら原因を直すことを優先してほしい。最初のハンドシェイクは成功したのに途中で失敗する更新は、タイマーではなく経路を指し、より大きな制御チャネル交換でのパケットサイズ問題、フローを落とすステートフルファイアウォール、初回だけ成功する提案のいずれかを探すことになる。どれも、いま読んだ同じログに痕跡を残す。タイマーを切ると、その証拠が隠れる。

間隔が別の場所を指すとき

設定のなかの二人の隣人が、似た症状と異なる修正を生む。ping-restart は設定した期間なにも届かないとトンネルを再起動し、ping-exit はクライアントを完全に落とす。ログのどこにも再ネゴシエーションがない待機中の切断は、これらか、UDPマッピングを独自の予定で失効させたNAT装置に属する。

家庭用ルーター、モバイルホットスポット、キャリアグレードNATはいずれも、待機中のUDPセッションを誰にも告げずに失効させる。その障害は時計ではなく待機に従い、静かな十分のあとに切れて安定した通信の一時間を生き延びるセッションは、再ネゴシエーションしていない。

四つ目を変える前に、測定した間隔、見つけた有効な値、それを示したコマンドの三つを書き留めてほしい。タイマーを動かすと間隔も動けば、仕組みは特定され、修正は上の交換についての判断になる。動かなければ設定を戻し、keepalive、NATの状態、パケット損失を見続けてほしい。