NAS Synology con due porte LAN: perché la stretta di mano VPN fallisce

Il portatile segnala un errore di stretta di mano TLS, che sembra un problema di certificato e di solito non lo è. Su un NAS con due porte Ethernet, la causa più frequente è un inoltro del router diretto all'indirizzo su cui il pacchetto non è in ascolto, e il messaggio del client è identico in entrambi i casi. Il pacchetto non risponde sulla seconda porta solo perché entrambi i cavi sono collegati. Prima che qualcuno riemetta un certificato, dimostrate che un pacchetto raggiunge davvero il NAS.

Ciò che segnala il client e ciò che è realmente accaduto

L'errore di stretta di mano di un client OpenVPN è un'etichetta generica. Copre una discrepanza di certificato, una discrepanza di trasporto, un ascoltatore su un'altra porta e un inoltro che non ha consegnato nulla. Per questo il messaggio è inutile come punto di partenza e utile solo come conferma. Trattatelo come l'affermazione che la sessione non è stata stabilita, e nulla di più preciso.

La porta e l'indirizzo associato sono i due fatti che decidono se un pacchetto arriva mai.

Annotate entrambi prima di cambiare qualsiasi cosa, perché una correzione plausibile applicata al livello sbagliato è il modo in cui un problema di quindici minuti diventa un intero pomeriggio. Rilevate l'interfaccia, l'indirizzo su di essa, la porta e il trasporto. Quei quattro valori sono tutto il percorso in ingresso, e la sezione seguente spiega dove vive ciascuno di essi.

Trovate l'indirizzo su cui il pacchetto è in ascolto

DSM numera le porte Ethernet e ciascuna porta il proprio indirizzo. La pagina VPN Server nomina l'interfaccia usata dal servizio OpenVPN, e il pannello di rete mostra l'indirizzo configurato su quell'interfaccia. Leggeteli in quest'ordine, dal servizio verso l'esterno, per descrivere ciò che è in ascolto invece di ciò che supponete debba usare.

Il servizio associa un solo indirizzo. Il fatto che entrambe le porte siano collegate e attive non fa rispondere il servizio sulla seconda. Un indirizzo statico su un'interfaccia accanto a un indirizzo DHCP sull'altra vi dà due valori simili facili da scambiare a colpo d'occhio, soprattutto quando differiscono solo nell'ultimo ottetto. Copiate l'indirizzo dal pannello invece di digitarlo a memoria. Poi confermate sul NAS ciò che è realmente associato alla porta.

sudo ss -lunp | grep 1194

Se quell'output nomina un indirizzo che non vi aspettavate, l'inoltro punta all'interfaccia sbagliata e tutto il resto qui è contabilità. Correggete la regola prima di leggere oltre, altrimenti finirete per fare debug di un certificato a causa di un pacchetto che non ha mai lasciato il router.

Riparate l'inoltro, poi osservate il contatore

Modificate la regola di inoltro esistente invece di aggiungerne una seconda per la stessa porta esterna. Due regole possono convivere nella tabella di un router e solo una vince sempre, il che trasforma una sessione di debug in una discussione su quale sia quella reale. Puntate l'indirizzo interno al valore che avete letto dal NAS, e lasciate la porta interna corrispondente a ciò su cui il servizio è in ascolto.

Se DSM ottiene quell'indirizzo via DHCP, create prima una prenotazione. Un cambio di lease rompe silenziosamente un inoltro che funzionava ieri.

sudo tcpdump -i any -n udp port 1194

Iniziate la cattura prima che il client tenti di connettersi, e leggete l'indirizzo di origine in qualunque cosa compaia. Niente affatto significa che qualcosa lungo il percorso l'ha scartato: l'inoltro, il firewall di DSM o l'interfaccia verso cui era diretto, e i certificati non possono essere la causa finché questo vale. Qualcosa che arriva dall'indirizzo pubblico del client senza risposta significa che il NAS ha ricevuto la richiesta e ha scelto di non rispondere. Sono riscontri diversi, e solo il secondo vi riporta nelle impostazioni del pacchetto stesso.

Solo allora guardate certificati e trasporto

Una volta arrivati i pacchetti, riesportate il profilo dopo ogni modifica del certificato, perché il vecchio file porta ancora l'autorità con cui è stato creato. Un profilo modificato a mano per un altro trasporto lascia il client in attesa di un ascoltatore che non esiste, e segnala lo stesso errore generico di tutto il resto. Confrontate il trasporto nel profilo con il trasporto che il pacchetto è impostato per servire. Due profili per due trasporti sono un progetto legittimo, e un profilo modificato per entrambi non lo è.

Provate dall'esterno della vostra rete come ultimo passo, poiché una connessione dall'interno della LAN può riuscire su un percorso che non tocca mai l'inoltro.

Tenete il profilo esportato, l'indirizzo dell'interfaccia e la regola di inoltro insieme in una nota. Quando un indirizzo cambia, quella nota è la differenza tra una riparazione e una replica. Nulla su questo percorso ha richiesto di reinstallare un pacchetto, cosa che vale la pena ricordare prima che il prossimo riavvio venga incolpato.