ベンダー製VPNアプリとNetworkManager：状態を所有するのはどちらか
プロファイルが名指すのはプラグインであり、ベンダークライアントの挙動ではありません。管理対象ノートPCを切り替える前に、登録、DNS、ブロック、更新の所有者を整理します。
プロファイルをインポートすることは、クライアントを置き換えることと同じではありません。NetworkManagerはプラグインの種類を、プラグイン固有のデータとシークレットとともに保存し、その種類を所有するプラグインが接続にできることを決めます。ベンダーのアプリケーションが上に重ねるものはすべて、登録から常時ブロックまで、ファイルの外にあります。切り替えが安全かどうかは、その層のどれに実際に依存しているかで決まります。
ファイルが名指すのはプラグインであり、機能の集合ではない
NetworkManagerの「VPN設定リファレンス」は、プラグインを選択するサービスタイプに加えて、プラグインだけが解釈する不透明なデータ辞書とシークレット辞書を説明しています。プロファイルは一つの実装との契約であり、どのクライアントでも再現できる挙動の記述ではありません。二つのクライアントが同じプロトコルを話しても、何を交渉し、どのデータ経路を有効にするかは異なります。プロトコルの名前が教えるのはトンネルが何かであり、周囲のクライアントがそれをどう扱うかではありません。
ですから、包みではなく要件を比べてください。問題は代替手段が接続できるかどうか（通常は接続できます）ではなく、元のクライアントを許容可能にしたすべての要件が移行後も残るかどうかです。何かを導入する前にその要件を書き出してください、そうしなければ比較は最初に壊れるものを探す作業になります。
ベンダーアプリがトンネルの周りに加えるもの
ベンダーのクライアントは通常、登録とデバイスの姿勢チェック、独自のインターフェースを持つ二要素の流れ、常時ブロック、更新チャネル、サポートツールをまとめて提供します。その一部はプロトコルの隣にあり、一部はインストーラーだけを共有する別製品です。NetworkManagerはトンネルとそのルーティングを置き換えられ、接続の状態が変わったときにディスパッチャスクリプトでアクションを起動できます。しかし、ブロックエンジン、証明書の更新手順、どのユーザーが接続を立ち上げてよいかという前提を再現することはありません。
構成要素が多いほど安全というわけでも、少ないほど弱いというわけでもありません。問題は、従うよう指示されたポリシーをどの構成要素が実際に適用しているかです。監査担当者が、トンネルが落ちたときに何が通信を止めるのかと尋ねたら、答えは実際にそうしているものを名指さなければならず、接続するだけのプロファイルはその答えではありません。
所有権が実際に分かれるところ
これはチェックリストではなく所有権の地図として読んでください。以下の失敗は所有権の隙間であり、クライアントの設定をどれだけ積んでも埋まらず、各行は層と、今日それを通常どちらが持っているか、そして隙間が最初に現れる場所を示します。
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
各行には、クライアントについての感覚ではなく、再現できる観察を結びつけてください。想定したリゾルバで解決された名前、トンネルが止まったときに消えるルート、模擬的な切断後にブロックされた接続という三つの観察で、表の大半を覆えます。観察はそれが証明する要件の横に書き、失敗したものは残してください、失敗した観察だけが次のインシデントを予測する記録の一部だからです。
所有権を重ねずに切り替える
同じサービスに対してベンダーのクライアントとNetworkManagerの接続を同時に動かすことが、こうした比較がうまくいかない最も一般的な原因です。どちらもルートを設定し、どちらもDNSを設定する可能性があり、どちらもファイアウォールの状態に触れる可能性があります。そのとき測っているのは、どちらのクライアントの文書化された挙動とも一致しない第三の構成です。
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"最初のコマンドは、プロファイルがそもそもVPN種別かどうかを示します。二つ目はプラグインのサービスタイプと保存されているシークレットを示し、鍵をファイルではなくエージェントから期待する場合に重要です。ジャーナルは、読み込まれたが交渉できなかったプラグインがそれを告げる場所です。三つのどれも問題を示さなければ、隙間は接続ではなくトンネルの上のポリシー層にあります。
新しい接続を有効にする前に古いクライアントを切断し、エンドポイントとアカウントを同一に保ち、ルート、リゾルバ設定、ブロックの所有者がどの構成要素かを書き留めてください。そのメモが、次の更新を二人の所有者で終わらせないために効きます。