UDP スキャンが「フィルタ済み」と言うとき、その WireGuard ピアは本当に落ちているのか

スキャナは UDP ポートについて「開放」か「フィルタ済み」を出力し、多くの場合数秒で「トンネルが壊れている」という結論が出ます。そうかもしれませんが、スキャンはそれを証明していません。UDP には接続のハンドシェイクがなく、WireGuard は認証できないものには一切応答しないため、ほとんどのプローブにとって沈黙は想定どおりの返答です。

代わりにクライアントから外側へと調べ、スキャンは数ある弱いデータ点の一つとして扱ってください。

スキャナに分かること、分からないこと

UDP スキャナはペイロードを送って待ちます。ICMP port-unreachable が返れば、ポートを閉鎖として報告できます。何も返らなければ、結果は設計上あいまいです：フィルタされた経路、存在しないホスト、ペイロードを無視した稼働中のサービスは、どれも同じ沈黙を生みます。三つの異なる状態が、一つの出力文字列になります。

WireGuard はそのあいまいさを意図的に悪化させます。プロトコルは認証できたパケットだけを受け入れるため、誤った鍵のプローブは応答なしで破棄されます。バナーもバージョン文字列もなく、指紋を取るためのエラーメッセージもありません。

同じポート番号での TCP テストは、関係のないものを試すだけです。存在しないかもしれない別のリスナを動かし、その拒否は UDP について何も語りません。

つまり「開放・フィルタ済み」という状態は、あなたのサーバよりもスキャナの不確かさを正確に表しています。

実際のクライアントをプロファイルから内側へたどる

まずクライアント自身の見え方から始めます。インターフェースにアドレスがあるか、設定が正しいエンドポイントを指しているか、接続を試みたときにハンドシェイクのカウンタが動くか。パケットを一度も送っていないクライアントと、パケットが破棄されたクライアントは、ステータス画面では同じに見えます。両者を区別できるのはカウンタだけなので、まずカウンタを読んでください。

次に、第三の場所から別のスキャンを回すのではなく、許可された試行が一度行われている間にサーバ側を観察します：

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

最初のコマンドはピアごとの最後のハンドシェイクを報告し、認証された交換が完了した直接の証拠になります。二つ目はリスナ宛てのパケットが届いているかどうかを示し、経路の問題と設定の問題を一歩で切り分けます。

キャプチャに何も出なければ、パケットはホストに届いておらず、トンネル設定は容疑者ではありません。期待したアドレスからパケットが届いているのにハンドシェイクがゼロのままなら、次に見るべきは鍵かピアの許可アドレスです。

自分で管理しているならサーバ側で突き合わせる

リスナが存在し、プロバイダのファイアウォールが UDP ポートを許可していることを確認します。ホストのファイアウォール規則とクラウドのセキュリティグループは独立した二つの関門で、どちらも相手が許可したパケットを落とせます。覚えているポートではなく、設定にある実際のポートで両方を確認してください。

アドレスはポートと同じくらい重要です。特定のアドレスで待ち受けるサーバは、別のアドレスに届いたパケットには応答せず、複数のインターフェースを持つホストでは、意図しない側でプローブを受け取ることがあります。

すべてのテストは、テストを許可されたシステムの内側に留めてください。有用な比較は、実際のクライアント試行一回と想定されるサーバ経路の間のものであり、同じプロバイダにたまたま属するアドレスを広く走査することではありません。

スキャン結果を正直に読む

スキャンは、ホストが存在し、ポートが中間装置に明らかに遮断されていないことを確かめる安価な方法です。認証されたプロトコルの到達性の証明ではなく、設定テストでも決してありません。

より強い証拠は、本当に重要なクライアントからの完了したハンドシェイクと、それに続くトンネルを使った要求への応答です。その順序は、鍵、許可アドレス、両方のファイアウォール、戻り経路を一度に試します。

実際の試行が失敗した場合も、別のプローブではなく、クライアントのカウンタとサーバのキャプチャで診断する必要があります。プロトコルの説明は、認証されていないパケットが応答を受け取らない理由を説明しており、スキャン結果があいまいである理由はまさにそこにあります。