WireGuardのハンドシェイクは成功するのにオフィスのサブネットが応答しない

ハンドシェイクは完了し、 wg show は最近の転送を報告し、サーバーのトンネルアドレスはpingに応答します。しかしサーバーのLAN上のホストは応答しません。三つの条件が同時に成り立つ必要があります。クライアントがLANのプレフィックスをトンネルへルーティングすること、サーバーがパケットを転送すること、そして応答には戻り経路が必要です。三つのうち一つが欠けると、症状は同じです。

AllowedIPsはアクセスリストであり、同時にルーティングテーブルでもある

クライアントでは、 AllowedIPs リストが、そのピアに何を送れるかと、WireGuardがどのルートをインストールするかの両方を決めます。サーバーのトンネルアドレスだけを列挙したピアエントリはホストルートを一つだけインストールするため、LANの宛先はトンネルに入りません。LANのプレフィックスを追加することが最初に確認すべき点であり、コピーした設定で最もよく欠ける変更でもあります。デフォルトルートまで広げたピアは別の設計であり、クライアントのインターネット通信も移動させます。

ホストルートとLANのプレフィックスは別々のエントリとして保ってください。オフィスに二つのサブネットがあるなら、両方がリストに入ります。二つ目のプレフィックスが欠けると、全体ではなく選択的に見える障害になります。

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

転送と変換はサーバー側の仕事

サーバーにはIP転送の有効化、トンネルから来る通信を受け入れる転送ルール、そしてLANインターフェース向けの変換ルールが必要です。この変換があるからこそ、オフィスのネットワークの全ホストに触れずに設計が機能します。応答はLANが聞いたことのないアドレスではなく、サーバーへ戻ります。これがなければ、各ホストにトンネルサブネットへのルートとそれを許可するファイアウォールルールが必要になり、他人が管理するネットワークではほとんど受け入れられません。

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

手で追加したルールは再起動で消えるので、サーバー設定のhookコマンドでインターフェースに結び付けてください。インターフェースより長生きするルールセットは、もはや存在しないトンネルのためにマシンが通信を変換し続ける原因になります。

LANが移ったのにルールが移らなかったとき

オフィスのサブネットを再採番するルーター交換は、この障害の典型的な形です。トンネルは上がったまま、ハンドシェイクも新しいまま、サーバーの背後は何も応答しません。変換ルールがまだ古いアドレスを指しているからです。インストーラーのスクリプトはサーバーのLANアドレスをPOSTROUTINGルールに埋め込むことが多く、再採番の後ではそのアドレスはどのインターフェースにも存在しません。するとパケットは応答できない宛先へ書き換えられます。

iptables -t nat -n -L POSTROUTING
ip -br addr show

二つの出力を比べてください。インターフェース一覧に出てこない変換先がバグであり、一度見れば修正は一行の変更です。ルールはWireGuardの設定ではなく生成されたunitにある場合があるので、編集後にそのunitを再読み込みし、次の起動で変更が上書きされないことを確認してください。

NATの背後にある二つの拠点には待ち合わせの場所が要る

どちらの側も内向きの接続を受け入れない場合、実用的な答えはパブリックアドレスと二つのWireGuardインターフェースを持つ小さなホストです。各拠点は外へ接続し、中央のホストは各ピアのLANを自分の AllowedIPsに列挙し、転送が二つのトンネル間でパケットを運びます。どちらの拠点のファイアウォールも変更する必要がなく、だからこの設計は広がりやすいのです。

拠点間のルーティングは元の送信元アドレスを保つため、ホストごとのログが意味を持ち続けます。二つのLANが重なる場合は中央のホストでの変換が簡単ですが、ログで送信元の同一性を失う代償があります。選ぶ前にどちらの性質が重要かを決めてください。

四つの確認で層を分ける

三つを変えて願うのではなく、層ごとに一つずつ確認してください。一つ目は各ピアのハンドシェイクの経過時間とカウンターを示します。二つ目はクライアントがその宛先を実際にトンネルへルーティングしているかを示します。三つ目と四つ目は、要求が届いたか、届いた後にポリシーが破棄したかを教えます。

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

届いても応答が返らない要求は、応答の経路かLANのホストを指します。まったく届かない要求は、 AllowedIPs またはクライアントのルートを指します。この二つの結果は別の修正を必要とし、キャプチャがそれを見分けます。