NAS Synology con dos puertos LAN: por qué falla el establecimiento de la conexión VPN

El portátil informa de un fallo de handshake TLS, que suena a problema de certificado y normalmente no lo es. En un NAS con dos puertos Ethernet, la causa más habitual es un reenvío del router dirigido a la dirección en la que el paquete no escucha, y el mensaje del cliente es idéntico en ambos casos. El paquete no responde en el segundo puerto solo porque ambos cables estén conectados. Antes de que nadie reemita un certificado, demuestre que un paquete llega siquiera al NAS.

Lo que informa el cliente y lo que ocurrió realmente

El fallo de handshake de un cliente OpenVPN es una etiqueta genérica. Cubre una discrepancia de certificado, una discrepancia de transporte, un oyente en otro puerto y un reenvío que no entregó nada. Por eso el mensaje es inútil como punto de partida y útil solo como confirmación. Trátelo como una declaración de que la sesión no se estableció, y nada más concreto.

El puerto y la dirección vinculada son los dos hechos que deciden si un paquete llega alguna vez.

Anote ambos antes de cambiar nada, porque una solución verosímil aplicada a la capa equivocada es la forma en que un problema de quince minutos se convierte en toda una tarde. Fíjese en la interfaz, la dirección que tiene, el puerto y el transporte. Esos cuatro valores son todo el camino de entrada, y la sección siguiente explica dónde vive cada uno.

Encuentre la dirección en la que escucha el paquete

DSM numera los puertos Ethernet y cada uno lleva su propia dirección. La página VPN Server indica la interfaz que usa el servicio OpenVPN, y el panel de red muestra la dirección configurada en esa interfaz. Léalos en ese orden, del servicio hacia fuera, para describir lo que escucha en lugar de lo que supone que debería usar.

El servicio vincula una dirección. Que ambos puertos estén conectados y activos no hace que el servicio responda en el segundo. Una dirección estática en una interfaz junto a una dirección DHCP en la otra le da dos valores parecidos que se intercambian con facilidad de un vistazo, sobre todo cuando solo difieren en el último octeto. Copie la dirección del panel en lugar de escribirla de memoria. Luego confirme en el NAS qué está realmente vinculado al puerto.

sudo ss -lunp | grep 1194

Si esa salida nombra una dirección que no esperaba, el reenvío apunta a la interfaz equivocada y todo lo demás aquí es contabilidad. Corrija la regla antes de seguir leyendo, o acabará depurando un certificado por un paquete que nunca salió del router.

Repare el reenvío y luego vigile el contador

Edite la regla de reenvío existente en lugar de añadir una segunda para el mismo puerto externo. Dos reglas pueden coexistir en la tabla de un router y solo una gana siempre, lo que convierte una sesión de depuración en una discusión sobre cuál es la real. Apunte la dirección interna al valor que leyó del NAS y deje el puerto interno coincidiendo con lo que escucha el servicio.

Si DSM obtiene esa dirección por DHCP, cree primero una reserva. Un cambio de concesión rompe en silencio un reenvío que funcionaba ayer.

sudo tcpdump -i any -n udp port 1194

Empiece la captura antes de que el cliente intente conectarse y lea la dirección de origen en lo que aparezca. Nada en absoluto significa que algo por el camino lo descartó: el reenvío, el cortafuegos de DSM o la interfaz a la que apuntaba, y los certificados no pueden ser la causa mientras eso se mantenga. Algo que llega desde la dirección pública del cliente sin respuesta significa que el NAS recibió la petición y eligió no responder. Son hallazgos distintos, y solo el segundo le devuelve a la configuración del propio paquete.

Solo entonces mire los certificados y el transporte

Una vez lleguen paquetes, vuelva a exportar el perfil tras cualquier cambio de certificado, porque el archivo antiguo aún lleva la autoridad con la que se creó. Un perfil editado a mano para usar otro transporte deja al cliente esperando a un oyente que no existe, y informa del mismo fallo genérico que todo lo demás. Compare el transporte dentro del perfil con el transporte que el paquete está configurado para servir. Dos perfiles para dos transportes es un diseño legítimo, y un perfil editado para ambos no lo es.

Pruebe desde fuera de su propia red como último paso, ya que una conexión desde dentro de la LAN puede tener éxito por un camino que nunca toca el reenvío.

Guarde el perfil exportado, la dirección de la interfaz y la regla de reenvío juntos en una nota. Cuando una dirección cambia, esa nota es la diferencia entre una reparación y una repetición. Nada en este camino exigió reinstalar un paquete, lo que conviene recordar antes de culpar al siguiente reinicio.