VPN por UDP en silencio nunha exploración de portos? Por que ocorre
WireGuard e OpenVPN endurecido descartan os datagramas que non superan a autenticación sen responder. O silencio dun escáner é o comportamento esperado, non un porto pechado.
Exploras o porto do VPN, non recibe resposta e conclúe que o servizo está caído ou que a devasa está pechada. Con WireGuard, e cos canais de control de OpenVPN que levan a súa propia autenticación, esa conclusión non se segue. Un datagrama sen material de autenticación válido descártase sen resposta, así que o silencio é o aspecto que ten un servizo san desde fóra. A sonda está mal antes de que o estea o túnel.
O silencio é o protocolo, non unha avaría
UDP non ten establecemento de conexión, así que non hai SYN nin acuse de recibo que permita a un escáner distinguir un porto aberto dun filtrado. A sonda chega como un datagrama illado e o servizo comproba se coincide co protocolo que espera. Cando non coincide, o paquete descártase, e descartar é o comportamento documentado e non un fallo.
WireGuard valida criptograficamente as súas mensaxes de handshake e ignora todo o que falla. OpenVPN con tls-auth ou tls-crypt fai o mesmo co seu canal de control. En ambos os casos unha carga arbitraria nunca chega a unha etapa orientada ao usuario, así que non hai nada con que responder nin erro que devolver.
TCP teríache dado un reset dun porto pechado. UDP déixache na ambigüidade, que os escáneres resolven imprimindo aberto ou filtrado en lugar de adiviñar.
Que pode e que non pode concluír un escáner
O resultado dunha exploración é tan informativo como a carga que enviou. Ordena as observacións posibles segundo o que cada unha 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 |
Le a terceira fila como a única proba positiva da lista. Require o perfil real, a clave real e o punto final correcto, que é exactamente o que un escáner xenérico non ten.
Mira os dous extremos do camiño
Para un servidor que administras, captura na interface antes de sacar calquera conclusión e despois pregunta ao servizo que viu. Ambos os comandos necesitan root na pasarela:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showSe non aparece ningún paquete na interface, o camiño descartouno antes de que o servizo vise nada, e a seguinte parada é o encamiñamento e o filtrado. Se chegan paquetes pero non se completa ningún handshake, o servizo é accesible e a discrepancia está nas claves, na configuración do punto final ou na versión do protocolo. Esa comparación responde a pregunta que o escáner non podía. Execútaa mentres un cliente real tenta conectarse, non mentres o escáner se repite.
Cambia a proba, non a protección
O atallo tentador é desactivar a protección do canal de control para que un diagnóstico reciba resposta. Iso cambia unha propiedade de seguridade real por un resultado de exploración máis bonito, e é a dirección equivocada. Usa no seu lugar un perfil válido dunha rede aprobada e anota o punto final e a hora para que a comparación sexa repetible.
A proba máis útil é unha diferencial: o mesmo perfil nun camiño que funciona e no camiño que non. Se o camiño que funciona produce un handshake e o camiño que falla non produce nada na interface, localizaches a rotura sen debilitar nada.
Un paquete UDP sen resposta, por tanto, non demostra nin que o servidor estea desconectado nin que sexa seguro. Demostra que esta sonda, neste camiño, neste momento, non foi aceptada.