UDP non è sempre più veloce: scegliere il trasporto di OpenVPN

Ogni guida dice che UDP batte TCP per OpenVPN, e questo consiglio è una scelta predefinita, non una misura. Il trasporto cambia come vengono consegnati i pacchetti e cosa succede quando il percorso li scarta, non come viene cifrato il tunnel. Dietro un portale captivo o un proxy che consente solo la porta 443, l’opzione più lenta è quella che si connette affatto. Quanto segue separa ciò che fa il protocollo da ciò che consente la vostra rete di accesso.

Cosa cambia davvero il trasporto

TCP fornisce un flusso di byte affidabile e ordinato e ritrasmette tutto ciò che si perde, come specifica la RFC 9293. UDP consegna i datagrammi alla rete, e OpenVPN esegue il proprio livello di affidabilità sopra quel socket. Incapsulare TCP dentro TCP impila due cicli di recupero, quindi un solo segmento perso può trattenere il flusso interno finché non arriva la ritrasmissione esterna. Questa interazione è il vero argomento a favore di UDP, e si manifesta come latenza anziché come throughput.

L’effetto cresce con le perdite e il tempo di andata e ritorno. Su un percorso locale pulito i due trasporti sembrano identici, ed è per questo che un test di laboratorio raramente riproduce la lamentela. Su un collegamento mobile congestionato la differenza si vede nelle sessioni interattive molto prima che un trasferimento massiccio noti qualcosa.

Niente di tutto ciò tocca riservatezza o integrità. L’handshake TLS e la cifratura del canale dati sono gli stessi per entrambi i trasporti, quindi cambiare non può salvare una suite di cifratura debole.

Dove TCP si guadagna il suo posto

Le reti di accesso sono la ragione abituale per scegliere TCP. Un hotel, un aeroporto o una rete per ospiti possono consentire la 443 in uscita e scartare tutto il resto, e un listener TCP su quella porta è l’unico profilo che funziona. È raggiungibilità, non prestazioni, ed è una ragione abbastanza buona da sola.

TCP aiuta anche quando il percorso è stabile ma i dispositivi intermedi sono ostili. Alcune reti azzerano i flussi UDP di lunga durata mentre tollerano sessioni TCP che somigliano a normale traffico web. Se quella somiglianza riesce è una proprietà della rete specifica, e nessuna guida può prometterlo per tutte. Provate dentro la rete che fallisce prima di dare la colpa al protocollo.

Un accesso rifiutato non è un problema di trasporto. Disattivare la verifica del certificato per forzare una connessione è un’altra modifica con un esito molto peggiore.

Tenere pronto un profilo TCP è il compromesso pratico. La maggior parte dei client conserva entrambi e consente di passare quando una rete rifiuta il percorso UDP, cosa che non costa nulla finché non ne avete bisogno. Quello che non dovreste fare è distribuire due profili che puntano a endpoint diversi, perché allora il confronto misura i server.

Verificate quale listener avete davvero

Prima di confrontare le prestazioni, confermate che entrambe le estremità concordino su trasporto e porta. Sostituire proto udp con proto tcp in un file client non crea un listener sul server. Il server deve essere configurato per quel protocollo, e il profilo deve corrispondergli.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep stampa ciò che è stato detto al server di usare, mentre i due elenchi di socket mostrano a cosa è associato. Un listener UDP appare solo nel primo elenco e un listener TCP solo nel secondo, quindi una riga mancante è il modo più rapido per trovare un profilo che non è mai stato applicato. Confrontate anche la porta, perché un profilo TCP sulla 1194 si comporta diversamente da uno sulla 443 nella maggior parte delle reti di accesso. Riavviate il servizio dopo la modifica e leggete la riga di log che segnala l’associazione.

La conferma lato client costa poco: avviate la connessione con --verb 4 e leggete la riga del trasporto nel log. Se il client dice UDP mentre il server ascolta su TCP, l’handshake non inizia mai e nessuna messa a punto aiuterà.

Confrontate il carico di lavoro, non l’etichetta del trasporto

Un confronto equo tiene tutto costante tranne il trasporto. Stesso dispositivo, stessa rete di accesso, stesso host di destinazione, stessa applicazione e idealmente stesso server. Se i due profili puntano a host diversi, state misurando anche quegli host.

Registrate tre esiti per ogni esecuzione: se il tunnel si stabilisce, se resta attivo e se l’attività si completa. Le richieste piccole che funzionano mentre i trasferimenti grandi si bloccano indicano dimensione dei pacchetti e MTU, non il trasporto. Le riconnessioni ripetute indicano il percorso o un timeout di un dispositivo intermedio.

Conservate il profilo che funziona nelle condizioni che incontrate davvero, e tenete salvato l’altro. La scelta appartiene alla rete, non alla persona, ed è per questo che qualsiasi risposta predefinita unica è sbagliata da qualche parte.