一つのWebサイトだけをWireGuardトンネルの外にルーティングする方法

ホスト名を除外することは、トンネルにはできない。しかしルートなら、一つのアドレスだけをトンネルの外へ、家庭のゲートウェイ経由で送り出せます。一つのサイトならそれで通常は足ります。難しいのは、ルートより下流のすべてが一致していなければならないことです。ファイアウォールはパケットを外に出さなければならず、DNSはルーティングしたアドレスを返さなければならず、サイトはそのアドレスを使い続けなければなりません。三つのうちどれか一つがずれると、例外は自分から知らせないまま機能しなくなります。

トンネルに触れる前に宛先アドレスを読む

トンネルを上げた状態でサイトを一度読み込み、ブラウザが実際に接続したピアアドレスを見ます。Linuxでは、 ss -tunp が開いているすべてのソケットのリモートアドレスを一覧表示し、 dig +short が同じ名前についてリゾルバが返したものを表示します。両方の数値を目の前に置いておきます。

二つの答えはしばしば食い違い、その食い違いこそが問題のすべてです。大規模サイトはオリジンの前にコンテンツネットワークを置くため、リゾルバが今返すアドレスは、ブラウザが一分前に使ったものではないかもしれません。古いガイドが載せているものではなく、ソケットで観察したほうをルーティングしてください。答えが地域ごとに回り続けるなら、そのサイトにはアドレス例外は不適切な道具です。

別のネットワークからもう一度検索を実行し、IPv4の答えと一緒にIPv6の答えも記録します。両方のファミリーを運ぶトンネルは両方に例外が必要で、そうでなければブラウザは触れてもいないIPv6の経路へ静かに戻ってしまいます。アドレスと日付は、後でまた見る場所に書いておきます。

クライアントにホストルートを一本置く

インターフェース名がhome-wgで、LANルーターが192.168.1.1にあるとします。NetworkManagerは、ゲートウェイがそのルーターで、プレフィックス長が32ビット全体を覆うルートを引き受け、最長プレフィックスが勝つためカーネルはそちらを優先します。

nmcli connection modify home-wg +ipv4.routes "198.51.100.20/32 192.168.1.1"
nmcli connection up home-wg
ip route get 198.51.100.20

ゲートウェイはトンネルなしで到達できなければならず、次のホップをトンネルのアドレスに向けるのは、避けたいインターフェースにパケットが再び入ってしまうため目的に反します。接続が再び上がったら、 ip route get 例外についてLANゲートウェイが表示されるはずで、公開リゾルバに対する同じコマンドは依然としてトンネルデバイスを表示するはずです。

wg-quickのプロファイルにはルートのフィールドがないため、同じ例外は PostUp 行に置かれ、ホストルートをLANインターフェースをデバイスとしてメインテーブルに追加します。編集後はインターフェースを下げてから上げ直してください。稼働中のインターフェースはファイルを読み直さないからです。wg-quickがインストールするfwmarkルールは自分自身のカプセル化パケットだけを誘導するので、通常のブラウザ通信はメインテーブルに従い、あなたの/32を見つけます。

キルスイッチが次にそれを妨げるもの

トンネルインターフェースでのみ通信を許可するファイアウォールポリシーは、ルートが完全に正しくても例外を落とします。スイッチを信じるのではなくスイッチの背後のルールを読みましょう。キルスイッチを実装するルールは通常、インターフェース名に限定されているからです。

必要なのは、物理インターフェースとその一つの宛先に対する狭い許可をドロップの前に置くことで、既定のポリシーはそのままにします。キルスイッチを丸ごと一時停止すれば要点は証明できますが、戻し忘れている間ずっとマシンを露出させてもしまいます。

二つの方向を別々に試します。例外のアドレスへの要求は成功し、無関係なサイトへの要求は依然としてトンネルから出るはずです。両方成功しても二番目が家庭のアドレスを報告するなら、間違っているのはファイアウォールのルール順であり、ルートではありません。

どのアドレスにブラウザが発信するかはDNSが決める

名前がトンネルの内側で解決されると、プロバイダのリゾルバはローカルのものとは異なるアドレスで答えることがあります。するとあなたのルートはブラウザが決して接続しないアドレスに適用され、ページは何も変わっていないかのようにトンネル経由で読み込まれます。ルーティングテーブルが正しくても、この失敗は壊れた例外のように見えます。

その名前のクエリもローカルリゾルバ経由で送るか、名前を完全に飛ばしてアドレスを直接試してください。DNSをトンネルの内側に残したままアドレスを分けるのはこの設定で最もよくある半端な形で、サイトは動き続けるものの意図したようには動かないため、最も気づきにくいものでもあります。

ルーター側でも同じ例外を、一度だけ、すべてのデバイスに

トンネルがルーターで動いている場合、ホストルートはルーターのポリシールーティングテーブルに属し、LANゲートウェイではなくWANゲートウェイを指します。その背後のすべてのデバイスが例外を継承するので、ストリーミングボックスや、ネットワーク設定を変えられない仕事用ノートPCには重要です。

他のすべてのクライアントにはトンネルを既定の出口として残し、ルーターのコンソールではなくクライアントマシンから確認します。同じブラウザセッションで例外のサイトともう一つのサイトを読み込み、出口アドレスを比べます。二番目がまだトンネルを示すなら、ポリシーテーブルは求めどおりに動いています。

アドレス、日付、理由をルーターのメモに書き留めます。後で移動するアドレスの周りに作られた例外は、一年後に誰も説明できない不具合になります。そして古いメモが見つかるまで、修正はいつも謎のように見えます。