WireGuard はデータを送るが何も戻ってこない：どちら側か

受信カウンターがゼロのまま送信カウンターだけが増えるのは、方向を示しているのであり、診断ではありません。同じ読み取り値は、ピアがハンドシェイクを完了していないとき、宛先が誤ったピアを選んだとき、遠端に戻り経路がないとき、フィルターが戻り道で応答を捨てているときにも現れます。それぞれの修復箇所は別です。

作業を短くする比較は、トンネルを出なかった要求と戻ってこなかった応答のどちらなのかを見ることです。正しいインターフェースでの一度のキャプチャで二者は決まります。

カウンターが示すのは量であり、障害の方向ではない

WireGuard のカウンターは、インターフェースがピアに渡した量と、ピアから受け取った量を記録します。どの宛先、どのピア、交換のどちら半分が失敗したかは示しません。バックグラウンドの通信があると、一部のバイトがキープアライブや無関係なフローかもしれないため、合計値はさらに曖昧になります。インターフェースが動いている証拠として読み、それ以上の判断材料にはしないでください。

まず役に立つ事実は、ハンドシェイクが最新かどうかです。それがなければ、このピア向けに暗号化されたものは何もなく、受信カウンターが動く理由もありません。

ピア選択か戻り経路か：二つの説明

一つ目の説明は、経路が別の場所を指していたか、ピアの許可プレフィックスが宛先を覆っていなかったため、パケットが目的のピアに届かなかったというものです。二つ目は、パケットは届いたが応答が戻れなかったというもので、これは遠端のルーティング問題です。表は、各地点で何を観測するかによって両者を分けています。

表は上から順に読んでください。ハンドシェイクがなければ、まだ他に調べるものがないので、鍵、エンドポイント、外側の経路へ進みます。ハンドシェイクが最新で、要求がサーバー上に見えるなら、問題は戻り方向に移り、そこでは宛先自身のルートテーブルが決めます。サーバーにまったく現れない要求は選択の問題であり、両方のピアの許可プレフィックスが最初に比べるべき点です。

この四行のうち二行はクライアントで、二行はサーバーで直します。どちらの組にいるかを知ることが作業の大半です。

応答が消える場所

応答は宛先を出て、サーバーのトンネルインターフェースに届き、許可アドレスがクライアントの内部アドレスと一致するピア向けに暗号化されます。その一致が失敗すると、応答は黙って破棄され、クライアント側からはネットワーク障害とまったく同じに見えます。応答が暗号化されていて、クライアント自身のフィルターがそれを拒否する場合も、症状は同じです。どちらの場合もカウンターではなくキャプチャが必要です。

この誤りの最も強い形は、クライアントのためにパケットを転送するのに、クライアントの内部範囲への戻り経路がないサーバーです。要求は受け取り、応答は既定ゲートウェイへ送り、トンネルはそれを見ません。サーバーに足した広い変換ルールは、経路を直す代わりにその障害を隠します。

一つの宛先を端から端まで試す

ピアの範囲内で宛先を一つだけ選び、ハンドシェイクが明らかに最新のうちに試します。以下のコマンドはピアの状態、選ばれたルート、交換の両側を読みます。暗号化されたパケットが実際に使うインターフェースでキャプチャを実行します。

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

トンネルインターフェースに要求が見えるのに何も戻らないキャプチャはサーバー側の答えであり、次に見るべきは宛先のルートテーブルです。まったく何も現れないなら、パケットは別の経路を通っているので、ローカルのルートが疑わしい対象です。両方のキャプチャに見えるのにアプリケーションが進まない交換は、問いをパケットサイズか、インターフェース統計に現れないフィルターへ移します。試験では、二つ目の変数が証拠を再び印象に変えてしまうため、宛先もクライアントも一つに保ってください。

許可されたアドレスは機能するのに名前が失敗するなら、答えはトンネルではなく DNS にあります。大きな転送だけが止まるなら、パケットサイズを別に調べてください。