UDP の VPN がポートスキャンに沈黙する理由

VPN のポートをスキャンして応答が返らないと、サービスが停止しているかファイアウォールが閉じていると結論しがちです。WireGuard や、独自の認証を伴う OpenVPN の制御チャネルでは、その結論は成り立ちません。有効な認証情報を持たないデータグラムは応答なしで破棄されるため、外から見た沈黙こそ健全なサービスの姿です。 トンネルより先に、その検査が間違っている。

沈黙はプロトコルであり、障害ではない

UDP には接続確立がないため、スキャナが開いたポートとフィルタされたポートを見分けるための SYN も確認応答もありません。検査は孤立したデータグラムとして届き、サービスはそれが想定するプロトコルに一致するかを確認します。一致しなければパケットは破棄され、破棄は不具合ではなく文書化された動作です。

WireGuard はハンドシェイクのメッセージを暗号学的に検証し、失敗したものはすべて無視します。 OpenVPN も tls-auth または tls-crypt により、制御チャネルで同じことを行います。どちらの場合も任意のペイロードが利用者に届く段階まで進むことはないため、返すべき応答もエラーもありません。

TCP なら閉じたポートからリセットが返っていたはずです。UDP は曖昧さを残し、スキャナは推測する代わりに open か filtered と出力してそれを解消します。

スキャナが結論できることと、できないこと

スキャン結果は、送ったペイロードの分だけしか情報を持ちません。想定される観測を、それぞれが実際に何を裏づけるかで並べてみましょう:

三行目だけがリストで唯一の積極的な試験です。本物のプロファイル、本物の鍵、正しいエンドポイントが必要で、それは一般的なスキャナにはないものです。

経路の両端を見る

自分が管理するサーバーなら、結論を出す前にインターフェースで捕捉し、そのうえでサービスに何を見たかを尋ねます。どちらのコマンドもゲートウェイで root が必要です:

tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg show

インターフェースにパケットが現れなければ、サービスが何かを見る前に経路がそれを捨てており、次の確認先はルーティングとフィルタリングです。パケットは届くのにハンドシェイクが完了しないなら、サービスには到達しており、食い違いは鍵、エンドポイント設定、プロトコル版のいずれかにあります。この比較が、スキャナには答えられなかった問いに答えます。実行するのは実際のクライアントが接続を試みている間であり、スキャナが同じことを繰り返している間ではありません。

変えるべきは試験であり、保護ではない

誘惑される近道は、診断に応答を返させるために制御チャネルの保護を無効にすることです。それは実際のセキュリティ特性を、見栄えのよいスキャン結果と引き換えにしており、方向が逆です。代わりに承認済みネットワークの有効なプロファイルを使い、比較を再現できるようエンドポイントと時刻を記録してください。

最も有用な試験は差分です。同じプロファイルを、通る経路と通らない経路で試します。通る経路でハンドシェイクが成立し、通らない経路でインターフェースに何も現れないなら、何も弱めることなく断点を特定できたことになります。

したがって、応答のない UDP パケットは、サーバーが停止していることも安全であることも証明しません。証明するのは、この検査が、この経路で、この瞬間に受け入れられなかったということだけです。