¿El puerto del VPN no responde? Escucha, dirección de enlace o cortafuegos del equipo

El VPN no responde nada en su puerto, y las dos causas posibles exigen reparaciones opuestas: o ningún proceso abrió el socket, o el socket existe y algo entre las máquinas detiene los paquetes. Un solo comando resuelve la primera mitad de esa pregunta, por eso va antes de tocar cualquier regla del cortafuegos. El orden de abajo elimina una explicación por paso en lugar de añadir otra conjetura. Conjeturar entre las dos es lo que convierte un diagnóstico de diez minutos en una noche entera.

Suponga que puede iniciar sesión en el servidor y que el cliente es un perfil real y no un escáner. Ambas suposiciones importan, porque una sonda genérica no puede responder a una pregunta específica del protocolo.

¿Existe el socket siquiera?

Empiece por lo que el servicio dice de sí mismo: si arrancó y, más útil, cuál fue su primer error de arranque. Un fallo de análisis, una clave ausente o un error de enlace impiden que la escucha exista siquiera, y el proceso puede salir con la suficiente discreción como para que la línea de estado se lea de forma ambigua. Una unidad que informa estar activa no es prueba por sí sola, porque el proceso principal puede estar vivo mientras el componente que debía enlazar el puerto ya se rindió.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

El listado de sockets es el hecho sobre el que descansa el resto del diagnóstico. Lea la columna de dirección local y no solo el puerto, porque es en esa columna donde aparecen los enlaces a loopback y los enlaces a la interfaz equivocada. Una escucha que existe en 127.0.0.1 funciona perfectamente y sigue siendo invisible para su portátil.

En qué dirección y familia responde el socket

Dos errores se ven idénticos desde el cliente y explican la mayoría de los informes de "no accesible". Un servidor enlazado a la dirección de loopback nunca acepta tráfico de otra máquina, y un servidor enlazado solo a una dirección IPv4 nunca responde a un cliente que marca la dirección IPv6 del mismo equipo. Compare la dirección de la tabla de sockets con la dirección que el cliente marca realmente, carácter por carácter, antes de suponer nada sobre la política.

Limitar el listado a un solo puerto lo mantiene legible cuando el equipo ejecuta varios servicios. El filtro sport toma el puerto junto con el transporte que está probando:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

La columna de protocolo cambia toda la respuesta

La tabla de sockets indexa por protocolo además de por puerto, y son dos entradas independientes. Un servicio que responde TCP en 1194 no le dice nada sobre si algo escucha en UDP 1194, y el cliente siempre usará solo uno de los dos. Confirme qué transporte elige la configuración del servidor y cuál envía el perfil del cliente, y luego busque exactamente esa fila.

UDP tiene una segunda particularidad: una sonda no autenticada no es un error que el servicio deba responder. Un escaneo que informa que el puerto está mudo ha medido la discreción del servicio, no su disponibilidad, así que pruebe con el cliente y el perfil reales.

Un intento, tres sitios donde mirar

Desde un cliente aprobado haga exactamente un intento y anote la hora al segundo. Luego lea tres fuentes para esa ventana: la regla de red o la consola del proveedor, los contadores o el registro del cortafuegos del equipo y el registro propio del servicio. Hacerlo una vez es lo que vuelve comparables los tres relatos, y cuesta menos que repetir un intento cuya marca de tiempo nadie registró.

Los dos desenlaces apuntan en direcciones opuestas. Si ningún paquete llegó al equipo, la ruta lo está descartando y la escucha es irrelevante. Si el paquete llegó al socket y el servicio lo rechazó, la ruta está bien y la respuesta está en el protocolo, la criptografía o las credenciales. Abrir un puerto para un servicio que ya aceptó una conexión hace más difícil el siguiente diagnóstico, no más fácil.

Nombre la etapa antes de cambiar una regla

Una negociación que empieza y una autenticación que falla son un solo fallo, y un túnel que se establece mientras el reenvío se atasca es uno completamente distinto. Nombrar la etapa primero mantiene la reparación estrecha: un problema de credenciales no lo arregla una regla de cortafuegos, y un problema de ruta de datos no lo arregla un reinicio.

Use el diagnóstico más estrecho que responda la pregunta. Una observación temporal de paquetes en un puerto, bajo el control de un administrador, es un instrumento razonable; desactivar todo el cortafuegos no lo es, porque el resultado se vuelve imposible de atribuir. La documentación de ss cubre los filtros usados arriba, y es un primer paso más barato que cualquier captura. Anote cuál de las dos ramas demostró, y la próxima ocurrencia empieza con una respuesta conocida.