L'handshake di OpenVPN sul Synology fallisce? Controllate l'inoltro LAN

Il portatile segnala che l’handshake TLS è fallito, quindi la tentazione è ricostruire i certificati. Prima, fate una domanda più noiosa: su quale porta Ethernet ascolta davvero il Synology? Un NAS con due porte LAN ha due indirizzi, e il pacchetto VPN Server di DSM lega il suo ascoltatore OpenVPN a uno di essi. Quando il router inoltra 1194 all’altro indirizzo, nessun pacchetto raggiunge mai il servizio, e il client non ha nulla con cui negoziare.

Il testo dell’errore inganna perché descrive l’ultima cosa che il client ha tentato, non la prima che è andata storta. Due minuti a confrontare la pagina del pacchetto con la regola del router lo risolvono.

Trovate l’indirizzo a cui è legato l’ascoltatore

DSM etichetta le sue porte come LAN 1 e LAN 2, e ciascuna porta un indirizzo e una sottorete separati. Aprite VPN Server, leggete l’interfaccia indicata nella scheda OpenVPN, poi aprite Pannello di controllo e annotate l’indirizzo IPv4 che DSM ha su quella stessa interfaccia. Sono quei due valori, non il nome host del NAS, che l’inoltro deve nominare.

Un secondo cavo collegato non crea un secondo ascoltatore. Entrambi i collegamenti possono apparire connessi mentre solo un indirizzo accetta il traffico, e quando le due interfacce stanno nella stessa sottorete i due indirizzi differiscono di una cifra che nessuno rilegge prima di salvare una regola.

Guardate il socket stesso via SSH, perché è l’unico posto che mostra a cosa il demone si è davvero legato, invece di ciò che la pagina delle impostazioni intende.

sudo netstat -anp | grep 1194

Modificate l’inoltro esistente invece di aggiungerne un altro

Due regole per una sola porta esterna lasciano il router libero di scegliere, e quella che sceglie può cambiare dopo un aggiornamento del firmware o un riavvio. Aprite la regola che esiste già, cambiate il suo indirizzo interno, salvate, poi riapritela e rileggete il valore. Dare alla regola il nome del servizio aiuta, perché un elenco di cinque inoltri identici è il modo in cui sopravvive quello sbagliato.

external 1194/udp  ->  192.0.2.20:1194/udp

Mantenete la porta interna uguale alla porta di ascolto, e mantenete il protocollo coerente. UDP 1194 è l’ascoltatore predefinito, mentre un profilo TCP ha bisogno del proprio ascoltatore lato pacchetto e di un inoltro corrispondente sul router. Inoltrare TCP a un servizio che ascolta solo UDP produce silenzio, non un errore.

Se l’indirizzo del NAS arriva dal DHCP, prenotatelo prima che la regola venga salvata. La scadenza del lease riassegna l’indirizzo, l’inoltro continua a puntare al vecchio valore, e l’handshake inizia a fallire in un giorno in cui nessuno ha toccato il NAS. Una configurazione statica lato NAS risolve lo stesso problema, purché l’indirizzo stia fuori dall’intervallo DHCP del router.

Dimostrate se i pacchetti arrivano

Avviate prima una cattura sul NAS, poi collegatevi dal client, e leggete l’indirizzo di origine nell’output. Una cattura avviata dopo il guasto non mostra nulla e non dimostra nulla.

sudo tcpdump -i any -n udp port 1194

Il silenzio significa che il traffico è morto prima del servizio: un indirizzo interno errato, una porta chiusa sul firewall di DSM, o un’interfaccia amministrativamente spenta. I pacchetti nell’output significano che l’inoltro funziona, e il guasto rimanente vive sopra il livello di rete, che è un’area di ricerca molto più piccola.

La cattura nomina anche l’interfaccia su cui è arrivato il pacchetto, e quel singolo dettaglio separa una regola rivolta alla porta sbagliata da una regola rivolta a una porta che non è attiva. Osservate il contatore del router durante lo stesso tentativo se lo espone. Un contatore che non si muove mentre la cattura resta vuota indica il router, mentre un contatore che si muove con una cattura vuota indica il percorso tra i due dispositivi.

Quando i pacchetti arrivano, smettete di incolpare l’inoltro

Il profilo è il sospettato successivo, e la ragione abituale è l’età. Un file .ovpn esportato contiene l’autorità e il materiale del momento dell’esportazione, quindi un pacchetto il cui certificato è stato sostituito dopo rifiuterà un client che porta ancora la vecchia copia.

Il trasporto è l’altra discrepanza che vale la pena controllare esplicitamente, perché il profilo e il pacchetto si modificano in luoghi diversi. Cambiare un profilo da UDP a TCP senza cambiare il pacchetto lascia il client in attesa di un ascoltatore che non esiste, e il client riporta lo stesso testo generico di handshake che riporta per tutto il resto. Leggete la riga proto nel file, poi guardate il protocollo scelto nella pagina del server, e solo allora concludete che coincidono. Leggere le regole del firewall di DSM è il terzo controllo: una regola che consente la porta dalla sottorete locale ma non da internet è facile da lasciare indietro dopo i test, e produce una connessione che funziona dalla cucina e fallisce da ogni altro luogo.

Provate il percorso che un utente remoto compie davvero

Un client dentro la stessa LAN può raggiungere il NAS senza toccare mai l’inoltro, quindi non dimostra nulla sull’accesso remoto. Usate un telefono con il Wi-Fi disattivato, o chiedete a qualcuno fuori dalla rete, e osservate il contatore del router durante quel tentativo. Se il tentativo remoto fallisce mentre quello locale riesce, l’inoltro o il firewall sono ancora in scena.

Annotate lo stato che funziona finché funziona: porta esterna, indirizzo interno, protocollo, interfaccia del pacchetto, e il nome del profilo e la data di esportazione. Quando l’handshake fallirà di nuovo, la differenza tra quella nota e la configurazione attuale è il guasto, e nessuno deve riscoprire quale delle due porte il servizio usa.