OpenVPN は起動したのに何も出力しない：まず log-append を確認する

設定ファイルを指定してシェルから OpenVPN を起動すると、ターミナルは何も出力せずにそのまま止まります。バナーもエラーもプロンプトもありません。直感的には起動に失敗したと思うので、もう一つ、さらに一つとコピーを起動し、マシンには中途半端に設定されたインスタンスがいくつも残ります。その前に、プロファイルにログをすでに別の場所へリダイレクトしているディレクティブがないか確認してください。沈黙はコンソールの性質であり、プロセスの性質ではありません。

沈黙には大きく異なる二つの説明がある

一つは、プロセスが正常に動作していて、監視していないファイルに書き込んでいるというものです。もう一つは、同じファイルに記録されたエラーで直ちに終了したというものです。

どちらも空のターミナルを残しますが、両者を分ける問いは一つです—今プロセスがあるのか、書き込むよう指示されたファイルに何があるのか。設定に再び触れる前にそれを答えてください。出力を得るために再起動するのは、二つのインスタンスが一つのトンネルデバイスと同じポートを奪い合う結果になり、元の問題とは無関係なエラーを生みます。

ディレクティブを見つけ、次にプロセスを見つけてください。

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

実行中のプロセスが使う出力先を見つける

プロセスが実際に起動されたプロファイルを、編集したものではなく読んでください。サービス管理のインスタンスは通常別のパスを読み込み、別の作業ディレクトリで動くため、相対ファイル名は予想もしない場所で解決されます。

明示的な cd ディレクティブがあると、相対パスがディレクトリ変更とともに移動するため、その違いはさらに際立ちます。この設定を引き継いだ場合、ファイルは今では誰も探さない場所にあるかもしれません。

ファイルの更新時刻を起動した瞬間と比べてください。先週のログは先週についての証拠です。次に、変化したファイルの最後の行を読み、そこにあるものを、見落としていた起動メッセージとして扱ってください。

log と log-append：証拠と消去

log-append はファイルにすでにある内容に追加します。log はファイルを書き込み用に開いて切り詰めるので、両者を切り替えると、これから読もうとしていた実行が消えることがあります。

デバッグ中に誰かがディレクティブを変えたなら、以前の証拠はすでに消えており、ファイルのサイズは不自然に小さく見えるはずです。二つの実行を比べて何かが変わったと結論づける前に、それを知っておく価値があります。ログは意図して消すか残すかしてくださいが、どちらをしたのかは把握しておいてください。意図して消した証拠は、偶然失った証拠より説明しやすいからです。

どちらのオプションも存在しない親ディレクトリを作らず、ファイルシステムの権限やサービスのサンドボックスを通じてアクセスを与えることもありません。設定上は正しく見えるパスでも、デーモンが動作するアカウントにとって書き込み不能なことがあり、その場合デーモンは何かを報告する前に失敗する可能性があります。ファイル名が問題だと決めつける前に、ディレクトリの存在と所有者を確認してください。

サービスのラッパーが出力を捕まえるとき

systemd では、明示的なファイルディレクティブが優先されない限り標準出力と標準エラーはジャーナルに送られますが、ベンダーのラッパーがまったく別の場所で捕まえることもあります。

だから同じプロファイルでも、シェルからとユニットからでは挙動が違います。ユニットの環境、作業ディレクトリ、標準ストリームは、対話的なシェルとはすべて異なります。相対パスは一方の文脈では解決され、もう一方ではどこにも届かないことがあります。両者が食い違うときは、プロファイルではなくユニットの定義を読んでください。

どちらかが壊れていると結論づけるのではなく、二つの起動構成を比べてください。ユニットのコマンドラインと環境を読み、次に同じ時間帯のジャーナルを読んでください。ラッパーが出力を独自のファイルへリダイレクトしているなら、そのファイルが今のログであり、OpenVPN のディレクティブはメッセージの行き先には関係ありません。

詳細度を上げるのは、それを読めるようになってから

出力先を見つける前に詳細度を上げても、見ていない場所にテキストが増えるだけです。

出力がどこに落ちるか分かったら、中程度のレベルでプロファイルが解析され、接続が試みられていることが分かります。起動の問題には二か三で十分です。より高いレベルは、失敗がネゴシエーションの細部であるときに価値を持ちますが、ファイルの肥大化も早めます。

そのうえで実際のエラーを読んでください。沈黙したターミナルはトンネルが上がったかどうかを何も証明しませんが、ファイルに記録された失敗こそが直す価値のあるものです。