GUI が開くプロファイルで OpenVPN サービスが失敗する：5 つの確認

二つのランチャーが同じマシンで同じプロファイルを開き、接続できるのは GUI だけです。ファイルは無傷で、インストーラーもおそらく正常です。違うのは、各ランチャーが openvpn.exe に与えるコンテキストです。作業ディレクトリ、アカウントの ID、ファイルの属性は、すべてそのコンテキストと一緒に移動します。この順に確認し、エラーを説明する最初の項目で止めてください。

どちらのランチャーが失敗するかを確認する

まず切り分けを証明します。同じプロファイル パスで GUI が接続でき、サービスが接続できないなら、ファイルは誰かが読めており、問題は誰がどこから読むかに変わります。両方失敗するなら、プロファイルが壊れていて、この話は当てはまりません。サービスの名前と、読み込むよう指示された正確なプロファイルを書き留めてください。

サービスが自分の自動開始ディレクトリを指している場合、エディターで開いているファイルを読み込んでいない可能性があります。サービス構成のパスと GUI のパスを 一文字ずつ比較してください。末尾のフォルダー名や違うドライブ文字だけでも、間違った枝へ進んでしまいます。

相対パスはどこで解決されるか

ca.crt やヘルパー スクリプトを名前だけで参照するプロファイルは、プロセスがいる場所からの相対的な検索を要求します。GUI は構成フォルダーで起動するので、それらの名前は解決されます。サービス マネージャーが起動したサービスにはそうした起点がなく、証明書が読まれる前に検索が失敗します。だから同じプロファイルが一方のランチャーでは動き、もう一方では動かないのです。

ラッパーに開始ディレクトリを与えるか、すべての参照を絶対パスにします。GUI のコンテキストをコマンド ラインで再現すると、次のようになります。

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

そのコマンドの詳細度を上げると、試された正確なパスが表示されます。アクセス許可を変更する前にこれを行ってください。ファイルの欠落と読み取りの拒否では、修正方法が異なります。既定のログでは両者を区別できません。フラグを一つ足すだけで、一時間の推測が節約できます。

サービスの ID が読み取れないとき

サービスはあなたではなく、システム ID として実行されます。あなたのユーザーにフル コントロールを与え、他の誰にも与えない ACL は、あなたのセッションでは完璧に機能しても、そこでは失敗します。マップされたドライブや認証された共有に置かれたプロファイルも、同じ理由で失敗します。他の何かを見る前に、ファイルのアクセス許可を確認してください。

確認は、有効なアクセス許可の読み取りと、サービス ID として試す読み取りです。前半は昇格したプロンプトから実行します。

icacls "C:\VPN\profiles\office\office.ovpn"

次に、同じ読み取りをサービス ID として試します。たとえば Sysinternals の psexec -s -i を使い、ファイルが開くかどうかを見ます。開かなければ、パスの修正では何も解決しません。ACL を修正するか、サービス ID が読める場所へプロファイルを移してください。

ファイル レベルの暗号化は、二つ目のより珍しいケースです。Encrypting File System 属性が付いたプロファイルは、暗号化したユーザーには透過的に復号され、サービス アカウントには読めないままです。だから同じファイルがエディターでは開き、サービスの下では開かないのです。

属性は昇格したプロンプトから見え、確認してもプロファイルは開きません。両方のコマンドを実行して出力を読んでください。

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

属性を消すとファイルは読めるようになりますが、それが担っていた保護も失われます。プロファイルを保護したままにする必要があるなら、ユーザーごとの暗号化に頼るのではなく、サービス ID に明示的な許可がある場所へ秘密の素材を置いてください。そうした配置はパスワード変更にも耐え、ファイルを暗号化した本人以外の誰かがアクセスをレビューできるようになります。

トンネルの所有者を決める

GUI はパスワードを要求でき、ユーザー ストアから証明書を読めます。サービスはどちらもできません。そのため、対話的な秘密に依存するプロファイルは、パスをどう直しても無人では起動しません。この限界は設計上の決定であり、回避すべき欠陥ではありません。他の何かを変える前に、所有者を一つ選んでください。

ログイン前にトンネルを立ち上げる必要があるなら、サービスに無人で使える資格情報の供給元と、プロファイルの独自のコピーを与えます。デスクにいる間だけ存在すればよいなら、GUI に置いたままサービス側のコピーを削除します。両方を同時に持つと、アダプターの競合と重複したルートが生じます。

その競合は通常、一つのアダプターを奪い合う二人の所有者ではなく、構成エラーとして診断されます。イベント ログには、一つのプロセスが TAP デバイスを開けずに失敗する様子が残ります。これはアクセス許可の問題に見えますが、そうではありません。まず所有者を数えてください。

サービスのラッパーが実際に起動するもの

サービスのエントリ ポイントは、自分が保存したパラメーターを読んでから openvpn.exe を起動する小さなラッパーです。イベント ログのコマンド ラインが期待と食い違うとき、調べるべきはその値です。再インストールは値を既定に戻し、証拠を破壊します。まず値を読んでください。

値はレジストリのサービス自身のキーの下にあり、sc qc はサービス マネージャーが起動するバイナリ パスを示します。どちらかを編集する前に、そのパスをラッパーの保存済み構成と比較してください。

ラッパーを自分が管理するスクリプトに置き換えるのは侵襲的ですが、実効のコマンド ラインを一つの読めるファイルに畳み込めます。再起動で終え、その後、最初の成功した起動行が現れるまでプロファイルごとのログを読んでください。サービスの状態が実行中というのは、ラッパーが終了していないというだけの意味で、子プロセスが即座に死んだ場合にも当てはまります。