一つのプロファイル、二人の所有者: NetworkManager か systemd か

.ovpn ファイルは、何かが所有するまで何も起きません。Pi のデスクトップでは、もっともありそうな所有者は、インポートした接続を独自のキーファイルに保存する NetworkManager と、ディレクトリから設定を読む単独のサービスユニットです。これは保存場所、認証情報の扱い、起動規則が異なるふたつの運用モデルです。どちらかを意図して選ぶことがこの作業のすべてであり、ファイルを両方の場所にコピーすると選択が偶然になります。

どちらも同じマシンで動かせますが、同じトンネルを同時に動かすことはできず、その衝突は設定の不具合ではなくネットワークの不具合のように見えます。

同じトンネルを所有するふたつの方法

NetworkManager の OpenVPN プラグインは、接続を代わりに管理するエディターとサービスを追加しますが、OpenVPN プログラムをインストールしてもこの統合はインストールされません。単独のユニットは逆の配置です。エディターもデスクトップ統合もなく、設定ファイルがひとつと、ユニットが与える権限だけがあります。前者は接続の状態を独自のデータベースに保ち、後者はプロファイルとユニットが指定する場所に保ちます。混乱の多くは、インポートしたプロファイルとコピーしたファイルが同じものだという前提から生まれます。

それらは同じもののふたつの見方ではありません。ダウンロードしたファイルを編集しても、NetworkManager が保存したものも、ユニットが読むものも変わりません。どちらが、たった今テストしたトンネルを構築したものかは分からないのです。

デスクトップが実際に使っている接続をたどる

文書化されているインポート操作は、nmcli connection import type openvpn file office.ovpn でプラグインを通じた接続を作ります。UUID を記録し、以後はその識別子を使ってください。名前は編集され、ふたつの接続が同じラベルを共有することがあるからです。nmcli connection show は存在するものを一覧し、接続自身のプロパティを読むと、どのファイルから来たか、何を保存しているかが分かります。編集している UUID がデスクトップの有効化するものと違えば、その編集は飾りにすぎません。

秘密は所有者の保管場所にあります。どのプロファイルが有効かを知るために保存済みの秘密をすべて吐き出すのは、遅く危険です。代わりに接続オブジェクトに問い合わせ、私的な素材は所有者が期待する場所に置いてください。

インポートした接続は動かすのにグラフィカルセッションを必要としませんが、認証情報の供給元は必要かもしれません。無人で起動するかどうかは、その権限と秘密にかかっており、デスクトップの有無ではありません。

ユニットのテンプレートは、頼る前に読む

パッケージが上流風のクライアントユニットを同梱している場合、office という名前のインスタンスは、ユニットの設定されたディレクトリにある %i.conf に対応します。2.6 テンプレートではそれが /etc/openvpn/client です。ガイドの例を信じる前に、インストール済みのユニットと追加ファイルを読んでください。ディストリビューションはパスを移すからです。端末からの手動起動は、サービスがファイル、秘密、権限をどう見るかについて何も証明しません。デスクトップのパスワードダイアログも、非対話のユニットが同じパスワードを得る承認された手段を持っている証拠にはなりません。

ユニットには必要なものだけを与えてください。参照されたファイルが読めないからといってサービス全体のサンドボックスを緩めると、小さな権限の修正を大きな露出と引き換えます。エラーはふつう、注意すべきファイルの名前を告げます。

アクセスを失わずに重複を退役させる

両方の所有者がトンネルを起動できると、どちらかがやがて誤った瞬間に勝ち、負けた側のルートとデバイスが取り残されます。偶然の重複を、それ自身の所有者を通じて削除する 回復経路を開いたままにし、残った所有者が再起動後も接続することを確認してください。異なるルーティングポリシーを持つ意図的に別々の VPN は別の設計上の問いであり、ふたつの起動経路がひとつの接続を争う許可ではありません。

そのうえで、受け入れたライフサイクル（手動起動、ログイン、または起動と再接続）を書き留め、保存されたエンドポイント、相手側の認証、トンネルが到達すべき資源を確認してください。デスクトップを入れ直しても、どの設定が動いていたかを知る代わりにはならないからです。