AllowedIPs はルーティングの一覧であり、ファイアウォール規則ではない

送信トラフィックのピアを選び、受信元を検証します。アクセスリストではなく、ルート管理を無効にしても分割トンネルは直りません。

ほとんどの人は AllowedIPs を許可リスト、つまりピアに接続できるアドレスの集合として読み、トンネル用に書かれたファイアウォール規則のようなものだと考える。そうではない。このフィールドは両方向に働くルーティングテーブルであり、送信パケットのピアを選び、受信パケットの送信元を検証する。アクセスリストとして読むと、誰も要求していないトラフィックをルーティングする設定が生まれる。

一つのフィールド、二人の読者: 送信の選択と送信元の検査

クライアントでは、プレフィックスがどの宛先をそのピアへ送り、どれを通常のネットワークに残すかを決める。そのため 0.0.0.0/0 のエントリはすべての IPv4 宛先を捉え、フルトンネルのプロファイルをインポートすると通常の閲覧が遠隔マシンを通るのはこのためだ。狭いエントリは逆に、一覧に挙げたネットワークだけをルーティングし、残りは元の場所に残す。WireGuard のドキュメントの暗号鍵ルーティングの節は、送信ピアの選択と受信元の検証という二つの仕事を一か所で示している。

サーバーでは、同じフィールドが各ピアの使える送信元アドレスを表す。これはパケットフィルターではなく暗号的な検査であり、内部の送信元がピアの一覧と一致しないパケットは、ホストのどのファイアウォールが見るよりも前に WireGuard の内部で破棄される。二つの仕事は一つの一覧を共有しており、よそからコピーした一覧が想定していない場所で誤動作するのはまさにそのためだ。

クライアントのブロックこそ、この混乱のほとんどが始まる場所だ。分割トンネルは遠隔のネットワークを列挙し、フルトンネルは同じフィールドに既定のプレフィックスを入れたものである:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

どちらの形式もそれ自体で完結しており、手順ではなく選択肢である。前者はその二つのネットワークだけをトンネルに通し、後者はすべての宛先を送り、::/0 のエントリが IPv4 の既定に IPv6 を加える。どちらを選んでも、wg-quick がルートをインストールし始めた時点で、それらのプレフィックスがそのピアのルーティングの決定のすべてになる。

ハブには別の一覧が必要

ハブは各クライアントのトンネルアドレスをホストプレフィックスとして列挙し、そのクライアントの背後に本当にあるネットワークも加える。クライアントの広い一覧をハブの各ピアにコピーすると、多くのピアが同じアドレスを送信元に使えるとハブに伝えることになり、それはアドレス設計ではない。Endpoint フィールドはまったく別の層に属し、ピアの外側のアドレスとポートを示すもので、トンネル内部の宛先を決して示さない。

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

ホストプレフィックスがトンネルアドレスを運び、ネットワークプレフィックスがクライアントの背後にあるものを運び、どちらも必要だ。ホストプレフィックスがなければハブはクライアント自身のトラフィックを返せず、ネットワークプレフィックスがなければ背後の LAN は到達不能のままになり、背後に何もないピアはホストプレフィックスだけを受け取る。

ルートのインストールを飛ばすと隙間が残る

wg-quick は設定ファイルからインターフェースを立ち上げる補助ツールで、その仕事の一部としてインターフェースのアドレスとルートをインストールする。Table = off を設定すると、この補助ツールにルートの作業を飛ばすよう指示することになり、代替のルートをインストールせず、プライベートネットワークも到達可能にしない。自動ルートがすでに仕事をしているなら、必要なプレフィックスを書くほうが明確な設定だ。ルート管理を切り、代替を書かないままにするのは設計ではなく、抜けである。

基本の wg ツールは挙動が異なり、インターフェースを設定するがルートには決して触れないため、直接その上に組んだ構成には独自のルートコマンドが要る。一方のツール向けに書かれた手順を他方で実行すると、誤りに見えることがある。ping の成功も弱い証拠で、必要なすべてのアプリケーション経路ではなく一つの経路を試すだけだ。

DNS と IPv6 は別々に決める

トンネルが通知する DNS サーバーのアドレスを確認し、選んだプレフィックスを通じてそのアドレスへのルートが存在することを確かめる。リゾルバーの設定はリゾルバーを到達可能にはせず、トンネルを狭めるとそこへ通じていたルートが静かに消えることがある。IPv6 も単独で調べるべきだ、正しい IPv4 の分割は、今も物理リンクを指す IPv6 の既定ルートについて何も語らない。ピアのブロックを一つ編集すると、三つの別々の決定が同時に変わりうる。

次に、既知の初期設定からプライベートなリソースと普通の Web サイトを一つずつ開く。リソースが応答し、閲覧が今もローカル接続から出ていくなら、分割は頼んだとおりに働いている。同じ瞬間に閲覧が壊れるなら、トンネルが既定ルートを取ったということで、プレフィックスの一覧を見るべき場所だ。

関連記事