proto udp o tcp-client: quale ascolta il tuo server?

Un profilo che funzionava il mese scorso ora va in timeout e qualcuno propone di sostituire proto udp con proto tcp-client. A volte è la mossa giusta, a volte produce un client che si connette a una porta dove nulla ascolta, perché il server non è mai stato configurato per l’altro trasporto. La direttiva descrive come parla il tuo lato; non può creare un listener dall’altra parte. Leggi il profilo e il server insieme prima di cambiare l’uno o l’altro.

Leggi il trasporto usato dalla connessione selezionata

Un profilo può contenere più voci remote e ciascuna può indicare il proprio trasporto. Il client le percorre in ordine, quindi la riga che vedi per prima non è necessariamente quella che vale.

Trova la voce che viene davvero tentata, poi leggi il suo trasporto. L’ordine conta, perché il client non passa oltre in silenzio. Alcune build tentano la voce successiva solo dopo un timeout, quindi un’alternativa funzionante in fondo al file viene raggiunta qualche secondo più tardi del previsto. Controlla nel log quale endpoint viene tentato invece di dare per scontato che abbia vinto la prima riga.

Se il file ha una riga proto vicino all’inizio e diverse voci remote sotto, quella riga è il valore predefinito per ogni remote che non la sovrascrive. Una modifica locale del valore predefinito non fa nulla per una voce remote che indica il proprio trasporto.

grep -nE '^(remote|proto)\b' client.ovpn

UDP e TCP non sono un’impostazione di velocità

UDP invia datagrammi senza costruire un flusso ordinato, quindi il traffico del tunnel stesso non viene avvolto in un secondo trasporto affidabile. TCP ti offre un percorso attraverso reti che scartano o bloccano UDP, al costo di una ritrasmissione annidata che può far sembrare peggiore un collegamento con perdite.

È uno scambio di raggiungibilità, non una classifica universale. La scelta giusta è quella che la rete davanti al client consente. Un percorso che scarta UDP sulla porta VPN non negozierà mai, per quanto bene sia scritto il profilo. Prova il percorso, poi scegli il trasporto.

Scegliere tra loro solo in base a una misurazione è un errore, perché la risposta dipende da ciò che la rete davanti a te consente. Un hotel o un proxy aziendale può consentire TCP in uscita sulla 443 e nulla più, ed è per questo che i provider offrono quella variante. Resta una connessione OpenVPN su quella porta, non una sessione HTTPS, anche se il numero di porta è quello familiare.

Che cosa significa davvero tcp-client

La direttiva lato client nomina l’estremità che avvia una connessione TCP. Il lato server usa la propria forma di ascolto, e copiare la parola del client in una configurazione server produce un listener che si aspetta di essere chiamato, non uno che accetta.

Corrispondere significa che le due estremità concordano sul trasporto, non che condividono la stessa stringa.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Chiedi al server su cosa ascolta prima di supporre che il profilo sia sbagliato. Un listener UDP non compare in un elenco di socket TCP, e vale anche il contrario, quindi guarda la vista specifica del protocollo invece di una generica.

Quando il profilo viene importato ma non si connette mai

Un profilo importato che va subito in timeout di solito fallisce prima di qualsiasi autenticazione. Il pacchetto va a una porta senza listener, oppure la rete lo scarta in silenzio.

Prova il percorso nel modo più semplice possibile: connettiti allo stesso host e alla stessa porta con il trasporto che il profilo dichiara, dalla stessa rete del client che fallisce.

Se una prova UDP non ottiene nulla e una prova TCP si connette, il server offre l’altro trasporto e il profilo è semplicemente obsoleto. Se nessuna delle due risponde, il problema è a monte della scelta del trasporto e nessuna modifica al profilo lo risolverà. Distinguere questi due casi richiede un minuto e fa risparmiare un’ora di debug dei certificati che non è mai stata pertinente.

Annota il trasporto che funziona

Quando una combinazione funziona, annotala con server, porta e protocollo, e indica da quale rete è stata provata.

Altrimenti la prossima persona che incontra un timeout ripeterà lo stesso esperimento nella direzione opposta, e forse cambierà un server che era a posto.

Se il provider pubblica entrambe le varianti, conserva entrambi i file ed etichettali in base alla rete a cui si adattano. Due profili con nomi chiari evitano la mescolanza accidentale di un trasporto client con un listener server che non è mai stato configurato per esso.