OpenVPN 設定にあるその config.json を所有しているのはどのプログラムか

config.json という名前のファイルを見つけ、そこに VPN サーバーの記述があれば、すぐにこう思い込みます。これは OpenVPN の接続に違いない、と。多くの場合そうではありません。この名前の JSON ファイルは、クライアントを起動するデスクトップのフロントエンドのものだったり、独自の設定を保存するデーモンのものだったり、製品のエクスポート形式のものだったりして、どれもそれぞれ別のスキーマを持っています。

ファイル名は最も役に立たない手がかりです。そのファイルを読むプロセスから始め、次にそのプロセスが期待する形式がそもそも JSON なのかを確かめ、それからようやく、ファイルを編集することが何かを変えるためのサポートされた方法なのかを判断してください。

ファイル名ではなくプロセスから始める

実際に何が動いているかを見ます。サービスユニット、起動スクリプト、あるいはトレイアプリは、起動するバイナリの名前と、たいていは渡す設定パスを明示します。ファイルが置かれているディレクトリは二つ目の手がかりです。アプリケーションのデータディレクトリ、サービスの設定ディレクトリ、ユーザープロファイルのディレクトリでは、所有者がそれぞれ違います。

次に、そのコンポーネントを所有する製品のドキュメントを読みます。JSON がラッパーのものなら、そのキーはラッパーのキーです。別の製品の例から組み立てたもっともらしいオブジェクトは、拒否されるか黙って無視されます。

同じ名前のファイルが別のディレクトリにあるのはよくある罠です。片方はサービスが起動のたびに書き直す生成された状態で、もう片方は人が編集することを想定したテンプレートかもしれません。間違った方を変更すると、次の再起動までしかもたない修正になります。

Community OpenVPN のプロファイルとは実際何か

Community OpenVPN 2.6 はオプション方式のテキスト形式を読みます。プロファイルはディレクティブの並びです。クライアントモードの行、デバイスの行、リモートのエンドポイント、さらに ID、暗号、ルートのオプションが続き、証明書と鍵の素材をインラインブロックの中に埋め込むこともあります。

この形式はクライアント自身が行単位で解析します。config オプションで JSON 文書を渡しても JSON パーサーは有効にならず、最初の行が未知のディレクティブとして拒否されます。JSON ファイルの名前を .ovpn で終わるように変えても中身は変換されませんし、有効なオプションファイルが拡張子の珍しさで無効になることもありません。

OpenVPN Connect と OpenVPN 3 Linux には、プロファイルのための独自のインポートと管理の経路があります。これらの製品はプロファイルを受け取り、自前のデータベースやサービスの状態に保存できますが、それはたまたまサーバーを記述している JSON ファイルとは同じものではありません。

別のコンポーネントが所有する状態を編集する

JSON が生成されている場合、それを編集するのは競争です。稼働中のサービスは、停止時、再接続時、あるいは次の設定変更時に書き戻すことがあり、手作業の編集はエラーも出さずに消えます。製品のインポートコマンド、管理 API、設定画面を優先してください。それらの経路はファイルが表している内部状態を更新するからです。再起動後に元へ戻るファイルは、どちらの経路が永続的だったかを教えてくれます。

生成されたファイルをどうしても編集するなら、まずサービスを停止し、バックアップを取り、可能な限り小さな変更にしてください。そのあと、サービスが起動時にファイルを書き戻すかどうかを確認します。起動時に戻るファイルは、本当の真実の源が別の場所にあり、その編集は決して残らなかったという意味です。

パスワードと埋め込みの秘密鍵は別の話です。JSON はオプションファイルと同じくらい簡単に完全な鍵を運べるので、どのエクスポートも秘密として扱い、共有ドライブに置かず、フォーラムの質問に構造を貼る前に値を伏せてください。

変更の検証とファイルの保護

検証とは「JSON が解析できる」ことではありません。解析は括弧が合っていることを示すだけで、所有者がキーを認識するかどうかは何も語りません。製品自身の状態を確認してください。有効なプロファイルの一覧、選択されている接続、そして新しい値が実際に使われる再接続です。一覧に現れても選択されたものにならないプロファイルは、まだ使用中のプロファイルではありません。

編集したコンポーネントのログを見てください。VPN クライアントのログだけでは足りません。あなたのファイルを拒否するラッパーはたいてい自分のログにそれを残しますし、ファイルを一度も受け取らなかったクライアントは、悪い設定を受け取ったクライアントと見分けがつきません。

動作しているファイルのコピーを残し、テストした製品のバージョンを記録してください。これらの形式はリリースごとに変わり、昨年動いていた構造がアップグレード後に、スキーマに一切触れないメッセージとともに拒否されることがあります。

手順のまとめ。プロセスを特定し、そのドキュメントを読み、ファイルがそもそも JSON なのかを確かめ、サポートされた編集経路を使い、製品自身の状態で検証する。ファイル名はこれらの問いのどれにも答えてくれませんでした。