Timeout TLS di sessanta secondi: quale estremità si è fermata davvero?

Il client rinuncia dopo sessanta secondi con un messaggio sulla negoziazione delle chiavi, e il portatile non esprime alcuna opinione sul perché. Quella frase descrive la pazienza del client, non il comportamento del server. Tre situazioni molto diverse la producono: il pacchetto non ha mai raggiunto il servizio giusto, il servizio lo ha scartato prima di registrare qualcosa, oppure il servizio lo ha rifiutato e lo ha detto in un punto che il client non può vedere. È la correlazione di un solo tentativo alle due estremità che le separa.

Date a un tentativo un'identità che potete cercare

Annotate l'ora di inizio con il suo fuso orario, il nome del profilo, la destinazione che il client ha effettivamente risolto, la porta e se la connessione è UDP o TCP. Se il profilo contiene diverse voci remote, indicate quale ha scelto quel tentativo, perché un nuovo tentativo può essere passato alla voce successiva senza modificare il file che state leggendo.

Prendete l'endpoint dal registro attivo, non dal download che ricordate. Un profilo che punta a un indirizzo privato è perfettamente valido e del tutto inutilizzabile da una rete che non può instradare verso di esso, e quel caso appare identico a un server spento.

Poi chiedete all'operatore la stessa finestra sull'istanza prevista. La deriva dell'orologio è abbastanza comune che uno scarto di pochi minuti può far sembrare assente un evento corrispondente, quindi annotate lo scarto invece di concludere che non ci sia stato alcun evento.

Quattro osservazioni, quattro passi successivi diversi

Ciò che il server registra decide il ramo. L'assenza di qualsiasi tentativo indica indirizzamento, trasporto o il percorso verso il servizio. I pacchetti in arrivo che scompaiono prima di uno scambio ordinario indicano i requisiti del canale di controllo del servizio reale. Un rifiuto con nome indica l'oggetto che nomina. Le risposte che lasciano il server ma non raggiungono mai il client indicano il percorso di ritorno.

Un registro applicativo vuoto è una prova più debole di quanto sembri. La registrazione inizia in un certo punto dello scambio, e i pacchetti scartati prima di quel punto non lasciano traccia nel file che state leggendo. Dove è consentito, l'operatore può usare osservazioni del servizio e della rete per vedere se è arrivato qualcosa.

Tenete separati i quattro esiti nelle vostre note. La tentazione è fonderli in «il server non risponde», ed è questa frase che manda le persone a cambiare cifrari quando il problema reale è una regola del firewall. Una nota che registra solo la parola timeout ha buttato via la distinzione che avete appena pagato.

Correggete la fase che la prova nomina

Una connessione TCP che si completa prova solo che qualcosa ha accettato un socket. Non prova che l'ascoltatore sia il servizio OpenVPN che avete configurato, e un server web sullo stesso nome host risponde perfettamente a un browser mentre è irrilevante per il tunnel.

Se il server segnala una lista di revoca scaduta, è un fatto molto più specifico del timeout finale del client, e la correzione spetta all'autorità di certificazione e non alla rete. Se le due estremità non concordano sulla protezione del canale di controllo o sul materiale condiviso, reimpostare una password non cambia nulla, perché lo scarto avviene prima che venga esaminata qualsiasi credenziale.

Cambiate una cosa che la prova sostiene davvero, poi ripetete lo stesso profilo contro lo stesso endpoint. Conservate il primo nuovo evento se la connessione va oltre, perché quell'evento è la fase successiva dell'indagine, non un nuovo problema.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

Che cosa cambia davvero allungare la finestra

Sessanta secondi è la finestra di stretta di mano del client, e la referenza client della comunità documenta l'opzione che la regola. Aumentarla fa attendere il client più a lungo prima di rinunciare. Non fa apparire un servizio assente e non rende accettabile un pacchetto rifiutato.

Una finestra più lunga ha un uso legittimo su un collegamento lento o un server molto carico, e vale la pena provarla quando avete prove che lo scambio procede lentamente invece di non avvenire affatto. Provarla per prima cosa ritarda solo la stessa diagnosi di un altro minuto e rende la cronologia più difficile da leggere. Se la cronologia mostra uno scambio che avanza e poi si blocca, la finestra è un sintomo del carico e non della raggiungibilità.