openvpn --errors-to-stderr は起動オプションであり、エラーではない
コマンドラインに --errors-to-stderr があるからといって、何かが失敗したわけではありません。起動行を読んでいるのかプロセスの出力を読んでいるのかを判断してから確認してください。
--errors-to-stderr を含むコマンドラインは苦情のように見えますが、苦情ではありません。この語はオプション名の一部であり、ログファイルの名前がファイルの中身を何も語らないのと同じです。設定を変更する前に、実際に何を読んでいるのかを確かめてください。
判断は三つの枝に分かれます。その行が起動そのものか、プログラムが出力したものか、VPN の起動前にラッパーが繰り返したテキストかであり、それぞれ見る場所が違い、VPN 自身のメッセージはそのうち一つだけです。
オプション名は状態メッセージではありません
Community OpenVPN の場合、--errors-to-stderr はエラー出力を標準出力ではなく標準エラーへ流します。これはストリームの選択であり、重大度のフィルターではなく、エラーを生みません。後から --log や --log-append を使えば同じメッセージをファイルへリダイレクトでき、そのためフラグの効果はコマンドの残りの部分に依存します。上流の ログのリファレンス がその順序を定めています。
つまりフラグの存在は、エラーがどこへ向かうかを教えてくれます。エラーが起きたことは教えてくれません。
起動行かプロセスの出力か
まず、そのテキストを誰が出力したのかを問いましょう。サービスユニット、アプリケーションバンドル、シェルのラッパーは、VPN プロセスが何かを書き出す前に argv 全体を繰り返すことがよくあります。断片だけを見ていると、その繰り返しは状態行と区別できません。
その行がラッパーからのものであれば、VPN はまだ動いておらず、報告することもありません。出力をもっと下へたどり、タイムスタンプやサブシステム名を持つ最初のメッセージを探してください。
その行が VPN プロセスからのものであっても、それは依然として起動の呼び出しにすぎません。OpenVPN は自分のコマンドラインをエラーとして出力せず、重要なメッセージはその後ろに続きます。
プロセスとその結果を突き止める
プロセスがまだ動いているかを確認します。稼働中で再試行しているクライアントは、すぐに終了したものとはまったく違って見え、同じコマンドラインがどちらの前にもあります。
次に、そのプロセスを所有するコンポーネントを通して結果を読みます。systemd ならユニットのジャーナル、デスクトップアプリならアプリ自身のログやコンソールです。終了ステータスと最後のメッセージが、オプション名がほのめかすだけの問いに答えます。
設定の解析エラー、ファイルの欠落、拒否された資格情報、ピアのタイムアウトは、四つの異なる出来事です。どれも同じストリームに届きます。それぞれ別の修正が必要です。プロファイルに触れる前にどれなのかを決め、助けを求めるときは正確なメッセージを引用してください。
フラグがその場所を得るのはどんなときか
フラグは、標準出力がデータを運び、エラーでそれを汚してはならないとき、またはラッパーが二つのストリームを別々に捕らえるときに、その場所を得ます。端末の前面セッションでは、どちらのストリームも目の前に届きます。その場合、区別があなたの行動を変えることはほとんどありません。
周囲のスクリプトが分離に依存しているなら、そのまま残してください。名前が物々しいからといって外すと、メッセージの出る場所が変わるだけで、ほかは何も直りません。
変えてはいけないもの
このオプションを修理の手順として扱わないでください。削除しても、証明書、ルート、認証の失敗は直りません。
起動呼び出しに --config stdin が含まれる場合、設定は標準入力から供給されています。これはファイルをどう渡すかという別の判断です。一度に一つだけ変え、二つ目を変える前に実際のメッセージを読み直してください。