¿VPN por UDP en silencio en un escaneo de puertos? Por qué ocurre
WireGuard y OpenVPN endurecido descartan los datagramas que no superan la autenticación sin responder. El silencio de un escáner es el comportamiento esperado, no un puerto cerrado.
Escaneas el puerto del VPN, no recibes respuesta y concluyes que el servicio está caído o que el cortafuegos está cerrado. Con WireGuard, y con los canales de control de OpenVPN que llevan su propia autenticación, esa conclusión no se sigue. Un datagrama sin material de autenticación válido se descarta sin respuesta, así que el silencio es el aspecto que tiene un servicio sano desde fuera. La sonda está mal antes de que lo esté el túnel.
El silencio es el protocolo, no una avería
UDP no tiene establecimiento de conexión, así que no hay SYN ni acuse de recibo que permita a un escáner distinguir un puerto abierto de uno filtrado. La sonda llega como un datagrama aislado y el servicio comprueba si coincide con el protocolo que espera. Cuando no coincide, el paquete se descarta, y descartar es el comportamiento documentado y no un fallo.
WireGuard valida criptográficamente sus mensajes de handshake e ignora todo lo que falla. OpenVPN con tls-auth o tls-crypt hace lo mismo con su canal de control. En ambos casos una carga arbitraria nunca llega a una etapa orientada al usuario, así que no hay nada con lo que responder ni error que devolver.
TCP te habría dado un reset desde un puerto cerrado. UDP te deja en la ambigüedad, que los escáneres resuelven imprimiendo abierto o filtrado en lugar de adivinar.
Qué puede y qué no puede concluir un escáner
El resultado de un escaneo es tan informativo como la carga que envió. Ordena las observaciones posibles según lo que cada una respalda realmente:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
Lee la tercera fila como la única prueba positiva de la lista. Requiere el perfil real, la clave real y el punto final correcto, que es exactamente lo que un escáner genérico no tiene.
Mira los dos extremos del camino
Para un servidor que administras, captura en la interfaz antes de sacar cualquier conclusión y luego pregunta al servicio qué vio. Ambos comandos necesitan root en la puerta de enlace:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showSi no aparece ningún paquete en la interfaz, el camino lo descartó antes de que el servicio viera nada, y la siguiente parada es el enrutamiento y el filtrado. Si llegan paquetes pero no se completa ningún handshake, el servicio es accesible y la discrepancia está en las claves, la configuración del punto final o la versión del protocolo. Esa comparación responde la pregunta que el escáner no podía. Ejecútala mientras un cliente real intenta conectarse, no mientras el escáner se repite.
Cambia la prueba, no la protección
El atajo tentador es desactivar la protección del canal de control para que un diagnóstico reciba respuesta. Eso cambia una propiedad de seguridad real por un resultado de escaneo más bonito, y es la dirección equivocada. Usa en su lugar un perfil válido de una red aprobada y anota el punto final y la hora para que la comparación sea repetible.
La prueba más útil es una diferencial: el mismo perfil en un camino que funciona y en el camino que no. Si el camino que funciona produce un handshake y el camino que falla no produce nada en la interfaz, has localizado la rotura sin debilitar nada.
Un paquete UDP sin respuesta, por tanto, no demuestra ni que el servidor esté desconectado ni que sea seguro. Demuestra que esta sonda, en este camino, en este momento, no fue aceptada.