WireGuard の分割トンネル：デフォルトルートなしで設定する

分割トンネルは何を除外するかで決まり、WireGuard はその判断をひとつのフィールドで行います。クライアント側ピアの AllowedIPs は、どの宛先がトンネルを通るかを選ぶと同時に、どの内部送信元アドレスを受け入れるかを絞り込み、wg-quick は同じ一覧をホストルートに変換します。一覧を間違えると、トンネルはすべてを飲み込むか、何も運びません。

まずプレフィックスの一覧を決める

設定ファイルに触れる前に、トンネルを使う必要のある宛先を書き出します。オフィスのサブネット、データベースの範囲、管理ネットワークは、それぞれ理由のあるプレフィックスです。一覧にないものは物理経路に残り、それこそが設計の狙いです。

一覧に 0.0.0.0/0 や ::/0 が含まれるなら、障害の仕方と DNS の期待が異なるため、それはフルトンネルであり、そう言うべきです。

後でレビュー担当者がルーティングテーブルと照合できるよう、一覧は短く保ちます。

クライアント設定：ピア、AllowedIPs、DNS

クライアントのインターフェースブロックには自身のトンネルアドレスと秘密鍵が入り、ピアブロックにはサーバーの公開鍵、エンドポイント、最初の手順のプレフィックスが入ります。

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

クライアント側の AllowedIPs はリモートの宛先の集合であり、クライアント自身のアドレスではありません。DNS 行は wg-quick のリゾルバ連携を通じてのみ有効なので、resolvconf や systemd-resolved に対応しないホストでは無視されます。PersistentKeepalive は NAT マッピングを維持するもので、直接経路では不要です。

各プレフィックスにはそれが提供するサービスをコメントとして添えないと、次の編集は当て推量になります。

サーバー設定：反対側の視点

サーバーでは、ピアのエントリがクライアントを表すため、その AllowedIPs はクライアントのトンネルアドレス、通常は /32 です。オフィスのサブネットではありません。クライアントの一覧をサーバーのエントリにコピーするのは分割トンネルで最も多い誤りで、アクセスを広げるか、ハンドシェイク時の内部送信元チェックを壊します。

サーバー自身のインターフェースアドレスと、オフィスへ向かうために必要なルートは、どのピアエントリとも別です。

二つのファイル、二つの視点、その間に分かれた一組のプレフィックス。

起動してルートを読む

対応する管理ツールでインターフェースを起動し、意図した内容ではなく、実際に何がインストールされたかを見ます。wg-quick は AllowedIPs からルートを導き、プロファイルが Table = off を設定していれば何もインストールされず、ルーティングは自分で書くことになります。プレフィックスごとにルートを読み、WireGuard インターフェースを指していることを確認します。ルート一覧が空なら、適用されたプロファイルが編集したものではない可能性が高いです。

ハンドシェイクのないピアはルーティングではなく鍵、エンドポイント、到達性の問題を抱えているため、ハンドシェイクのカウンタも確認します。

次に担当する人は追い込まれた状況で実行するのだから、使ったコマンドをそのまま書き残します。

両側を検証し、ロールバックを記録する

プライベートアドレス、その内部名、そして直接のままであるべき宛先を試します。プライベートアドレスが通り、直接の宛先がトンネルから出ていくなら、プレフィックスの一覧が広すぎます。アドレスは通るのに名前が失敗するなら、DNS 行が効いていません。ロールバックは一つのコマンドで、同じメモに残します。

プロファイルを再適用する管理ツールは手動のルートを置き換えることがあるため、再接続後、ルートがまだあることを確認します。

同じインターフェースを二つの管理ツールが作ればいずれ食い違うので、設定の所有者は一人にします。wg-quick のマニュアルに、提供されるルートと DNS の挙動が記載されています。