WireGuard のピアが 1 台だけ到達不能なときの確認手順

WireGuard のピアが一方は通信を通過させ、もう一方はハンドシェイクを完了するものの、トンネルの先の何にも決して到達しません。動作しているピアから分かるのは、インターフェース、UDP ポート、サーバーの鍵がおそらく正常だということだけです。もう一方のピアの AllowedIPs、その内部送信元アドレス、両者の間の転送ルールについては何も分かりません。リストを順にたどり、条件が崩れる最初の手順で止めてください。

手順 1: パケットがたどるべき経路を書き出す

同じハブ上の二台のクライアントは自動では互いに到達しません。ハブアンドスポーク構成では、サーバーが wg0 でパケットを受け取り、それを再び wg0 からもう一方のピアへ転送する必要があり、そのためには IP 転送と転送ルールが要ります。直接のピアツーピア構成では、双方が相手のエンドポイントと相手のトンネルアドレスを AllowedIPs の中に持つ必要があります。設定を読む前に、どちらの構成を調べているのかを決めてください。

想定した経路は、どこを見るべきかも教えてくれます。パケットがハブを経由すべきなら、失敗する区間は送信側の AllowedIPs、ハブの転送、受信側の AllowedIPs のいずれかです。直接通るべきなら、ハブは無関係で、両方のピアのエンドポイント項目が重要になります。

手順 2: AllowedIPs は片側ではなく両側で比べる

WireGuard は AllowedIPs を経路表とアクセスリストの両方として使います。送信時はトンネルを選ぶために宛先アドレスをピアの AllowedIPs で引き、受信時は内部送信元アドレスが送信側ピアの AllowedIPs の中に入っていなければパケットは破棄されます。どちらかの側で範囲が欠けていると、通信は通るのに中身が消えるという同じ症状になります。

再読み込みが黙って失敗している可能性があるため、設定ファイルではなく実際の状態を読んでください: sudo wg show wg0 allowed-ips。サーバー側では、失敗しているピアの項目にそのトンネルアドレス（たとえば 10.90.0.3/32）が含まれている必要があります。クライアント側では、サーバーピアの項目にテスト対象の宛先（ハブのトンネルアドレスでもリモートサブネットでも）が含まれている必要があります。範囲が重なると引き当てが曖昧になり、意図しないピアが選ばれかねないので、必ず分けてください。

手順 3: 内部送信元アドレスを確認する

10.90.0.3 を wg0 経由で経路設定しているのに、パケットを Wi-Fi アドレスから送り出しているクライアントは、送信元がピアの AllowedIPs と一致しないため受信側で拒否されます。カーネルが実際に何を選ぶのかを ip route get 10.90.0.3 from 10.90.0.2 で、トンネルインターフェースに割り当てられたアドレスを ip -brief addr show wg0 で確認してください。

受信側の Linux ホストでは、逆経路フィルタリングが第二の関門になります。戻り経路を持つインターフェースに厳格な rp_filter が設定されていると、到着したインターフェースと戻り経路が一致しないトンネル通信が落とされます。無効にする前に有効値を確認し、多くのトポロジーでは正しい修正は緩めたフィルタではなく経路の追加だと心得てください。

手順 4: ハブの転送と戻り経路を見直す

ハブがピア間を転送する必要があるなら、カーネルに net.ipv4.ip_forward=1 が要り、ファイアウォールは転送されるフロー（wg0 に入り、wg0 から出て、送信側のトンネルアドレスから受信側へ向かうフロー）を受け入れる必要があります。よくある失敗は UDP 51820 を受け入れる入力ルールはあるのに転送ルールがないこと]で、その場合ハンドシェイクは成功するのに中身が死にます。有効なルールは sudo nft list ruleset、またはお使いのファイアウォール管理ツールの相当するコマンドで一覧にしてください。

次に応答を確認します。宛先ホストは送信元への戻り経路を持たねばならず、それはハブ経由でも自身のゲートウェイ経由でもかまいません。ハブがトンネルのサブネットに NAT もかけているなら、変換が転送フローに適用され、状態が失効する前に応答がハブへ届くことを確認してください。鍵の問題に見える片方向の失敗は、しばしばこの戻り経路だけが原因です。

最後に、ハンドシェイクとデータを切り分けます。ハンドシェイクは完了するのに大きな転送で止まるピアは、たいていその経路固有の MTU か MSS の問題を抱えており、AllowedIPs の問題ではありません。まず小さな ping で、次にフルサイズの ping で試し、二つのピアを比べてください。

手順 5: 変更は一つに絞り、動いているピアはそのまま残す

失敗している経路に一つだけ変更を加え、両方のピアを再試験します。すべてのピアの AllowedIPs を 0.0.0.0/0 に置き換えるのは、すでに動いていたピアを壊す最短の道で、そのインターフェース上のすべての通信の経路判定が変わってしまいます。その一件だけを編集し、再読み込みして、実際の状態を読み直してください。

どの経路が成功し、どれが失敗したのか、そしてそれぞれの正確なコマンド出力を記録してください。その比較は VPN が壊れているという一般的な報告より価値があり、次の担当者が最初に求めるものです。