実際にあなたの PiVPN プロファイルを使っている OpenVPN インスタンスはどれか

PiVPN はサーバー設定とクライアントプロファイルを書き、その後終了しますが、トラフィックを運ぶプロセスになることはありません。そのため、失敗したハンドシェイク、誤ったエンドポイントに接続するクライアント、再起動後に壊れて戻るサービスは、インストーラーのメニューからは説明できません。そうした症状は、いま動いている OpenVPN デーモン、そのデーモンが実際に読み込んだ設定、そして向けられたログに属します。読み取り専用の四つのコマンドでたいてい片付き、どれも証明書や鍵を変更しません。

ヘルパーとデーモンは別のオブジェクトである

混乱は簡単に説明できます：一つのディレクトリに、ヘルパーが生成したファイル、デーモンが読むファイル、ときには両方の古いコピーが同居します。ヘルパーはプロビジョニング用スクリプトです。パッケージを導入し、ユニットファイルを書き、クライアントプロファイルを出力して、仕事を終えます。残るのはサービスマネージャーのエントリーと一本のコマンドラインです。

systemd ホストではディレクトリ一覧ではなく、アクティブなユニットから始めてください。名前はパッケージングによって異なり、Debian や Raspberry Pi OS のイメージは通常、たとえば openvpn-server@server のようなテンプレートインスタンスを公開しますが、古いインストールでは openvpn@server を使います。ファイル名から推測するのではなく、どちらが動いているかをマネージャーに尋ねてください。

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

その出力の ExecStart= を読みます。実行ファイルと、マネージャーが実際に起動するオプション名、そして任意の --config パスが示されますが、近くにある設定ファイルでも、どのコマンドからも参照されていなければ、動作中のトンネルの一部ではありません。

デーモンが解決した設定チェーンをたどる

OpenVPN は設定を探してディレクトリを走査しません。次に --config で渡されたファイルを読み、config ディレクティブをすべてたどり、そのうえでコマンドラインオプションを適用します。2.6 のマニュアル がその順序を説明しており、ポート、デバイス、暗号について二つのファイルが食い違うときに重要になります。

まず実際の起動内容を出力し、次に識別情報と到達性を決めるディレクティブを見ます。どちらのコマンドも読み取り専用で、稼働中のサーバーでも安全ですが、後者は公開チケットに載せたくないパスを出力します。

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

ホームディレクトリの .ovpn ファイルはクライアント側の成果物です。サーバーのデーモンは決して読まないので、サーバー側のハンドシェイク障害を直すためにそのファイルを編集しても何も起こりません。

もう一つの罠はインクルードです。 config 行は二つ目のファイルを引き込み、そのオプションはその位置で処理されるため、後から来る単一値のディレクティブが、メインファイルに書かれているように見える内容を上書きできます。見えているファイルが正しそうなのにデーモンの挙動が違うなら、何かを変える前にインクルードされたファイルを読んでください。

ログを思い出すエラーではなく、プロセスに合わせる

ログの出力先は二つが一般的で、そのうち一つだけが journal です。 log-append が設定されていると、デーモンはそのファイルに書き、journal には起動行以外ほとんど残りません。それがない場合、journalctl がイベントの出どころです。

journalctl -u openvpn-server@server -n 80 --no-pager

一回の接続試行を一つの時間枠に対応づけます。クライアントのエンドポイントを記録し、同じ秒のサーバーイベントを読みます。証明書交換にまで至らない TLS ハンドシェイクは到達性かプロトコルの不一致を示し、認証の拒否はトンネルパラメーターが合意された後に届きます。

古いログ行は、五分前にダウンロードしたプロファイルについて何も証明しません。クライアントファイルを再生成し、一度だけ接続して、その試行中に現れた行だけを読んでください。

最後の一般的な失敗ではなく、最初の具体的な失敗を記録します。バインドエラー、応答のない外側の交換、証明書の拒否、アカウントの拒否は、それぞれ別の層へ導き、末尾のタイムアウトは、その上にある有用なイベントを隠していることがよくあります。

トンネルの再構築は診断の手順ではない

誘惑される近道は、より単純な二本目のトンネルを立てることです：静的鍵、証明書なし、追加認証なし。たいていは接続でき、それは二つのホストが互いに UDP か TCP を通せることだけを示します。証明書で認証する構成がなぜ失敗するのかは何も語らず、保つよう求められたセキュリティモデルを静かに置き換えます。

同じことが、tls-auth や tls-crypt を無効にし、verify-x509-name を緩め、緑の状態を得るために第二要素を落とす場合にも当てはまります。検証を外したから接続するトンネルは別のシステムであり、修理されたものではありません。

ログが示した層で一箇所だけ限定的な変更を行い、同じユニットを再起動し、その一回の接続試行を繰り返します。これで比較は正直に保たれ、元に戻せる変更が残ります。

次の人に渡すもの

まだ手元にあるうちに四つの事実を書き留めてください：OpenVPN のバージョンは openvpn --version の出力から、稼働中のユニット、インクルードを含む設定チェーン、そして一回の試行を覆うログの時間枠です。その四つが曖昧な不満を再現可能なケースに変えます。

共有する前に伏せ字にします。秘密鍵、auth-user-pass ファイル、静的鍵の素材、完全なクライアントバンドルはチケットに載せるべきではありません；オプション名とチェーンの形は、たいてい第二の目には十分です。

チェーンが無傷で、ログがまだネットワークを指しているなら、次の手順はクライアントとサーバーの間の経路 であり、別のインストールではありません。それが、ヘルパーが決して持っていなかった物語の一部です。