Fallou o handshake de OpenVPN no Synology? Revise o reenvío de LAN

O seu portátil informa de que o handshake TLS fallou, así que a tentación é reconstruír os certificados. Antes, faga unha pregunta máis aburrida: en que porto Ethernet escoita realmente o Synology? Un NAS con dous portos LAN ten dúas direccións, e o paquete VPN Server de DSM ata o seu escoitador OpenVPN a unha delas. Cando o router reenvía o 1194 á outra dirección, ningún paquete chega xamais ao servizo, e o cliente non ten con que negociar.

O texto do erro engana porque describe o último que probou o cliente, non o primeiro que saíu mal. Dous minutos comparando a páxina do paquete coa regra do router resolverano.

Atope a dirección á que está atado o escoitador

DSM etiqueta os seus portos como LAN 1 e LAN 2, e cada un leva unha dirección e unha subrede separadas. Abra VPN Server, lea a interface indicada na pestana OpenVPN, despois abra o Panel de control e anote a dirección IPv4 que DSM ten nesa mesma interface. Esas dúas valores, non o nome de host do NAS, son os que debe nomear o reenvío.

Un segundo cable conectado non crea un segundo escoitador. As dúas ligazóns poden aparecer conectadas mentres só unha dirección acepta o tráfico, e cando as dúas interfaces están na mesma subrede as direccións difiren nun díxito que ninguén volve ler antes de gardar unha regra.

Mire o propio socket por SSH, porque é o único sitio que mostra a que se atou realmente o daemon, e non o que pretende a páxina de axustes.

sudo netstat -anp | grep 1194

Edite o reenvío existente en lugar de engadir outro

Dúas regras para un só porto externo deixan o router libre de escoller, e a que escolla pode cambiar tras unha actualización de firmware ou un reinicio. Abra a regra que xa existe, cambie a súa dirección interna, garde, logo volva abrila e lea o valor. Poñer o nome do servizo á regra axuda, porque unha lista de cinco reenvíos idénticos é como sobrevive o equivocado.

external 1194/udp  ->  192.0.2.20:1194/udp

Manteña o porto interno igual ao porto de escoita, e manteña o protocolo coherente. UDP 1194 é o escoitador por defecto, mentres que un perfil TCP necesita o seu propio escoitador no lado do paquete e un reenvío correspondente no router. Reenviar TCP a un servizo que só escoita UDP produce silencio, non un erro.

Se a dirección do NAS vén de DHCP, resérvea antes de que se garde a regra. O vencemento da concesión reasigna a dirección, o reenvío segue apuntando ao valor antigo, e o handshake comeza a fallar un día no que ninguén tocou o NAS. Unha configuración estática no lado do NAS resolve o mesmo problema, sempre que a dirección quede fóra do rango DHCP do router.

Demostre se os paquetes chegan

Inicie primeiro unha captura no NAS, logo concéctese desde o cliente, e lea a dirección de orixe na saída. Unha captura iniciada despois do fallo non mostra nada e non demostra nada.

sudo tcpdump -i any -n udp port 1194

O silencio significa que o tráfico morreu antes do servizo: unha dirección interna incorrecta, un porto pechado no cortalumes de DSM ou unha interface administrativamente baixada. Os paquetes na saída significan que o reenvío funciona, e o fallo restante vive por riba da capa de rede, que é unha área de busca moito máis pequena.

A captura tamén nomea a interface pola que chegou o paquete, e ese único detalle separa unha regra dirixida ao porto equivocado dunha regra dirixida a un porto que non está arriba. Vixie o contador propio do router durante o mesmo intento se o expón. Un contador que non se move mentres a captura segue baleira apunta ao router, mentres que un contador que se move cunha captura baleira apunta ao camiño entre os dous dispositivos.

Cando cheguen paquetes, deixe de culpar o reenvío

O perfil é o seguinte sospeitoso, e a razón habitual é a idade. Un ficheiro .ovpn exportado contén a autoridade e o material do momento da exportación, así que un paquete cuxo certificado se substituíu despois rexeitará un cliente que aínda leva a copia antiga.

O transporte é a outra discrepancia que paga a pena comprobar explicitamente, porque o perfil e o paquete edítanse en lugares distintos. Cambiar un perfil de UDP a TCP sen cambiar o paquete deixa o cliente agardando un escoitador que non existe, e o cliente informa do mesmo texto xenérico de handshake que informa para todo o demais. Lea a liña proto do ficheiro, despois mire o protocolo seleccionado na páxina do servidor, e só entón conclúa que coinciden. Ler as regras do cortalumes de DSM é a terceira comprobación: unha regra que permite o porto desde a subrede local pero non desde internet é fácil de deixar atrás tras as probas, e produce unha conexión que funciona desde a cociña e falla desde calquera outro sitio.

Probe o camiño que un usuario remoto percorre de verdade

Un cliente dentro da mesma LAN pode chegar ao NAS sen tocar nunca o reenvío, así que non demostra nada sobre o acceso remoto. Use un teléfono co Wi-Fi desactivado, ou pregunte a alguén fóra da rede, e vixie o contador do router durante ese intento. Se o intento remoto falla mentres o local funciona, o reenvío ou o cortalumes seguen na imaxe.

Anote o estado que funciona mentres funciona: porto externo, dirección interna, protocolo, interface do paquete, e o nome do perfil e a data de exportación. Cando o handshake volva fallar, a diferenza entre esa nota e a configuración actual é o fallo, e ninguén ten que volver descubrir cal dos dous portos usa o servizo.