一つのテストLANに専用のWireGuard出口を与える方法

三つの設計が同じラボの問題を解きます：小さなLANはWireGuardピア経由で出て行き、ゲートウェイ自身は通常の上流回線を保つ、という問題です。魅力的な近道はルーターのデフォルトルートをトンネル内へ移すことですが、それでは筐体自身の管理経路と転送している他のすべてが壊れます。興味深い選択肢は、一つのインターフェースと一つのプレフィックスに限定したポリシールーティングです。実際に手元にあるマシンについて三つの問いに答えて選びます。

出口をどこに置くか決める

最初の問い：このホストは他の何かのために転送しているか？専用のラボ用ゲートウェイなら、既定で破棄する転送ポリシーで運用できます。本番の役割を負うルーターにはできませんし、管理されたファイアウォールの上に競合するルール群を重ねるのは、障害を予定表に載せる方法そのものです。二つ目：再起動をまたいで二つのポリシーオブジェクトとその順序を管理できますか？三つ目：手元のピアはトンネルの送信元アドレスを許可し、インターネットへの出口を提供しますか？プライベートネットワークだけを公開するピアは別の製品であり、ローカルのルーティング変更では直りません。どれかがいいえなら、出口は名前空間か使い捨ての仮想マシンに置いてください。

名前空間やVMはメモリを消費しますが、きれいな影響範囲が得られます。ポリシールーティングはルール二つ分で済み、デバッグすべき筐体は一台だけになります。

送信元を許可する出口を選ぶ

このラボの失敗のほとんどは、ファイアウォールのルールが一つも存在しないうちに起きます。出口の運用者は、変換後にパケットが持つ送信元アドレスを受け入れる必要があり、この設計ではそれがLANプレフィックスではなくトンネルアドレスです。だからこそマスカレードは後付けではなく、最初から設計に含まれます。

運用者に三点を確認します：ピアがトンネルアドレスを許可していること、自分自身で終端せずIPv4を転送すること、外向きNATを適用することです。一つ目がなければパケットは届いて消えます。三つ目がなければプライベートな送信元のまま出て行き、次のホップで死にます。次に、wg-quickが独自のデフォルトルートを入れていないことを確認します：これを防ぐのがTable = offであり、この設定が抑止するのはルート生成であって、ピアのAllowedIPs検査やDNSの扱いではありません。

二つのポリシーオブジェクトが誘導を担う

誘導にはテーブルとルールが必要です。テーブルは二つのルートを持ちます：LANインターフェースから出るLANプレフィックスと、トンネルから出るデフォルトです。ルールは、LANインターフェースに到着しそのプレフィックスを持つ通信をテーブルへ送ります。送信元一致に加えてiifセレクターを使うのは、ゲートウェイ自身のWireGuardパケットがローカルで発生し、受信インターフェースとは決して一致しないからです。

ガードは検索の後にではなく前に来ます。この順序が設計の安全特性そのものです。

ガードは同じセレクター上の二番目のルールで、その判定はunreachableです。トンネルが上がっている間は検索が勝ち続けるよう、より高い数値の優先度を与えます。トンネルのルートが消えると検索は何も返さず、ガードが探索を止めるので、メインテーブルのWANデフォルトへ抜けることはありません。

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

フォールバックの隙間は開ける前に閉じる

ガードを先に、検索を後に導入します。逆にすると数秒間の窓が残り、その間にテストクライアントの通信が上流回線に届き得ます。

フィルターが絵を完成させます。forwardフックでは、テストプレフィックスについてLANからトンネルへの方向と確立済みの戻り方向を許可し、それ以外はすべて破棄し、そのプレフィックスのトンネルインターフェースへのNATはpostroutingに置きます。転送チェーンにpolicy dropを残すことが、欠けたルートを漏洩ではなく沈黙に変えます。逆経路フィルタリングは、カプセル化を解かれて届く公開の送信元の最良の逆経路がWAN側にあるため、トンネルインターフェースで緩いモードが必要です。Linuxはallとインターフェースごとの値の高い方を採るので、トンネルインターフェースを設定することは、どこでも検証を弱めることとは同じではありません。

障害のケースで証明する

クライアントの送信元アドレスと、それが到着するインターフェースを名指しして、カーネルに正確な問いを投げます。両方がなければ検索は別の問いに答えるので、どちらの場合も正しく見えてしまいます。そのうえでファイアウォールのカウンター、ピアの転送状態、クライアント自身のサービスを見ます。

撤去をきちんと試験します。ルールとフィルターを残したままトンネルを止めると、クライアントは止まり、ゲートウェイ自身の通信は動き続けるはずです。次に、ローカルインターフェースに触れずにピアを止めるのが、ルートの存在だけに頼る設計を捕まえるケースです。最後に再起動してルール順序を再確認するのは、ガードを外す撤去フックが設計全体をメインテーブルに戻してしまうからです。テーブル番号、優先度、インターフェース名は、次にルールを追加する人がこれを壊す人だからこそ、変更チケットに記録してください。