OpenConnect は切断された VPN をいつまで再試行すべきですか？

--reconnect-timeout は、トンネルが落ちた後、このクライアントプロセスが諦めて終了するまでどれだけ試行を続けるのかという一つの狭い問いに答えます。OpenConnect のマニュアルページ はこのオプションを、リンク喪失や応答をやめたピアの後の再試行について、文書化された既定値 300 秒とともに記録していますが、この数値は稼働中の一つのクライアントに対する期限であり、VPN が到達可能であり続ける証拠ではありません。また、プロセスを生かし続けるための方針でもなく、混乱の多くはここから始まります。

その上に第二の仕組みが乗ると、混乱はさらに増します。クライアントを再起動するスーパーバイザ、ゲートウェイに ping するプローブ、組み込みの再試行ウィンドウは、どれも一度の障害に反応し得るため、インシデントは誰にも整合できない三本のタイムラインを生みます。

再接続ウィンドウが実際に区切るもの

アクセスネットワークが数秒消えるところを想像してください。クライアントはリンクの切断を検知するか、死んだピアからの応答を聞かなくなり、保持できる状態を保ちながらセッションの再確立を始めます。再試行はゲートウェイが再び受け入れるかウィンドウが尽きるまで続き、尽きたウィンドウは非ゼロの終了コードで終わります。ライフサイクルの所有権がプロセスを監督する側へ移るのは、タイムアウト値ではなく、この終了の時点です。

ウィンドウは、プローブがどのくらいの頻度で走るかについては何も述べず、認証を延長することもできません。ゲートウェイがセッションを取り消した場合や、アカウントが新しい第二要素を要求するようになった場合、待ち時間を延ばしても古いセッションが再び有効になるわけではありません。再試行が実るのは、経路が戻り、ゲートウェイがセッションをまだ認識し、要求される資格情報が使える状態にあるときだけなので、この数値は生存間隔ではなく期限として読んでください。

ウィンドウは、その間アプリケーションが何をするかも規定しません。プラットフォームと障害の進み具合によって、クライアントはルートがまだ入ったまま再接続していることも、ルートが外された後に再接続していることもあります。だからこそ、障害の最中に出されたリクエストは、すぐ失敗するのではなくタイムアウトまでぶら下がりがちです。

スーパーバイザの再起動とクライアントの再試行は二つの層

動いているクライアントに自分のウィンドウを使わせ、終了にはサービスマネージャに反応させてください。systemd の下で再起動ポリシーを持つフォアグラウンドのクライアントは、一定期間は再試行し、そのあと再起動の判断を一度だけ行うという、まさにその分担を与えます。結果は、後からでも再構成できる一本のタイムラインになります。

バックグラウンドのクライアントに加えて、インターフェースが見えないときに別のコピーを起動する独立したポーラを置くのが、うまくいかないパターンです。すると両方のプロセスが同じデバイスノード、ルート、リゾルバ設定を奪い合うので、どうしてもデーモンが欲しいなら、クライアントが実際に起動するコマンドラインにそのオプションを置いてください。

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

その行には重みを持つ点が二つあります。--background はプロセスを切り離すので、pid ファイルがそれに対する唯一の確実な取っ手になり、タイムアウトはその同じプロセスが生きている間だけ消費され、それを殺すスーパーバイザは続行のための予算を残しません。

意図的な切断には独自の信号が要ります。計画的な一時停止と本当の障害は素朴な監視者には同じに見え、どちらも「接続していない」と読まれます。一時停止はスーパーバイザの停止操作か、ラッパーが理解するマーカーを通して行い、意図的な停止が誰も求めていない再起動を引き起こさないようにしてください。

引き継ぎが再試行ループと競合しないようにする

無人での復旧は、人の立ち会いなしに更新される資格情報に依存しており、対話的なデスクトップセッションの中でしか解錠されないキーリングや、常に手入力のコードを要求するトークンは、経路が戻った時点でクライアントを認証段階に足止めします。ウィンドウを延ばす前にそのワークフローを片付けてください。長いウィンドウは、同じブロックされたプロンプトに失敗する時間を与えるだけです。

プロンプトを減らすためにサーバ検証を緩めるべきではありません。ゲートウェイを検証するピンやトラストアンカーこそが自動再接続を安全にするのであって、証明書の質問を避けるためにそれを無効にすることは、目に見える中断を目に見えない中断と引き換えにすることです。検証済みの識別情報を保ち、代わりにプロンプトを直すべきであり、どのゲートウェイにも接続しようとするクライアントは立ち止まって待つものより悪いのです。

インターフェースの存在も健康の信号ではありません。トンネルデバイスは、その背後に死んだセッションを抱えて存在し得ますし、起動プロセスはトンネルがまったくなくても存在し得ます。これらの観察はどれも、実際のリクエストには耐えません。健康は、ユーザーが必要とするもの、たとえばトンネルを通って既知の内部サービスへ向かうリクエストから来なければなりません。

障害の最中と後に何を検証するか

四つの事象を別々のテストとして実行してください。ウィンドウより短い中断、それより長い障害、認証の失敗、意図的な停止のそれぞれが異なる予測可能な状態で終わるべきであり、最初の二つの境界こそが値を選ぶ理由のすべてです。

チェックは外に向け、プロセステーブルだけではほとんど証明できないので、短い切断の間は pid が安定しているかを見て、長い切断の後にはそれが消えて一度だけ置き換わったことを確認してください。

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

短い中断の間は、クライアントが早期に終了せず本当に再試行したこと、そしてルートとリゾルバのエントリが重複なく戻ったことを確認します。より長い障害では、きれいな終了と、その後にちょうど一度の再起動が続いたことを確認します。認証の失敗では、クライアントが拒否し続けるゲートウェイに対して空回りしていないことを確認します。pid が積み上がらず単一の値に戻ることも確認に加えてください。

意図的な停止では、ヘルス URL は到達不能なままで、プロセスは停止したままであるべきです。そのうえでアプリケーション側からループを閉じ、同じリクエストが、トンネルがない間は失敗し、戻った後は、あなたのポリシーが期待する送信元アドレスから成功しなければなりません。緑のトンネルアイコンは証拠ではありませんが、完了したリクエストは証拠です。