¿Falla el handshake de OpenVPN en el Synology? Revise el reenvío de LAN

Su portátil informa de que el handshake TLS ha fallado, así que la tentación es reconstruir los certificados. Antes, haga una pregunta más aburrida: ¿en qué puerto Ethernet escucha realmente el Synology? Un NAS con dos puertos LAN tiene dos direcciones, y el paquete VPN Server de DSM ata su escucha OpenVPN a una de ellas. Cuando el router reenvía el 1194 a la otra dirección, ningún paquete llega jamás al servicio, y el cliente no tiene con qué negociar.

El texto del error engaña porque describe lo último que probó el cliente, no lo primero que salió mal. Dos minutos comparando la página del paquete con la regla del router lo resuelven.

Encuentre la dirección a la que está atada la escucha

DSM etiqueta sus puertos como LAN 1 y LAN 2, y cada uno lleva una dirección y una subred separadas. Abra VPN Server, lea la interfaz indicada en la pestaña OpenVPN, después abra el Panel de control y anote la dirección IPv4 que DSM tiene en esa misma interfaz. Esos dos valores, no el nombre de host del NAS, son los que debe nombrar el reenvío.

Un segundo cable conectado no crea una segunda escucha. Ambos enlaces pueden aparecer conectados mientras solo una dirección acepta el tráfico, y cuando las dos interfaces están en la misma subred las direcciones difieren en un dígito que nadie vuelve a leer antes de guardar una regla.

Mire el propio socket por SSH, porque es el único sitio que muestra a qué se ató realmente el demonio, y no lo que pretende la página de ajustes.

sudo netstat -anp | grep 1194

Edite el reenvío existente en lugar de añadir otro

Dos reglas para un solo puerto externo dejan al router libre de elegir, y la que elija puede cambiar tras una actualización de firmware o un reinicio. Abra la regla que ya existe, cambie su dirección interna, guarde, luego vuelva a abrirla y lea el valor. Poner el nombre del servicio a la regla ayuda, porque una lista de cinco reenvíos idénticos es como sobrevive el equivocado.

external 1194/udp  ->  192.0.2.20:1194/udp

Mantenga el puerto interno igual al puerto de escucha, y mantenga el protocolo coherente. UDP 1194 es la escucha por defecto, mientras que un perfil TCP necesita su propia escucha en el lado del paquete y un reenvío correspondiente en el router. Reenviar TCP a un servicio que solo escucha UDP produce silencio, no un error.

Si la dirección del NAS viene de DHCP, resérvela antes de que se guarde la regla. El vencimiento de la concesión reasigna la dirección, el reenvío sigue apuntando al valor antiguo, y el handshake empieza a fallar un día en que nadie tocó el NAS. Una configuración estática en el lado del NAS resuelve el mismo problema, siempre que la dirección quede fuera del rango DHCP del router.

Demuestre si los paquetes llegan siquiera

Inicie primero una captura en el NAS, luego conéctese desde el cliente, y lea la dirección de origen en la salida. Una captura iniciada después del fallo no muestra nada y no demuestra nada.

sudo tcpdump -i any -n udp port 1194

El silencio significa que el tráfico murió antes del servicio: una dirección interna equivocada, un puerto cerrado en el cortafuegos de DSM o una interfaz administrativamente caída. Los paquetes en la salida significan que el reenvío funciona, y el fallo restante vive por encima de la capa de red, que es un área de búsqueda mucho más pequeña.

La captura también nombra la interfaz por la que llegó el paquete, y ese único detalle separa una regla dirigida al puerto equivocado de una regla dirigida a un puerto que no está arriba. Vigile el contador propio del router durante el mismo intento si lo expone. Un contador que no se mueve mientras la captura sigue vacía apunta al router, mientras que un contador que se mueve con una captura vacía apunta al camino entre los dos dispositivos.

Cuando lleguen paquetes, deje de culpar al reenvío

El perfil es el siguiente sospechoso, y la razón habitual es la edad. Un archivo .ovpn exportado contiene la autoridad y el material del momento de la exportación, así que un paquete cuyo certificado se sustituyó después rechazará a un cliente que aún lleva la copia antigua.

El transporte es la otra discrepancia que vale la pena comprobar explícitamente, porque el perfil y el paquete se editan en lugares distintos. Cambiar un perfil de UDP a TCP sin cambiar el paquete deja al cliente esperando una escucha que no existe, y el cliente informa del mismo texto genérico de handshake que informa para todo lo demás. Lea la línea proto del archivo, después mire el protocolo seleccionado en la página del servidor, y solo entonces concluya que coinciden. Leer las reglas del cortafuegos de DSM es la tercera comprobación: una regla que permite el puerto desde la subred local pero no desde internet es fácil de dejar atrás tras las pruebas, y produce una conexión que funciona desde la cocina y falla desde cualquier otro sitio.

Pruebe el camino que un usuario remoto recorre de verdad

Un cliente dentro de la misma LAN puede llegar al NAS sin tocar nunca el reenvío, así que no demuestra nada sobre el acceso remoto. Use un teléfono con el Wi-Fi desactivado, o pregunte a alguien fuera de la red, y vigile el contador del router durante ese intento. Si el intento remoto falla mientras el local funciona, el reenvío o el cortafuegos siguen en la foto.

Anote el estado que funciona mientras funciona: puerto externo, dirección interna, protocolo, interfaz del paquete, y el nombre del perfil y la fecha de exportación. Cuando el handshake vuelva a fallar, la diferencia entre esa nota y la configuración actual es el fallo, y nadie tiene que volver a descubrir cuál de los dos puertos usa el servicio.