OpenVPN が「初期化完了」と表示する：プロンプトが戻らない理由

最後のログ行のあと端末が静かになっても、何も固まっていない。これは前面で動くクライアントの想定どおりの姿である。起動を終えたあとは、そこにとどまってトラフィックを運んでいる。シェルのプロンプトは、見た目ほど成功の証ではない。

このメッセージは起動と定常状態の境目として扱う。まさにそれを示しているからだ。

メッセージが示すのは起動の終わりであり、プロセスの終わりではない

OpenVPN がこの行を出すのは、デバイスを開き、インターフェースを設定し、ルートを登録し、相手との TLS 交換を終えた後である。そのあともプロセスは動き続ける。トンネルを開いたままにしてパケットを中継するのが仕事だからだ。前面で動くプログラムは、その仕事をしている間はプロンプトに戻らない。以降の出力が静かなのは正常で、何かが変わったときだけクライアントは話す。

この行が出たあとで接続が切れるなら、それは別の出来事であり、ログが後からそう告げる。

Ctrl+C は決断であって、修理ではない

Ctrl+C を押すと割り込みが送られ、クライアントはそれを停止要求として扱う。プロンプトが戻り、トンネルは消え、それを使っていたセッションは終わる。これは前進に見えて、実際は逆である。目的が常時接続なら、答えるべきは端末なしで動き続けられる場所へプロセスを移すことであって、中断ではない。

デバッグ中は前面に置いたままが正しい。後から起きるエラーが同じウィンドウに見え続けるからだ。静かな一分はどちらとも証明しない。出力を眺めるのではなく、トンネル越しに資源を試すこと。

メッセージが証明しないもの

完了はクライアント自身の設定についてのローカルな表明である。相手が応答するとも、入れたルートが必要なものと一致するとも、トンネル経由の名前解決が動くとも言っていない。分割トンネルのプロファイルは完全に初期化できていても、社内共有が到達できないままになることがある。ルートや DNS ポリシーがそこを覆っていなかったからだ。サーバー側のインスタンスも、クライアントを受け入れられる状態になると似た行を出すが、それはどれかのクライアントが接続していることとは違う。

「サーバーが起動した」と「ノートPCが共有を開ける」は別々の場所からの観察であり、これを混同すると間違ったホストをデバッグすることになる。

端末なしで動かす

常設の配備なら、そのプラットフォームが支えるサービス構成を使う。systemd のホストなら、プロファイルを /etc/openvpn/client に置いた openvpn-client@office のインスタンスで、再起動を越えるように起動と有効化を行う。Community OpenVPN には --log や --log-append と組み合わせる --daemon もあり、これはプロセスを切り離して出力をファイルへ送る。どちらの方法もプロセスの動き方を変えるが、ルートを直すわけでも、遠隔のアプリを健全にするわけでもない。

あるサービスがすでに管理しているインスタンスの隣で、二つ目を起動していないか確認する。同じプロファイルを奪い合う二つのクライアントは、紛らわしいログと、意図しなかった一つのトンネルを生む。

仕事に合う構成を選ぶ

診断には前面、セッションより長く生きる必要があるものにはサービス、頼れるサービス管理者がないときにはデーモンモード。この三つで通常の場合は足りるし、どれにも存在する明確な理由がある。うっかり一つを選ぶと、「ウィンドウを閉じるまで動く」という報告になる。

トンネルを残すつもりなら、あとで再起動後に戻ることと、ログが自分が見る場所に残ることを確かめる。初期化の行もそのログに現れるので、そのときには誰も端末を眺めている必要はない。