接続を押すと、Linux マシンではインターフェースが現れ、ルートが設定され、リゾルバーが異なる応答を始めるという三つのことが変わる。設定の失敗の多くは、この三つのうち一つだけが他を伴わずに起きたこと、あるいは二つのプログラムがどちらがそれらを所有するかで一致しないことから来る。順序を理解すれば、クライアントのログ出力を読むより速く失敗を説明できる。

何かが動く前にインターフェースが現れる

トンネルクライアントは仮想インターフェースを開き、パケットをそこへ渡す。TUN デバイスは IP パケットを運びルーティング VPN に必要なもので、TAP デバイスは Ethernet フレームを運びブリッジ構成に必要なものだ。カーネルモジュールがデバイスを提供し、セッションが続く限りクライアントがそれを所有する。

インターフェースが上がることは、トンネルが機能することとは違う。相手に到達できなくてもアドレス付きで存在しうるため、インターフェース一覧は最後ではなく最初の確認になる。自分が上がっていると報告するデバイスは、カーネルから見た仮想リンクの姿を述べているのであって、相手が応答する用意があるかではない。

提供されたインターフェースモードはそのままにしておく。TUN プロファイルを TAP に変えても、ルーティングサーバーがブリッジになるわけではなく、たいていは接続が確立するだけで何も転送しない。

ルートを設定するのはトンネルを所有する者だ

ルートは二つ目の変化であり、その所有権は内容より重要だ。NetworkManager のプロファイル、systemd のユニット、手動で起動したクライアントのいずれもルートを設定でき、そのうち二つが同時に行えば、後から誰も説明できないテーブルができる。

ip -br addr show
ip route show
ip -6 route show

フルトンネルのプロファイルはデフォルトルートを置き換え、スプリットトンネルのプロファイルはより具体的なルートを追加してデフォルトはそのままにする。どちらも正常であり、後者こそが、遠隔管理しているマシンでデフォルトルートを削除するのが最初のテストとして不適切な理由だ。削除は、問題を直すために使っているセッションを失う最速の方法でもある。

推測せずにテーブルを読む。より具体的なルートやポリシー規則が、デフォルトルートがまだ物理インターフェースを指したままトラフィックをトンネルへ送ることがあり、これはテーブル全体を読むまで矛盾して見える。その組み合わせはスプリットトンネルでは正常で、一行で構成を説明できると期待する人には混乱のもとだ。図に合うルートではなく、実際の宛先に合うルートを探すこと。

リゾルバーは持ち主が変わる

DNS は三つ目の変化であり、見ていない場所で管理されている可能性が最も高いものだ。デスクトップでは NetworkManager が接続ごとにリゾルバー設定を渡すことがある。systemd-resolved を使うシステムでは設定はリンクごとに適用され、/etc/resolv.conf は編集すべきファイルではなくスタブやシンボリックリンクであることがある。

resolvectl status
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

リゾルバーファイルへの手動編集が再接続後に消えるなら、それはそれを維持しているコンポーネントを見つけ、代わりにプロファイルを変える合図だ。生成されたファイルを編集することは、再接続が消してしまう変更だ。

プライベート名には通常、内部リゾルバーと運用者が提供した検索ドメインが必要だ。公開リゾルバーに置き換えると、VPN が存在する理由そのもののリソースを壊すことがあり、症状は DNS の失敗ではなくルーティングの失敗に見える。名前とアドレスを別々に試すこと、片方が動き他方が失敗すればどこを見るべきかが正確に分かるからだ。その一度の比較が一時間のルート調査を節約する。

接続ごとに一つの管理者

プロファイルの形式が、どのプログラムで使えるかを決める。OpenVPN のプロファイルには OpenVPN か対応プラグインが必要で、WireGuard の設定にはピアキーや許可プレフィックスを持つ独自形式がある。インポート画面は、ファイル拡張子が何を示そうと、一方を他方に翻訳しない。

管理者を一つ選び、その接続を所有させる。同じトンネルを二つのツールで立ち上げると、ルートテーブルと再接続の挙動が曖昧になり、たいていは後から起動した方が再現しにくい形で勝つ。

ディストリビューションが対応するパッケージを入れ、プロファイルは運用者から入手する。通常は秘密鍵か同等の素材を含むので、認証情報として扱い、他の秘密と同じ場所に保管する。ダウンロードフォルダに置き忘れたプロファイルは、机の上に置き忘れた鍵だ。

上がっているのに動かないときに何を確認するか

インターフェースが上がり、クライアントが成功を報告している状態で、外側へ向かって、ルートテーブルが宛先に対してトンネルを選ぶか、リゾルバーがプライベート名に答えるか、向こう側に戻り経路があるかを確認する。それぞれに別のコマンドと別の所有者がある。

nmcli connection show --active
nmcli device status
wg show

nmcli のリファレンスには、一式が必要な場合の状態と接続のコマンドが記載されている。ここで重要なのは、プロファイルが有効であることとデバイスがトラフィックを運んでいることの区別であり、この二つは食い違うことがある。

設定を終わりと呼ぶ前に、同じ管理者を通して一度再接続し、切断後も DNS が機能することを確認する。最初のネットワーク変更までしか動かない設定は未完成であり、ただ今動いているだけだ。

関連記事