OpenVPN がエラーも出さずに起動しない？ジャーナルを確認

コマンドは戻り、サービスは失敗と表示され、説明らしきものは端末に届かない。この沈黙こそが人々が「OpenVPN が起動しない」と表現する症状であり、プログラムが何も言わずに死んだという意味であることはほとんどない。メッセージが読んでいないチャネルへ行ったか、起動したものが設定したものではなかったという意味だ。プロファイルを容疑者とみなすのをやめれば、どちらの場合も一分以内に診断できる。

出力を受け止める場所は四つある。ユニットのジャーナル、接続を所有しているプラグイン、トンネルの反対側、そして実行中だと思っているものとは別のバイナリで、それぞれに独自の確認方法がある。

沈黙は、正しいチャネルを見ていなかったという意味だ

前面で実行した呼び出しは端末に出力する。ユニットはジャーナルに出力し、失敗したユニットは、失敗が起動のされ方にあり、指示された内容にはない場合、何も書く前に終了することがある。この区別は重要で、ジャーナルに記録がなければプロセスは実際には動いておらず、記録が一つあってその後に終了していれば、動いて何かを拒否したということになる。

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

きれいな終了とシグナルを区別するには、次を使う: systemctl show -p Result -p ExecMainStatus openvpn-client@office。状態 1 と Result=exit-code はプログラムの判断であり、Result=signal やタイムアウトは代わりに環境を指し、プロファイルをどう編集してもそれは変わらない。何かを再起動する前に両方の値を記録しておくこと、再起動はそれらを生んだ一時的な状態を消してしまうからだ。

インスタンス名はパスの一部だ

パッケージ済みのテンプレートユニットはファイルパスを取らない。インスタンス名を取り、その名前をディレクトリに付加してプロファイルを探す: office は Debian と Ubuntu のパッケージでは /etc/openvpn/client/office.conf に解決される。office-v2.conf というファイルを @office として起動しても決して読まれず、ユニットは何もすることがなかったとみなして静かに終了する。検索ディレクトリはクライアントモードとサーバーモードで異なるため、テンプレートを切り替えると同じ間違いはまったく別の場所を指す。

この不一致が沈黙の失敗の最も一般的な原因であり、プロファイル自体は正常なのでプロファイルの中では見えない。実際に存在するものを列挙し、パッケージが期待する拡張子も含めて二つの名前を一文字ずつ比較する。

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

ユニットが有効なのにインスタンスが一つも一覧にない場合、有効化自体が後で改名された名前を指していることがある。正しいインスタンスを再度有効化すれば通常は足りるし、取り残された古いユニットファイルは次に触る人を混乱させないよう削除する価値がある。放置されたユニットファイルは小さなことで、後になって誰かの一時間を奪う。

プラグインがトンネルを所有しているとき、端末には何も見えない

デスクトップアプレットから開始した接続は NetworkManager が所有しており、その OpenVPN の出力は、開いているシェルではなくそのサービスのジャーナルに入る。手でクライアントを実行して何も見えないのはこの配置では想定内で、手で実行したプロセスが接続を運んでいるわけではないからだ。

ジャーナルでそれを所有するサービスを探し、その後、読める程度の詳細度でパースを再現する。下の二つのコマンドは、同じ失敗の別の所有者を見ている。

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

単独実行はメッセージを読むためのもので、管理された接続を置き換えるものではなく、両者はその後で異なり、DNS 統合、ルート、寿命はプラグインに属する。単独実行でパースエラーを直しても、アプレットが引き継いだ後に名前解決が自動で直るわけではないので、二つの観測は分けておくこと。

二つのバイナリ、一つの PATH

手動で構築したインストールが /usr/local の下にあると、シェルからの呼び出しでは勝つ、なぜなら /usr/local/sbin が Ubuntu の既定 PATH で /usr/sbin より前にあるからだ。ユニットはあなたの PATH を使わず、ExecStart に書かれた絶対パスを実行する。だから端末で動く版とサービスとして失敗する版は、本当に別のプログラムであり得る。

何かを再構築する前に二つを比較する。三番目のコマンドが議論を決める。

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

もう一つの環境差が同じ場所に隠れている。パッケージ済みのユニットは /run の下の実行時ディレクトリに依存しており、それは systemd がユニットのために作り、その設定を省いた手書きの代替ユニットは、ファイルを一つも開く前に失敗することがあり、その失敗は OpenVPN のメッセージを伴わない一般的な拒否に見える。

クライアントが報告できない失敗

結果の一部は遠い側で決まる。HTTP ステータスで応答して接続を閉じるゲートウェイは、自分の状態をすでに伝えており、次に有用なのはあなたのローカルファイルではなく、そのログか資格情報の背後にあるアカウントだ。そのシナリオではローカルに壊れたものはなく、埋め合わせにプロファイルを編集すると次の診断が難しくなる。クライアント設定に触る前にそのログを読むこと。

もう一つの沈黙のケースは、正しく動作しているクライアントだ。クライアントモードのトンネルは決してポートで待ち受けないので、開いたリスナーを期待する確認は何も報告せず、失敗のように見える。空のポート一覧から結論を出す前に、どのモードで起動したかを確認すること。

層を順番に調べる: ユニットが存在してインスタンス名が正しいか、ジャーナルか --log ファイルに何か届いたか、実際にどのバイナリとプロファイルが動いたか、失敗はローカルかリモートか。それぞれの答えが一つの層を取り除く。プロファイルから始めるのは、一度も開かれていないかもしれないファイルを書き直すことになる。