NetworkManager で VPN ルートが見つからない：プロファイルのポリシーかスクリプトか

接続するとトンネルインターフェースが現れ、必要なプレフィックスだけがテーブルにない。次の一手はたいてい、それを追加するスクリプトの検索だ。その検索は OpenVPN のヘルパーをプロファイルに貼り付ける回答に行き着くが、そうした回答の半分は状況を改善するどころか悪化させる、というのもルートの欠落には三つの所有者が考えられ、そのうちスクリプトの欠落は一つだけだからだ。

何かを書く前に、どの所有者の責任かを決めよう。

三つの所有者、一つの欠けたプレフィックス

プレフィックスは、誰も渡していないから、プロファイルが拒否したから、あるいは見ていない場所にインストールされたから、存在しないことがある。どれも別の不具合であり、直し方も別だ。

一つ目は確認が最も簡単で、サーバーやプラグインがそのルートを提供したことがあるかを見ればよい。プレフィックスを受け取っていないバックエンドはインストールできないし、ヘルパースクリプトは相手が一度も示していない到達性を捏造できない。二つ目はプロファイルのポリシーで、接続が本来取るはずのルートを抑止することがある。三つ目はテーブルやルールで、既定の検索が見ない場所にルートを保持していることがある。

四つ目の所有者は後のあなた自身、つまり接続時にルートを追加するが切断時に削除しないスクリプトである。これはトンネルより長生きし、死んだインターフェースを指し、次にそのマシンを調べる人を混乱させるプレフィックスを生む。

何かを足す前にプロファイルを読む

保存済み接続のプロパティから始めよう。秘密を吐き出さずに読み、プロファイル名が曖昧なら UUID を使う。

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type は どのバックエンドが接続を所有しているかを教えてくれるが、これはプラグインのデータがバックエンド固有だからこそ重要だ。あるプラグインが受け付けるキーは別のプラグインにとってサポートされた指示ではないので、別クライアントのドキュメントからコピーした断片は何の証拠にもならない。

ipv4.ignore-auto-routes と ipv4.never-default は別の問いに答える。前者は接続が本来自動で取るルートを拒否でき、後者はプロファイルが既定ルートになれるかを制御する。自動ルートを無視し、他に何も頼らないプロファイルはきれいに接続し、ほとんど何もインストールしない。

ip -4 rule show
ip -4 route show table all

この二つのコマンドで三つ目の可能性が決着する。プレフィックスを main だけでなくすべてのテーブルで探し、ポリシールールが該当の検索を別の場所へ送っていないかを確認しよう。プレフィックスが別のテーブルにあり、誰も参照していないなら、ルートが欠けているのではなく、そこへ決して届かない検索があるのだ。

スクリプトに直せないもの

ヘルパースクリプトを足すと、NetworkManager の vpn.data に実行するプログラムが与えられる。これは実在する仕組みだが、スクリプトが制御を得るのはプロファイル自身のポリシーが何を受け入れるかをすでに決めた後だから、こうしたケースの大半には誤りだ。

OpenVPN の script-security もよくある混同で、クライアントが実行できるスクリプトとその環境に置けるものを規定する OpenVPN の設定である。レベル 3 は環境経由で資格情報を渡すことを許すが、これはルーティングの修正ではなく秘密の扱いに関する判断だ。バックエンドが OpenVPN でないプロファイルに貼り付けたり、どのスクリプトも必要としないのに引き上げたりしても、ルートは増えず露出だけが増える。

次に再起動の反射がある。NetworkManager サービスを再起動すると、リモートで作業中なら自分がつないでいるリンクも含め、管理下のすべてのリンクが切断されて作り直される。これは無害な診断ではなく破壊的な操作で、サーバー上ではセッションが生き残るかどうかの差になりうる。

判断は順番に

三つの問いを順に立てよう。相手がプレフィックスを提供したかは、バックエンドのログや自身の状態出力で分かる。そうなら、プロファイルはルートを受け入れてインストールする設定か、それとも抑止しているか。ルートがどこかに存在するなら、テストしている通信に対して検索経路は正しいか。

一つ目がはい、二つ目がはい、三つ目が正しいときにはじめて補助スクリプトは正当化され、それでもバックエンドがそのルートをネイティブに支えるかを問うべきだ。VPN 設定リファレンスには service-type とプラグイン固有のデータ辞書が記されており、キーが存在すると決めつける前にそこから始めるべきである。

承認された修正の後、再接続して宛先をアドレスで、次に名前で試し、そのうえで切断して再接続し、状態が再現することを確かめよう。所有者が一つ、テーブルが一つ、そしてトンネルとともに消えるルートこそ、手に入れる価値のある結果だ。