Le scan UDP affiche filtré : votre pair WireGuard est-il vraiment hors service ?

Les scanners affichent ouvert ou filtré pour un port UDP, et la conclusion suit généralement en quelques secondes : le tunnel est cassé. Il peut l’être, mais le scan ne l’a pas établi. UDP ne transporte aucune poignée de main de connexion, et WireGuard ne répond à rien qu’il ne puisse authentifier, donc le silence est la réponse attendue à la plupart des sondes.

Travaillez plutôt du client vers l’extérieur, et traitez le scan comme un point de donnée faible parmi d’autres.

Ce que le scanner peut voir et ce qu’il ne peut pas

Un scanner UDP envoie une charge utile et attend. Si un ICMP port-unreachable revient, il peut signaler le port comme fermé. Si rien ne revient, le résultat est ambigu par conception : un chemin filtré, un hôte absent et un service en cours qui a ignoré la charge utile produisent tous le même silence. Trois états différents, une seule chaîne de sortie.

WireGuard aggrave volontairement cette ambiguïté. Le protocole n’accepte un paquet que lorsqu’il s’authentifie, donc une sonde avec les mauvaises clés est rejetée sans réponse. Il n’y a ni bannière, ni chaîne de version, ni message d’erreur à empreindre.

Un test TCP sur le même numéro de port ne teste rien de lié. Il sollicite un autre écouteur qui n’existe peut-être pas, et son refus ne dit rien sur UDP.

Les états ouverts filtrés décrivent donc l’incertitude du scanner plus précisément que votre serveur.

Parcourez le vrai client du profil vers l’intérieur

Commencez par la vue du client lui-même. L’interface porte-t-elle une adresse, la configuration nomme-t-elle le bon point de terminaison, et le compteur de handshakes bouge-t-il lorsqu’une connexion est tentée ? Un client qui n’a jamais envoyé de paquet et un client dont les paquets ont été rejetés se ressemblent à l’identique dans une fenêtre d’état. Seuls les compteurs les distinguent, alors lisez d’abord les compteurs.

Observez ensuite le côté serveur pendant une tentative autorisée, plutôt que de lancer un scan séparé depuis un troisième emplacement :

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

La première commande indique le dernier handshake par pair, ce qui est une preuve directe qu’un échange authentifié s’est terminé. La seconde montre si les paquets destinés à l’écouteur arrivent du tout, ce qui sépare un problème de chemin d’un problème de configuration en une seule étape.

Si la capture ne montre rien, le paquet n’a jamais atteint l’hôte et la configuration du tunnel n’est pas suspecte. Si elle montre des paquets arrivant de l’adresse attendue alors que le handshake reste à zéro, les clés ou les adresses autorisées du pair sont le prochain endroit à regarder.

Corrélez sur le serveur lorsque vous l’administrez

Confirmez que l’écouteur existe et que le pare-feu du fournisseur autorise le port UDP. Une règle de pare-feu d’hôte et un groupe de sécurité cloud sont deux portes indépendantes, et l’une comme l’autre peut rejeter un paquet que l’autre a autorisé. Vérifiez les deux contre le port réel de la configuration plutôt que contre le port dont vous vous souvenez.

L’adresse compte autant que le port. Un serveur qui écoute sur une adresse précise ne répondra pas à un paquet qui arrive sur une autre, et un hôte multiréseau peut recevoir la sonde sur l’interface que vous ne vouliez pas.

Gardez chaque test à l’intérieur de systèmes que vous êtes autorisé à tester. La comparaison utile est entre une vraie tentative du client et le chemin attendu du serveur, pas un balayage plus large d’adresses qui appartiennent par hasard au même fournisseur.

Lire un résultat de scan honnêtement

Un scan est un moyen peu coûteux de vérifier qu’un hôte existe et qu’un port n’est pas manifestement bloqué par un dispositif intermédiaire. Ce n’est pas une preuve d’accessibilité pour un protocole authentifié, et ce n’est certainement pas un test de configuration.

La preuve la plus solide est un handshake terminé avec le client qui vous importe réellement, suivi d’une requête qui utilise le tunnel et obtient une réponse. Cette séquence sollicite les clés, les adresses autorisées, les deux pare-feu et le chemin de retour en une seule fois.

Lorsque la vraie tentative échoue, la panne doit tout de même être diagnostiquée avec les compteurs du client et la capture du serveur plutôt qu’avec une autre sonde. La description du protocole explique pourquoi un paquet non authentifié ne reçoit aucune réponse, et c’est toute la raison pour laquelle le résultat du scan est ambigu.