TLS エラー後に OpenVPN が再試行を続ける：止める方法

クライアントは接続し、TLS ネゴシエーション中に失敗し、待機してから同じサーバーへ同じ結果で再試行します。失敗したプロセスを再起動するスーパーバイザーの下では、その試行はジャーナル内の終わらないループになり、最初の診断行は手の届かない場所へ流れていきます。OpenVPN には、そのネゴシエーション失敗を別の再試行ではなく目に見える終了に変えるオプションがあります。これは診断と監視のための設定であり、修理ではないので、プロセスを本当に停止させたままにできるポリシーと組み合わせてください。

最初のエラーを隠す循環

見えているのは一回の失敗ではなく繰り返されるブロックです：接続の試行、TLS エラー、休止、そして同じ順序。繰り返すたびに元の行はジャーナルの上へ押し上げられます。ユニットが失敗時に再起動するなら、誰も原因を読まないまま循環が何時間も続くことがあります。症状はループであり、根本的な不具合は一つのネゴシエーション問題です。

対話的なセッションは、一時的な失敗が次の試行で解消するかもしれないため、これを許容します。自動接続は同じ楽観を許されません：人間や監視が状態を見られるよう、プロセスは停止しなければなりません。

何かを変える前に、一つの完全な循環を記録してください。リモートアドレス、エラーで示された TLS の段階、プロセスがそもそも終了するかどうかを書き留めます。

ループの背後にある再試行の仕組み

再試行が既定なのは、無関係ないくつかのタイムアウトが同じ仕組みを共有しているからです。connect-retry は接続試行の間隔を設定し、connect-retry-max は各リモートエントリを試す頻度を制限でき、resolv-retry は名前解決の繰り返しを制御します。TLS ネゴシエーションの失敗はトランスポートのイベントとしてその仕組みに届くため、クライアントは報告せずに次の試行を予定します。既定値は不安定な回線には役立ち、治らない不具合には害になります。

--tls-exit オプションが変えるのはネゴシエーションの場合だけです。マニュアルはこれを TLS ネゴシエーション失敗時の終了と説明しており、あらゆるエラーでの終了より狭い範囲です。タイムアウト、リゾルバの失敗、認証の拒否はそれぞれ独自の動作を保ちます。

TLS 失敗時にクライアントを終了させる

クライアントが実際に読み込むプロファイルに tls-exit を置くか、起動時に --tls-exit を渡し、一度フォアグラウンドで実行します。終了ステータスと最後のログ行の両方を読んでください（スーパーバイザーが反応するのはステータスだからです）。ネゴシエーション失敗後の非ゼロ終了が意図した結果です。プロセスが終了せず再試行を続けるなら、そのオプションはクライアントが実際に読み込むプロファイルにありません。

その終了が見えるかどうかはスーパーバイザーが決めます。Restart=always や Restart=on-failure を持つ systemd ユニットはクライアントを再起動するので、ループは続き、オプションは何もしていないように見えます。クライアントを責める前にポリシーを確認してください：

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no はプロセスを停止させたままにし、Restart=on-failure は非ゼロのステータスの後でも再起動します。失敗を見えるようにしつつ、無関係なクラッシュからサービスを回復させたいなら、Restart=on-failure を設定し、再起動の嵐を止めるために StartLimitBurst と StartLimitIntervalSec を使ってください。次にユニットのステータスを読んで最後の終了コードを確認します：systemctl status がそれを報告し、ジャーナルは再起動より上に最初のエラーを保ちます。

決定はユニットかプロファイルのメモに書いてください。TLS 失敗で終了するプロファイルは、理由が記録されていなければ、次に触る人には事故に見えます。どの失敗がプロセスを止めるべきで、どれを再試行すべきかを明示してください。

使い捨てのエンドポイントで証明する

信頼する前に挙動を見るには、プロファイルをコピーし、コピーを TCP 接続は受け付けるが OpenVPN を一切話さないエンドポイントに向けます。応答してから黙るリスナーで十分です。tls-exit があれば、ハンドシェイクが失敗したときにクライアントは終了するはずで、なければ同じプロファイルは回り続けるはずです。使うのはコピーで、稼働中のプロファイルは使いません。

二回の実行は、それぞれがどれだけ続いたかではなく、終了ステータスと最初のエラー行で比べてください。ステータスはオプションが発火したかを、最初の行はどの段階が失敗したかを示します。

終わったらテスト用プロファイルを削除してください。意図的に間違ったエンドポイントを持つコピーは、後でディレクトリ内のすべてのプロファイルを起動する人にとって罠になります。

このオプションが決して届かない段階

認証の拒否は後の段階です。サーバーがアカウントを評価して拒否するなら、TLS はすでにネゴシエート済みなので tls-exit は発火しません。次に見るべきは認証の再試行設定で、サーバーの理由はクライアントの最後の行より重要です。誤ったパスワードと欠けた証明書は、クライアント側で似たメッセージを生むことがあります。

欠けたルート、誤ったリゾルバ、到達できないゲートウェイもこのオプションの外です：ネゴシエーションの失敗ではないからです。静かなパケット損失は最も分かりにくい例です：交換がどこまで進んだかによって、クライアントはネゴシエーション失敗を報告することも、単にタイムアウトすることもあります。

この区別をメモに残してください。この設定は修理ではなく診断と監視のためのものなので、暗号の不一致、証明書の問題、誤ったポートを直すものではありません。まず失敗したネゴシエーションの原因を直し、そのうえで即時の終了が配置にまだ適しているかを判断してください。