OpenVPN が active (exited) と表示する？起動したインスタンスを探す

トンネルを確認し、systemctl status openvpn を実行すると、Main PID がなくプロセス一覧も空の active (exited) が返ります。自然な読み方はサービスが起動して死んだというもので、そのため unit を開いて /bin/true を見つけ、パッケージが壊れていると結論します。Debian のパッケージでは、その状態は設計どおりに動いている wrapper であり、トンネルはそれが起動するインスタンス unit のどれかで生きています。集約 unit はどのインスタンスがそれを作ったかを決して教えてくれません。

この unit で active (exited) が実際に意味するもの

パッケージされた unit は一回限りの処理です。その ExecStart は /bin/true で、終了した unit を active (exited) として報告し続けるのは RemainAfterExit=yes です。そのディレクティブを外すと、同じ成功した /bin/true の処理は inactive (dead) で終わり、これは人々が期待し、逆方向に誤読するまさにその状態です。コマンドは単なるプレースホルダーで unit は他の unit が行う作業について報告しており、この配置に壊れたところはなく、/bin/true を置き換えることはトンネルではなくパッケージングの契約を変えます。

wrapper は委譲します。パッケージ設定やその systemd ジェネレーターが供給するインスタンス unit を起動するので、空のプロセス一覧はトンネルについて何も証明しません。インスタンスが選ばれていない場合でも、wrapper は成功し、何も起動しません。状態が答えるのは wrapper が動いたかどうかで、トンネルが存在するかどうかではありません。

括弧内の語ではなく、status 出力の三行を読みます。Loaded は systemd が読んだ unit ファイルを示し、Active は最後の成功した実行のタイムスタンプを持ち、Main PID の不在は終了した一回限りの処理に合います。その三行は、起動の一秒後に落ちたサービスとこの wrapper を見分ける方法でもあります。

status をもう一度読む前に unit を一覧します

何が動いているかを尋ねる前に、何が存在するかを systemd に尋ねます。テンプレートがインストールされていてもインスタンスが作られていないことがあり、トンネルを持つのは作られた unit だけです。読み込まれた集合から始めます:

systemctl list-units 'openvpn*'

その一覧は systemd がこの瞬間に読み込んだもので、トンネルの目録に最も近いものです。インストールされた unit ファイルは別の問いに答え、何も作られていないときでもその一覧はテンプレートを示します:

systemctl list-unit-files 'openvpn*'

二つの一覧を一緒に読みます。二つ目にあるテンプレートと一つ目にあるインスタンスは別の答えだからです。存在するテンプレートと動いているインスタンスは同じ事実ではなく、二つ目だけがトンネルを意味します。パッケージの配置はディストリビューションや OpenVPN のバージョンによっても異なり、古い openvpn@ テンプレート、分かれた client と server の組、ディストリビューションの wrapper は、それぞれのパッケージで正当な場合があります。

見つけたチュートリアルではなく、自分のマシンに合わせます。他人の出力のインスタンス名が office でも、あなたのは home や work かもしれません。引き継ぐのは方法であって文字列ではありません。

インスタンス名をたどって、それが読むファイルへ進みます

upstream の client テンプレートでは unit の作業ディレクトリは /etc/openvpn/client で、そのコマンドはそこから %i.conf を取るので、openvpn-client@office は /etc/openvpn/client/office.conf を読みますので、例を信じるのではなく、インストールされた unit でその対応を確認してください。手元のテンプレートは古いか、ディストリビューションによる書き換えかもしれません:

systemctl cat [email protected]

その出力の末尾に現れる drop-in は、.d/ の下のファイルが ExecStart、作業ディレクトリ、設定パスを変えられるため読む価値があります。office.ovpn としてダウンロードしたプロファイルは インスタンスが開くファイル ではありません。このずれが、編集したことのないパスをエラーが示す通常の理由です。

プロファイル内の相対パスが次の罠です。メインのファイルを移動しながら ca、cert、key の参照を相対のままにすると、ファイルが見つからないエラーを別のファイルが見つからないエラーに取り替えるだけです。二つ目は確実に存在すると思っていたファイルを指すので、ファイル名よりプロファイルのディレクトリが重要になります。

それを起動し、そのインスタンスのジャーナルを読みます

いま調べたインスタンスを起動します。集約 unit のログにはトンネルのエラーが入らないので、この起動のジャーナルを読み、その順に設定エラー、ファイルアクセスエラー、接続エラーを探します。

sudo systemctl start [email protected]
journalctl -u [email protected] -b

起動と有効化は別の判断です: start は unit を今実行し、enable は次の起動を整え、enable --now は両方を一手で行います。daemon-reload は unit 定義を読み直すだけで、動いているプロセスを再起動せず、編集したプロファイルも適用しません。プロファイルを変えた後は、ファイルを読み直すインスタンスの再起動が必要です。

同じトンネルに二つ目のマネージャーを置かない

NetworkManager と OpenVPN 3 のセッションマネージャーは独自の接続状態を持ち、そのどちらかの隣に systemd インスタンスを置くと、同じトンネルに二人の所有者ができます。症状は、トンネルが上がって数秒後に置き換わる、または停止したままにならないことです。デスクトップ用にディストリビューションが文書化しているマネージャーを選び、サーバーでは意図的に systemd を使ってください。

インスタンスを起動する前に、既存の所有者を確認します。デスクトップのアプレットが接続を示しているとき、起動したインスタンスはそれを完成させるのではなく競合します。両方を動かして順序を願うのではなく、使っていないマネージャーを無効にしてください。その衝突は、トンネルが確立された後に、決して起動していないプロセスに壊されるジャーナルも説明します。

元の問いには、インスタンス名、それが読んだファイル、失敗したジャーナル行で答えます。OpenVPN の systemd 統合に関するメモ は、テンプレートの配置と、インスタンス名が解決されるファイル対応を説明しています。