WireGuardのハンドシェイクは成功するが、応答が返らない

最近のハンドシェイクは良い知らせですが、人が書きがちな一文よりずっと小さな主張です。両ピアは認証済みのハンドシェイクメッセージを交換しました。アプリケーションのパケットは、依然として内部の宛先に届いて戻ってくる必要があります。

健全な制御プレーンと沈黙したデータプレーンの間のこの隙間が、ここでの主題そのものです。同じカウンターの二回の読み取りが、どちら側にいるかを教えてくれます。

ハンドシェイクが証明するのは鍵であり、配送ではない

WireGuardのハンドシェイクは認証を伴う鍵合意です。両ピアが互いに到達でき、有効な鍵を持ちさえすれば成功します。ルーティング、ファイアウォールの方針、宛先そのものはハンドシェイクが決して問わない問いです。

つまり、トンネルは完璧に確立していながら、その中のすべてのパケットが破棄されていることがあります。誤ってルーティングされた内部パケットと別の経路を通る応答は、クライアントから見ると同じに見えます。

内部アドレス一つが試験のすべて

宛先を一つ選び、それに固定します。相手ピア自身のトンネルアドレスが最も簡単な例で、その背後のホストはちょうど一ホップを加えます。変更を記録せずに両者を切り替えると、誰も比較できない結果になります。

次に、クライアントが選ぶ経路を見ます。より具体的なローカル経路は、WireGuardに問い合わせる前にパケットを別の場所へ送ることがあり、これは家庭内LANがリモートの範囲と重なるたびに起こります。

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

物理インターフェースに解決されるアドレスは、すでに問いに答えています。トンネルは何も破棄していません。パケットはそこに一度も入っていません。

カウンターは証拠であり、判決ではない

wg showはピアごとに送受信したバイト数を報告し、二つの数は独立に動きます。一回読み取り、許可された要求を一つ実行し、同じ分のうちにもう一度読み取ります。

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

受信が横ばいのまま送信が増えるのは、応答のない要求の署名です。要求がフィルタされたのか、宛先が落ちていたのか、応答が別の経路を通ったのかは分かりません。これは一つの症状を共有する三つの調査です。設定を変える前に、それらを切り分けてください。

固定のバイト数も成功のしきい値ではありません。カウンターの値はトラフィックに従い、一つの数値を健全性の証拠として扱うと、自信に満ちた無意味さが生まれます。

相手ピアが戻りのパケットを自分で確認する

遠い側のピアは、送信元がそのピアのallowedipsの内側に入るときだけ内部パケットを受け入れます。送信側に経路があっても十分ではありません。受信側に送信元の登録がなければ、戻りのトラフィックは静かに破棄されます。

その確認の背後にホストのファイアウォールがあります。トンネルインターフェースは許可するが内部サブネットは許可しない転送ルールは、ハンドシェイクを受け入れ、パケットを拒否します。クライアント側から見ると、それはまさに死んだピアのように見えます。二つのインターフェースを持つホストが誤った送信元から応答することもあり、その場合ピアは予期しなかった応答を捨てます。

実験を誠実に保つ

到達すべき家庭内ネットワークからリモートアクセスのプロファイルを試すと、意図した経路とは別の経路を練習することになります。外部ネットワークに移り、そのローカルプレフィックスを記録して、二回の実行を比較できるようにしてください。

小さなやり取りが成功しても、すべての経路の問題を除外できるわけではありません。大きなパケットは小さなものが通る場所で失敗することがあり、サイズやプロトコルで一致するフィルターは負荷の下で違う振る舞いをします。

ハンドシェイクを動作が既知の段階として保ち、そこから先へ進みます。次の有用な証拠は、一つの内部要求がどこで止まるかであり、新しい鍵の一式やもう一巡の推測ではありません。