El escaneo UDP dice filtrado: ¿tu par de WireGuard está realmente caído?

Los escáneres imprimen abierto o filtrado para un puerto UDP, y la conclusión suele llegar en segundos: el túnel está roto. Puede que lo esté, pero el escaneo no lo demostró. UDP no lleva ningún handshake de conexión, y WireGuard no responde a nada que no pueda autenticar, así que el silencio es la respuesta esperada a la mayoría de las sondas.

Trabaja en cambio desde el cliente hacia fuera y trata el escaneo como un dato débil entre varios.

Qué puede ver el escáner y qué no

Un escáner UDP envía una carga y espera. Si vuelve un ICMP de puerto inalcanzable, puede informar el puerto como cerrado. Si no vuelve nada, el resultado es ambiguo por diseño: una ruta filtrada, un host ausente y un servicio en marcha que ignoró la carga producen el mismo silencio. Tres estados distintos, una sola cadena de salida.

WireGuard empeora esa ambigüedad a propósito. El protocolo acepta un paquete solo cuando se autentica, así que una sonda con las claves equivocadas se descarta sin respuesta. No hay banner, ni cadena de versión, ni mensaje de error que identificar.

Una prueba TCP en el mismo número de puerto no prueba nada relacionado. Ejercita otro listener que quizá no exista, y su rechazo no dice nada sobre UDP.

Los estados abiertos filtrados describen, por tanto, la incertidumbre del escáner con más precisión que tu servidor.

Recorre el cliente real desde el perfil hacia dentro

Empieza por la visión del propio cliente. ¿Tiene la interfaz una dirección, nombra la configuración el extremo correcto y se mueve el contador de handshakes cuando se intenta una conexión? Un cliente que nunca envió un paquete y un cliente cuyos paquetes se descartaron se ven idénticos en una ventana de estado. Solo los contadores los distinguen, así que lee primero los contadores.

Después observa el lado del servidor mientras ocurre un intento autorizado, en lugar de ejecutar un escaneo aparte desde un tercer lugar:

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

El primer comando informa del último handshake por par, que es evidencia directa de que se completó un intercambio autenticado. El segundo muestra si llegan paquetes para el listener, lo que separa un problema de ruta de un problema de configuración en un solo paso.

Si la captura no muestra nada, el paquete nunca llegó al host y la configuración del túnel no es la sospechosa. Si muestra paquetes que llegan desde la dirección esperada mientras el handshake sigue en cero, las claves o las direcciones permitidas del par son el siguiente lugar donde mirar.

Correlaciona en el servidor cuando lo administras

Confirma que el listener existe y que el cortafuegos del proveedor permite el puerto UDP. Una regla de cortafuegos del host y un grupo de seguridad de la nube son dos puertas independientes, y cualquiera de las dos puede descartar un paquete que la otra permitió. Comprueba ambas contra el puerto real de la configuración y no contra el puerto que recuerdas.

La dirección importa tanto como el puerto. Un servidor que escucha en una dirección concreta no responderá a un paquete que llegue a otra, y un host con varias interfaces puede recibir la sonda por la interfaz que no querías.

Mantén cada prueba dentro de sistemas que estés autorizado a probar. La comparación útil es entre un intento real del cliente y la ruta esperada del servidor, no un barrido más amplio de direcciones que casualmente pertenecen al mismo proveedor.

Leer un resultado de escaneo con honestidad

Un escaneo es una forma barata de comprobar que un host existe y que un puerto no está obviamente bloqueado por un dispositivo intermedio. No es una prueba de alcanzabilidad para un protocolo autenticado y desde luego no es una prueba de configuración.

La evidencia más sólida es un handshake completado con el cliente que de verdad te importa, seguido de una petición que use el túnel y obtenga respuesta. Esa secuencia ejercita las claves, las direcciones permitidas, ambos cortafuegos y la ruta de vuelta de una vez.

Cuando el intento real falla, el fallo todavía debe diagnosticarse con los contadores del cliente y la captura del servidor, no con otra sonda. La descripción del protocolo explica por qué un paquete no autenticado no recibe respuesta, que es la razón completa de que el resultado del escaneo sea ambiguo.