NetworkManagerかwg-quickか: WireGuardのルートを所有しているのはどちらか

WireGuardファイルのAllowedIPsを変更してトンネルを再起動しても、ルーティングテーブルは以前とまったく同じに見えます。よくある反応は問題のルートを削除して先に進むことですが、それは次の再接続が元に戻すまでしか効きません。編集したファイルが、目にしている状態を生み出したオブジェクトとは限りません。同じマシンで二つの管理ツールが同じプロトコルを動かせますが、インターフェースを所有できるのは同時に一方だけです。

神話: マシン上のWireGuard設定は一つだけ

wg-quickは /etc/wireguard/ 配下のファイルを読み、インターフェースを立ち上げるときに構築します。NetworkManagerは接続プロファイルを独自のkeyfile形式で保存し、アクティブ化時にそれを描画し、 wg-quickファイルをインポートすると、値はそのプロファイルにリンクされるのではなくコピーされます。プロファイルはもうそれを読まないため、後から元のファイルを編集しても何も変わりません。同じピアと鍵の一覧が二か所に存在し、二つ目のコピーが有効になります。

覚えておく価値のある兆候: 再起動には耐えるが再インポートには耐えない編集は一方のストアから来ており、再起動で消える編集はもう一方から来ています。

実例を一つ挙げると分離が明らかになります。比較してください: nmcli connection show と systemctl status wg-quick@wg0、その後ルートが実際にどのインターフェースにぶら下がっているかを確認します。サービスが停止していてインターフェースが上がっていれば、ファイルが何と言おうとプロファイルが仕事をしています。

神話: ルーティングルールはWireGuardの一部

カーネルのWireGuardデバイスはピアと鍵を認識しますが、ポリシールーティングについては何も知りません。目にする ip rule のエントリや追加テーブルは、インターフェースを立ち上げたツールがインストールしたものです。wg-quickはfwmarkと専用テーブル、そしてそれを指すルールを追加できますが、NetworkManagerは独自のipv4設定を通じてルートをインストールし、DNSはシステムが使うリゾルバのバックエンドに任せます。同じトンネルでも副作用は異なります。

何かを変更する前に ip rule と ip route show table all を読み、各ルートがどのテーブルに属するかを記録してください。自分で設定していないテーブル番号は、それを作成したツールに関する強い手がかりです。

神話: ルートを削除すれば修正になる

実行中に削除されたルートは、所有者が次のアクティブ化で再インストールするルートであり、ノートPCの復帰、リンクの揺らぎ、サービスの再起動、NetworkManagerの自動接続など、あなたなしでもアクティブ化は起こり得ます。だから同じルートが戻ってくるのであり、回避策が間違っているのではなく頼りなく感じられるのです。まず管理ツールを特定し、その管理ツールが実際に読む入力を変更してください。

再接続と該当サービスの再起動は、本当の修正と見かけだけ整った修正を分けるテストです。

所有者を一つ選び、もう一方を削除する

デプロイがサポートする管理ツールを選び、アイドルのままでいてくれることを期待するのではなく、その文書化された制御で競合するアクティブ化を無効にしてください。マスクされたwg-quickサービスや削除されたNetworkManagerプロファイルは明示的ですが、両方を有効にして競争させるのは明示的ではありません。何かを無効にする前に、リモートセッションを運んでいるインターフェースがまさに削除しようとしているものかもしれないので、動作するアクセスを確保してください。

変更後、含まれる通信と除外される通信、次にDNS、最後に一度再起動して確認します。単一の管理ツールで再起動後も状態が保たれれば、偶然ではなく所有者がいるということです。

ある設定が何度も戻ってくるなら、結果を削除するのをやめ、それを生み続けるプロセスを見つけるという一般則は、WireGuardの外でも覚えておく価値があります。