WireGuard: wg-quick における二本のハーフルートと 0.0.0.0/0
二つの /1 は /0 と同じアドレスを覆いますが、wg-quick の扱いは異なります。編集前にポリシールール、マーク、エンドポイントの経路を確認してください。
二つの /1 プレフィックスは、一つの /0 とまったく同じ IPv4 アドレスを覆いますが、その等価性はピアの許可プレフィックス一覧の内側でのみ成り立ちます。セットアップツールが経路を決めた瞬間に、つまり Linux の wg-quick がデフォルトプレフィックスを算術ではなく特別扱いするために、成り立たなくなります。特別分岐は専用テーブル、二つのポリシールール、ソケットマーク、逆経路の設定を入れるもので、ハーフルートの組はそれらを一切受け取りません。したがって編集後にプロキシやブラウザが動かなくなったとき、プレフィックスは変更のうち最も興味の薄い部分です。
プレフィックス一覧だけが設定のすべてではない
AllowedIPs は同時に二つの仕事をしており、覆いに関わるのはその片方だけです。WireGuard 自身にとってこの一覧は暗号鍵ルーティングであり、どの宛先がピア方向に暗号化され、そのピアがどの送信元アドレスを使えるかを決めます。wg-quick にとって同じ一覧は経路仕様も兼ね、生成される経路は一覧がたまたまどの分岐に一致するかで変わります。二つの異なる一覧形状で覆いが同じでも、ホストの状態が同じだということにはなりません。
デフォルト設定はその判断を利用者の手から取り上げます。なぜなら Table は既定で自動であり、経路がどこに落ちるかはツールが選ぶからです。別のネットワークマネージャ、ディストリビューションのラッパー、独自の Table 値は結果をまた変えるため、あるホスト向けに書かれた助言が次のホストでは誤って見えることがあります。
デフォルト分岐が経路以外に加えるもの
/0 の項目は wg-quick をデフォルト経路の道筋へ送ります。別のルーティングテーブルがデフォルトを受け取り、一つのポリシールールがマークのない通信をそこへ送り、二つ目のルールがメインテーブルのより具体的な経路を優先させ、インターフェースは自身のソケットにファイアウォールマークを受け取ります。このマークがループの番人です。トンネル通信を運ぶ暗号化データグラムはマーク付きで出ていくので、それ以外すべてをトンネルへ向けるルールがトンネル自身の転送パケットを飲み込むことはありません。
代わりに /1 の二項目は通常の経路をたどります。設定されたテーブルに二本の経路が落ち、周辺の仕組みはどれも現れません。不要だからではなく、そのコード経路に入らなかったからです。
二つの構成が分かれる場所
相違はまず再帰として現れます。メインテーブルにハーフルートがあると、ピア自身の転送アドレスがトンネルのプレフィックスに入るため、トンネルを運ぶべきパケットがトンネル内向きの経路に一致します。何かがそれを除外しなければなりません。現在のエンドポイントへのホスト経路、手動で付けたマーク、インターフェース固有のルールのいずれかです。 ホスト経路はエンドポイントのアドレスが変わるまで機能します。これは DNS ベースのエンドポイント、移動するクライアント、複数ピアの構成で起こります。
次に、マークについて推論するものはすべて挙動が変わります。接続をローカルでリダイレクトする透過プロキシは、マークと送信元が元のクライアントフローと異なる新しいソケットを作り、デフォルト分岐が生成するポリシールールはそうしたフローを振り分けていた要素の一部でした。プロキシ自身の外向き接続を読むのは、元の宛先に到達できるかを試すのとは別の作業です。
編集前にルールとマークを読む
トンネルが健全なうちに現在の状態を記録し、変更後にもう一度記録して、設定ファイルから推論するのではなく二つのダンプを比較してください。ポリシールール、すべてのテーブル、インターフェースのマーク、記録されたエンドポイントを含めます。
ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints
出力の一行目がマークなし通信のルールを失い、専用テーブルが空なら、デフォルト分岐は動いていません。プレフィックスの算術ではその効果を戻せません。以前マークを持っていたインターフェースでマークがゼロになっているのも同じ合図で、一つの値で見えます。
配布前にトンネル断絶を練習する
ハーフルートの配置を意図的に選ぶなら、欠けている部分を明示的に用意しなければなりません。アドレス変更に耐えるエンドポイント経路、トンネルが落ちたときの意図した挙動、IPv6 に対する同等の扱いです。障害時に発見するのではなく要件として書き出し、そのうえで失敗を練習してください。物理アップリンクへ黙って戻る完全トンネルは、動かなくなるトンネルより悪いからです。
sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1
経路の検索はトンネルを経由せずに物理インターフェースからエンドポイントを解決すべきであり、インターフェースを下ろしたときホストは設計が約束した状態に残るべきです。置き換え後に動くプロキシは、生成されたホスト状態が重要だったことを示しますが、ループ防止と停止状態の挙動が変更を生き延びたことは示しません。