NAS Synology con dous portos LAN: por que falla o handshake da VPN

O portátil informa dun fallo de handshake TLS, que soa a problema de certificado e normalmente non o é. Nun NAS con dous portos Ethernet, a causa máis habitual é un reenvío do router dirixido á dirección na que o paquete non escoita, e a mensaxe do cliente é idéntica en ambos casos. O paquete non responde no segundo porto só porque os dous cables estean conectados. Antes de que ninguén reemita un certificado, demostre que un paquete chega á fin ao NAS.

O que informa o cliente e o que ocorreu realmente

O fallo de handshake dun cliente OpenVPN é unha etiqueta xenérica. Cobre unha discrepancia de certificado, unha discrepancia de transporte, un oínte noutro porto e un reenvío que non entregou nada. Por iso a mensaxe é inútil como punto de partida e útil só como confirmación. Trátea como unha declaración de que a sesión non se estableceu, e nada máis concreto.

O porto e a dirección vinculada son os dous feitos que deciden se un paquete chega algunha vez.

Anote ambos antes de cambiar nada, porque unha solución verosímil aplicada á capa equivocada é a forma en que un problema de quince minutos se converte en toda unha tarde. Fixe a interface, a dirección que ten, o porto e o transporte. Eses catro valores son todo o camiño de entrada, e a sección seguinte explica onde vive cada un.

Atope a dirección na que escoita o paquete

DSM numera os portos Ethernet e cada un leva a súa propia dirección. A páxina VPN Server indica a interface que usa o servizo OpenVPN, e o panel de rede mostra a dirección configurada nesa interface. Léaos nesa orde, do servizo cara a fóra, para describir o que escoita en lugar do que supón que debería usar.

O servizo vincula unha dirección. Que ambos portos estean conectados e activos non fai que o servizo responda no segundo. Unha dirección estática nunha interface xunto a unha dirección DHCP na outra dálle dous valores parecidos que se intercambian con facilidade de vistazo, sobre todo cando só difiren no último octeto. Copie a dirección do panel en lugar de escribila de memoria. Logo confirme no NAS que está realmente vinculado ao porto.

sudo ss -lunp | grep 1194

Se esa saída nomea unha dirección que non esperaba, o reenvío apunta á interface equivocada e todo o demais aquí é contabilidade. Corrixa a regra antes de seguir lendo, ou acabará depurando un certificado por un paquete que nunca saíu do router.

Repare o reenvío e logo vixíe o contador

Edite a regra de reenvío existente en lugar de engadir unha segunda para o mesmo porto externo. Dúas regras poden convivir na táboa dun router e só unha gaña sempre, o que converte unha sesión de depuración nunha discusión sobre cal é a real. Apunte a dirección interna ao valor que leu do NAS e deixe o porto interno coincidindo co que escoita o servizo.

Se DSM obtén esa dirección por DHCP, cree primeiro unha reserva. Un cambio de concesión rompe en silencio un reenvío que funcionaba onte.

sudo tcpdump -i any -n udp port 1194

Comece a captura antes de que o cliente tente conectarse e lea a dirección de orixe no que apareza. Nada en absoluto significa que algo polo camiño o descartou: o reenvío, a devasa de DSM ou a interface á que apuntaba, e os certificados non poden ser a causa mentres iso se manteña. Algo que chega desde a dirección pública do cliente sen resposta significa que o NAS recibiu a petición e escolleu non responder. Son achados distintos, e só o segundo o devolve á configuración do propio paquete.

Só entón mire os certificados e o transporte

Unha vez cheguen paquetes, volva exportar o perfil tras calquera cambio de certificado, porque o ficheiro vello aínda leva a autoridade coa que se creou. Un perfil editado a man para usar outro transporte deixa o cliente agardando un oínte que non existe, e informa do mesmo fallo xenérico que todo o demais. Compare o transporte dentro do perfil co transporte que o paquete está configurado para servir. Dous perfís para dous transportes é un deseño lexítimo, e un perfil editado para ambos non o é.

Probe desde fóra da súa propia rede como último paso, xa que unha conexión desde dentro da LAN pode ter éxito por un camiño que nunca toca o reenvío.

Garde o perfil exportado, a dirección da interface e a regra de reenvío xuntos nunha nota. Cando unha dirección cambia, esa nota é a diferenza entre unha reparación e unha repetición. Nada neste camiño exixiu reinstalar un paquete, o que convén lembrar antes de culpar ao seguinte reinicio.