Wi-Fi はひとりでにつながる。VPN には二次的な関連付けが要る

ノート PC は席に着く前に Wi-Fi に接続し、VPN はまだクリックを待っている。VPN プロファイルの自動接続を設定しても何も変わらないのは、このスイッチがプロファイル自身の有効化を司り、NetworkManager が VPN をベース接続の随伴物として扱うからだ。文書化された仕組みはベース接続の二次リストであり、別の場所にある別のプロパティである。

自動接続は VPN のスイッチではない

Wi-Fi あるいは Ethernet のプロファイルは、デバイスを所有しているため自分で有効化できる。VPN プラグインのプロファイルは同じ意味でデバイスを所有しておらず、デバイスを持つ接続の隣で起動される。だから VPN の自動接続フラグは正しく見え、正しく保存され、トンネルを生まない。このフラグはプロファイルについての問いに答えるもので、必要とするネットワークについてではない。

このようにモデルを読むと故障の形も説明できる。ベースは接続し、何も VPN に起動を求めず、デスクトップは接続済みネットワークの隣に切断された VPN を表示する。壊れてはいない；関連付けが作られなかっただけだ。

両方のプロファイルを UUID で特定する

nmcli -f NAME,UUID,TYPE connection show

トンネルを起動すべき Wi-Fi または Ethernet のプロファイルを選び、次に目的の VPN プロファイルを選ぶ。名前ではなく UUID を使うのは、名前が複製や編集できるラベルであり、有効化の経路が実際に解決するのは UUID だからだ。

プロファイル名をインターフェース名やマシンが今持っているアドレスと混同しないこと。どれも端末ではたまたま似て見える別々の識別子であり、混ぜると何も狙わない変更になる。

VPN をベース接続に追加する

nmcli connection modify uuid "PRIMARY_UUID" +connection.secondaries "VPN_UUID"

プラス記号の形式は既存のリストに追加し、省略するとリストを置き換えて既に設定されていた他の二次接続を黙って外す。まず現在の値を確認し、何かを変える前に書き留めておく。

NetworkManager の接続設定は、二次接続をベース接続とともに起動する VPN 接続として説明している。ネイティブな WireGuard プロファイルが同じ種類のオブジェクトかどうかは NetworkManager の管理方法次第であり、VPN プラグインではなくインターフェースとして現れるトンネルには同じコマンドが適切でない場合がある。

これは接続ポリシーの変更であり、実行時の切り替えではない。デプロイが承認する再接続プロセスを通して適用し、変更後の最初の有効化が今のセッションとは違う振る舞いになると想定する。

シークレットは関連付けの一部ではない

二次エントリは「これをあれと一緒に起動する」と言うだけだ。その中にパスワードを渡すもの、キーリングを解錠するもの、プロンプトに答えるものはない。デスクトップのログイン後に問題なく認証するプロファイルでも、シークレットエージェントが使えないコンテキストで有効化されれば失敗しうる。

実際のデプロイには、サポートされたシステムまたはシークレットエージェントの仕組みを使う。トンネルを無人で起動させるために全員のパスワードをスクリプトに保存すると、認証の設計が持ち主の雇用より長く残るファイルに変わる。

両方のイベントを読み、次にリソースを確認する

一回の試行の間にベース接続と VPN の有効化を観察する。VPN のイベントが欠けていれば、トリガーが設定されていないか UUID が誤っている。VPN のイベントの後に認証失敗が続けば、トリガーは動いており、残る問題は資格情報であり、別の修正になる。

有効化の後は、アイコンを信じるのではなく、設定のきっかけとなったリソースを要求する。そのうえで意図的に切断し、次に何が起きるかを見るのは、自動起動の関連付けがキルスイッチではなく、無限の再試行を約束するものでもないからだ。「トンネルなしの通信はない」が要件なら、それは独自の設定と独自のテストを要する別のポリシーだ。両者を混同すると、利用者が守られていると思い込む一方で、マシンがループで再接続し続けることになる。