WireGuard が動くのはサーバーが先に送ってから：エンドポイントの知識

トンネルは、サーバーが先に何かを送ってからでないと動かないように見えます。クライアントから開始しても何も起こらず、数秒待って再試行すると成功します。よくある診断は壊れた NAT ですが、その診断は誤りです。変わったのは、一方のピアがもう一方の居場所を学習したことです。

到達可能性ではなくエンドポイントの知識

WireGuard のピアは、どこへ送るべきかを知るまでハンドシェイクを開始しません。設定はそれをアドレスとポートからなるエンドポイントとして与え、実行中の状態は現在信じているエンドポイントを追跡します。

wg show はその全体の両側を表示し、出力にエンドポイントがないピアは、公開鍵と許可されたプレフィックスがどれほど正しくても何も開始できません。ルールを変更する前に、クライアントの見方とサーバーの見方を比較してください。どちらが何を知っているかについて、両者はしばしば一致しません。

ピアがエンドポイントを学習する仕組み

WireGuard は意図的に静かです。正しく認証されたパケットがピアの予期しないアドレスから届くと、実装はそのピアのエンドポイントを新しい送信元に更新し、ネットワークを切り替えるノート PC でローミングが機能するのはこのためです。この挙動が方向依存を説明します：サーバーが先に送り、そのパケットがクライアントに届けば、クライアントはサーバーの現在のアドレスを学習して応答できます。それまでは送り先がありません。この仕組みは初回接続を信頼する近道ではなく認証されたローミングで、エンドポイントが動く前にパケットが有効でなければならなかったからです。

wg のツールのドキュメントにはその更新が説明されており、これを前提に設計するなら一度読む価値があります。

状態を持つ変換は独自の方向を加える

UDP が変換を行うゲートウェイを通過する場合、ゲートウェイは最初に見たパケットの状態を作ります。RFC 4787 はその挙動と、最終的に対応付けを削除するタイムアウトを説明しています。未使用の対応付けは失効し、遠端からの受信パケットはホストに届く前にゲートウェイで破棄されます。朝の間ずっと動いていたトンネルが午後に応答しなくなるのは、まさにこの理由です。

これは同じ方向性の症状を生む二つ目の独立した仕組みです。エンドポイントの知識と変換の状態の両方が正しくなければならず、片方を直してももう片方は直りません。

本当に必要な方向を設定する

接続を開始しなければならないクライアントでは、サーバーのエンドポイントをクライアントのピアセクションに置き、そのままにしてください。サーバーが先に送ることに頼るのは、静かなネットワークで変わるトラフィック順序の偶然に頼ることです。設定は意図した方向を明示すべきで、発見させるべきではありません。

変換の背後にあり到達可能であり続ける必要があるピアでは、その側で永続的な keepalive を有効にしてください。25 秒ごとの keepalive が通常の開始値で、その目的はトンネルを試すことではなく対応付けを開いたままにすることです。両側で有効にすると結果を改善しないままトラフィックとログのノイズが倍増するため、運ぶ側を一方に選んでください。

トリガーの前後で状態を比較する

失敗した瞬間に二つの見方を取得し、サーバーが送った後にもう一度取得します。最初のコマンドはエンドポイントとハンドシェイクの経過時間を示します。二つ目はそのポートの変換エントリがあるかどうかを示します。取得結果はどちらの方向が実際に回線を越えたかを示し、ルート確認はクライアントがそのトラフィックを全く別の場所へ送っていないことを確かめます。

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

エンドポイントの列と変換エントリを一緒に記録してください。エンドポイントのないピアと対応付けのないゲートウェイは別の障害です。keepalive で直るのはそのうち一方だけです。