Fracassa l’handshake d’OpenVPN al Synology? Reviseu el reenviament de LAN

El portàtil informa que l’handshake TLS ha fracassat, i la temptació és reconstruir els certificats. Abans, feu una pregunta més avorrida: en quin port Ethernet escolta realment el Synology? Un NAS amb dos ports LAN té dues adreces, i el paquet VPN Server del DSM lliga el seu oient OpenVPN a una d’elles. Quan el router reenvia el 1194 a l’altra adreça, cap paquet no arriba mai al servei i el client no té res amb què negociar.

El text de l’error enganya perquè descriu l’última cosa que el client va provar, no la primera que va fallar. Dos minuts comparant la pàgina del paquet amb la regla del router ho resolen.

Trobeu l’adreça a la qual està lligat l’oient

El DSM etiqueta els seus ports com a LAN 1 i LAN 2, i cadascun porta una adreça i una subxarxa separades. Obriu VPN Server, llegiu la interfície indicada a la pestanya OpenVPN, després obriu el Tauler de control i anoteu l’adreça IPv4 que el DSM té en aquesta mateixa interfície. Aquests dos valors, no el nom d’amfitrió del NAS, són els que ha de nomenar el reenviament.

Un segon cable connectat no crea un segon oient. Tots dos enllaços poden aparèixer connectats mentre només una adreça accepta el trànsit, i quan les dues interfícies són a la mateixa subxarxa les adreces difereixen en un dígit que ningú no rellegeix abans de desar una regla.

Mireu el sòcol mateix per SSH, perquè és l’únic lloc que mostra a què s’ha lligat realment el dimoni, i no el que pretén la pàgina de configuració.

sudo netstat -anp | grep 1194

Editeu el reenviament existent en lloc d’afegir-ne un altre

Dues regles per a un sol port extern deixen el router lliure de triar, i la que triï pot canviar després d’una actualització de firmware o d’un reinici. Obriu la regla que ja existeix, canvieu-ne l’adreça interna, deseu, torneu-la a obrir i llegiu el valor. Posar el nom del servei a la regla ajuda, perquè una llista de cinc reenviaments idèntics és com sobreviu el que és incorrecte.

external 1194/udp  ->  192.0.2.20:1194/udp

Mantingueu el port intern igual al port d’escolta i mantingueu el protocol coherent. L’UDP 1194 és l’oient per defecte, mentre que un perfil TCP necessita el seu propi oient al costat del paquet i un reenviament corresponent al router. Reenviar TCP a un servei que només escolta UDP produeix silenci, no un error.

Si l’adreça del NAS ve del DHCP, reserveu-la abans que es desi la regla. El venciment de la concessió reassigna l’adreça, el reenviament continua apuntant al valor antic i l’handshake comença a fallar un dia que ningú no ha tocat el NAS. Una configuració estàtica al costat del NAS resol el mateix problema, sempre que l’adreça quedi fora del rang DHCP del router.

Demostreu si els paquets hi arriben

Primer inicieu una captura al NAS, després connecteu-vos des del client i llegiu l’adreça d’origen a la sortida. Una captura iniciada després del fracàs no mostra res i no demostra res.

sudo tcpdump -i any -n udp port 1194

El silenci vol dir que el trànsit va morir abans del servei: una adreça interna incorrecta, un port tancat al tallafoc del DSM o una interfície administrativament aturada. Els paquets a la sortida volen dir que el reenviament funciona, i la resta de la falla viu per sobre de la capa de xarxa, que és una àrea de cerca molt més petita.

La captura també anomena la interfície per la qual ha arribat el paquet, i aquest sol detall separa una regla adreçada al port equivocat d’una regla adreçada a un port que no està aixecat. Mireu el comptador propi del router durant el mateix intent, si n’exposa un. Un comptador que no es mou mentre la captura continua buida apunta al router, i un comptador que es mou amb una captura buida apunta al camí entre els dos dispositius.

Quan els paquets arribin, deixeu de culpar el reenviament

El perfil és el següent sospitós, i la raó habitual és l’edat. Un fitxer .ovpn exportat conté l’autoritat i el material del moment de l’exportació, de manera que un paquet el certificat del qual es va substituir més tard rebutjarà un client que encara porta la còpia antiga.

El transport és l’altra discrepància que val la pena comprovar explícitament, perquè el perfil i el paquet s’editen en llocs diferents. Canviar un perfil d’UDP a TCP sense canviar el paquet deixa el client esperant un oient que no existeix, i el client informa del mateix text genèric d’handshake que informa per a tota la resta. Llegiu la línia proto del fitxer, després mireu el protocol seleccionat a la pàgina del servidor i només llavors concloeu que coincideixen. Llegir les regles del tallafoc del DSM és la tercera comprovació: una regla que permet el port des de la subxarxa local però no des d’internet és fàcil de deixar enrere després de provar-ho, i produeix una connexió que funciona des de la cuina i fracassa des de qualsevol altre lloc.

Proveu el camí que un usuari remot fa de debò

Un client dins del mateix LAN pot arribar al NAS sense tocar mai el reenviament, així que no demostra res sobre l’accés remot. Feu servir un telèfon amb el Wi-Fi desactivat, o pregunteu a algú de fora de la xarxa, i mireu el comptador del router durant aquest intent. Si l’intent remot fracassa mentre el local funciona, el reenviament o el tallafoc encara hi són.

Anoteu l’estat que funciona mentre funciona: port extern, adreça interna, protocol, interfície del paquet i el nom del perfil i la data d’exportació. Quan l’handshake torni a fracassar, la diferència entre aquella nota i la configuració actual és la falla, i ningú no ha de tornar a descobrir quin dels dos ports fa servir el servei.