VPN UDP silencieux lors d’un scan de ports ? Pourquoi cela arrive

Vous scannez le port du VPN, vous n’obtenez aucune réponse et vous concluez que le service est arrêté ou que le pare-feu est fermé. Avec WireGuard, et avec les canaux de contrôle d’OpenVPN qui portent leur propre authentification, cette conclusion ne s’ensuit pas. Un datagramme dépourvu de matériel d’authentification valide est écarté sans réponse, donc le silence est l’aspect d’un service sain vu de l’extérieur. La sonde est fausse avant que le tunnel ne le soit.

Le silence est le protocole, pas une panne

UDP n’a pas d’établissement de connexion, donc il n’y a ni SYN ni accusé de réception qui permettrait à un scanner de distinguer un port ouvert d’un port filtré. Une sonde arrive comme un datagramme isolé, et le service vérifie si elle correspond au protocole qu’il attend. Si ce n’est pas le cas, le paquet est écarté, et l’écartement est le comportement documenté, non un dysfonctionnement.

WireGuard valide cryptographiquement ses messages de handshake et ignore tout ce qui échoue. OpenVPN avec tls-auth ou tls-crypt fait de même pour son canal de contrôle. Dans les deux cas, une charge utile arbitraire n’atteint jamais une étape orientée utilisateur, donc il n’y a rien pour répondre et aucune erreur à renvoyer.

TCP vous aurait donné un reset depuis un port fermé. UDP vous laisse dans l’ambiguïté, que les scanners résolvent en affichant ouvert ou filtré au lieu de deviner.

Ce qu’un scanner peut et ne peut pas conclure

Le résultat d’un scan n’est aussi informatif que la charge utile qu’il a envoyée. Classez les observations possibles selon ce que chacune étaye réellement :

Lisez la troisième ligne comme le seul test positif de la liste. Il exige le vrai profil, la vraie clé et le bon point de terminaison, ce qui est exactement ce qu’un scanner générique n’a pas.

Regardez les deux extrémités du chemin

Pour un serveur que vous administrez, capturez sur l’interface avant de tirer une quelconque conclusion, puis demandez au service ce qu’il a vu. Les deux commandes exigent root sur la passerelle :

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

Si aucun paquet n’apparaît sur l’interface, le chemin l’a écarté avant que le service ne voie quoi que ce soit, et l’arrêt suivant est le routage et le filtrage. Si des paquets arrivent mais qu’aucun handshake ne se termine, le service est joignable et l’écart se situe dans les clés, la configuration du point de terminaison ou la version du protocole. Cette comparaison répond à la question que le scanner ne pouvait pas trancher. Exécutez-la pendant qu’un vrai client tente de se connecter, pas pendant que le scanner se répète.

Changez le test, pas la protection

Le raccourci tentant est de désactiver la protection du canal de contrôle pour qu’un diagnostic obtienne une réponse. Cela échange une véritable propriété de sécurité contre un résultat de scan plus flatteur, et c’est la mauvaise direction. Utilisez plutôt un profil valide issu d’un réseau approuvé, et notez le point de terminaison et l’heure pour que la comparaison soit reproductible.

Le test le plus utile est différentiel : le même profil sur un chemin qui fonctionne et sur le chemin qui ne fonctionne pas. Si le chemin fonctionnel produit un handshake et que le chemin défaillant ne produit rien sur l’interface, vous avez localisé la rupture sans rien affaiblir.

Un paquet UDP sans réponse ne prouve donc ni que le serveur est hors ligne ni qu’il est sûr. Il prouve que cette sonde, sur ce chemin, à cet instant, n’a pas été acceptée.