この NetworkManager プラグインは VPN を二つ同時に動かせるのか

接続一覧に VPN の項目が二つ並び、どちらも接続済みと表示されているのに、期待した通信を運んでいるのは片方だけ、ということが起きる。あるいは二つ目がまったく起動を拒み、それがプラグインのせいなのか、クライアントのせいなのか、忘れていたポリシーのせいなのか誰にも分からない。VPN は一つまでという主張は特定の実装を説明したもので、実装はそれぞれ違う。まず能力を確かめ、それから調整に進む。

保存済みプロファイルを数え、次に有効化を数える

保存済みプロファイルは設定のオブジェクトであり、有効な接続は実行中のインスタンスである。一覧はこの二つの概念を見た目で融合させているので、どちらの報告も正しく聞こえる。まず正確なオブジェクトを UUID とともに名指しするところから始める。表示名は一意ではなく、古いインポートが新しい項目と同じラベルを共有していることがよくあるからだ。次に有効な接続の一覧を別に見て、どの UUID が現れるかを確かめる。そうして初めて、二つの設定を比べているのか、二つの生きたトンネルを比べているのかが分かる。

同じ UUID を二回有効化するのは第三のケースであり、同時実行ではない。一つのインスタンスの再有効化である。

プラグイン自身のメタデータを読む

VPN プラグインはどれも、マネージャーが読む小さなメタデータファイルを同梱しており、そのファイルは複数の接続を同時に扱えるかどうかを宣言できる。上流プロジェクトが今書いていることを繰り返すのではなく、このマシンにインストールされているファイルを読む。実際に手元にあるものを決めるのはディストリビューションのパッケージだからだ。同じ確認はプロトコルごとに必要で、あるプラグインへの答えは別のプラグインについて何も語らない。 パッケージのバージョンを結果と一緒に記録する。そうしてこそ後日の比較に意味が生まれる。

VPN は一つまでという古い助言は、より古い統合を説明したものだった。永遠に正しいわけでも、固定された前提として安全に扱えるわけでもなく、目の前のファイルがその場で決着をつける。

同時であって調整済みではない

二つのプラグインが正常に起動することは能力の証明であって、設計の証明ではない。どちらも既定ルートを提示する二つのトンネルは競合し、自分のルートを最後に据えた側が、そう宣言しないまま勝つのが普通だ。重なるプライベート範囲も同じ問題を小さな形で抱える。

何かを有効化する前に、どの宛先がどのプロファイルに属するかを決める。プロファイルの名前を変えても宛先は区別されない。

DNS は望むと望まざるとにかかわらず勝者を選ぶ

リゾルバーの設定はプロファイルごとにあり、二つが有効なときは解決の順序を意図ではなくポリシーと優先度が決める。最後に立ち上がったプロファイルが、あらゆる社内名を静かに所有しうる。

プライベートな名前空間ごとに、それに答えるべきリゾルバーを割り当て、順序に頼らず経路の優先を意識して設定する。そのうえで両方のトンネルを上げた状態で各名前空間の名前を試し、片方を切断した状態でもう一度試す。両方のトンネルが上がっている間しか動かないリゾルバーは、最悪の瞬間に誰かを驚かせる設計だ。

決まった順序で展開し、間で点検する

一つのプロファイルを有効化してそのルートとリゾルバーの状態を点検し、次に二つ目を有効化してもう一度点検する。二つの状態を比べれば、何が変わり、どのプロファイルが何を所有しているかが分かる。両方を有効化してから結果を診断してはいけない。

必要なリソースはそれぞれ、運ぶべきトンネルを通して試し、そのうえで片方のプロファイルを切断して、もう片方がルート、DNS、意図した障害時の振る舞いを保つことを確認する。導入済みのプラグインがどうしても必要なことをできないなら、マネージャーの隣で廃れたプロトコルを復活させるのではなく、サポートされた更新か明示的に切り離した代替を選ぶ。誰も管理していない二本目の別個のトンネルは分離ではなく、驚くようなルートのもう一つの源にすぎない。