Perché una VPN si blocca sui trasferimenti grandi e non su quelli piccoli

Una pagina si carica, un ping riesce e una copia di file si blocca sempre nello stesso punto. Questo schema indica la dimensione dei pacchetti, non la larghezza di banda o le credenziali. L'incapsulamento aggiunge byte a ogni pacchetto, quindi un carico utile che entrava nel percorso originale può superare il limite una volta passato per un tunnel. In queste conversazioni tre numeri diversi vengono chiamati MTU, e confonderli porta a un'impostazione che sistema un'applicazione e ne rompe un'altra.

Tre numeri che la gente chiama MTU

La MTU dell'interfaccia è il limite configurato per un pacchetto su quel collegamento. La MTU del percorso è il limite più piccolo lungo la rotta, e si scopre invece di configurarsi. La MSS di TCP è la dimensione del carico utile che un peer dichiara di poter ricevere, e deriva dagli altri due invece di essere un limite fisico a parte.

Un tunnel ha una vista interna e una esterna. Il pacchetto esterno trasporta quello incapsulato più le intestazioni necessarie al protocollo, quindi la dimensione interna utilizzabile è minore di ciò che consente il percorso esterno. Anche il percorso verso il server VPN è diverso dal percorso del server verso la destinazione.

La scoperta della MTU di percorso permette a un mittente di conoscere la dimensione che funziona, ma dipende dall'arrivo del riscontro. Quando un dispositivo intermedio filtra i messaggi ICMP pertinenti, il mittente continua a trasmettere pacchetti che non arrivano mai a termine, ed è il classico buco nero. Il sintomo è inequivocabile quando lo si conosce: l'handshake riesce, il primo carico a dimensione piena sparisce e la connessione alla fine si reimposta o si blocca. Niente nel registro dell'applicazione sembra un problema di rete.

Sonda il percorso con un carico che controlli

Una sonda è una prova su una rotta e una dimensione, non un'impostazione consigliata. Usa un host che risponde e varia solo la dimensione del carico.

ping -M do -s 1372 -c 2 203.0.113.20
ping -4 -f -l 1372 vpn.example

Il primo comando invia una sonda Linux con la frammentazione disattivata e un carico di 1372 byte, e il secondo fa lo stesso su Windows, dove il carico si imposta con -l. Una risposta significa che quella dimensione ha superato il percorso. Un messaggio di frammentazione necessaria è informativo, mentre un timeout è ambiguo perché l'host o un dispositivo intermedio possono semplicemente scartare ICMP.

Scendi di dimensione in pochi passi invece di fare una ricerca binaria fino al byte. Stai cercando di stabilire se esiste un tetto di dimensione, non di pubblicare un numero per ogni rete. Il numero che trovi vale per questo percorso, questo protocollo e questa famiglia di indirizzi.

IPv4 e IPv6 frammentano in modo diverso, quindi il risultato di una famiglia non dice nulla sull'altra. Prova la famiglia che l'applicazione usa davvero.

Il clamp MSS aiuta solo TCP

In TCP il carico utile effettivo viene negoziato durante l'handshake, e un router del percorso può riscrivere quel valore verso il basso perché entrambi gli estremi inviino segmenti più piccoli. È ciò che fa il clamp MSS, e funziona senza toccare affatto il client.

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip link show tun0

La prima regola limita la MSS annunciata alla MTU del percorso per gli handshake TCP inoltrati, e la seconda mostra la MTU propria dell'interfaccia del tunnel così da confrontarla con ciò che il percorso consente. Il clamp è la riparazione meno invasiva per un'applicazione TCP che si blocca dopo l'handshake.

Per UDP non fa nulla. Un client vocale o di gioco che invia datagrammi grandi ignorerà del tutto un'impostazione MSS, perché non c'è alcun handshake da riscrivere. Se l'applicazione che fallisce è UDP, guarda invece le opzioni di dimensione dei pacchetti del client stesso. I due protocolli falliscono in modo diverso e si riparano con strumenti diversi, per questo il protocollo appartiene alla prima frase del ticket.

OpenVPN espone opzioni come tun-mtu, mssfix e impostazioni legate alla frammentazione, e il loro comportamento dipende dalla versione e dal fatto che il canale dati sia AEAD. Leggi il manuale della versione in uso e cambia un'opzione alla volta.

Cambia un solo valore supportato e ripeti entrambe le prove

Conserva il profilo originale, cambia un solo valore supportato e ripeti sia la richiesta piccola che funzionava sia il trasferimento grande che falliva. Se cambia solo quello grande, stavi inseguendo la dimensione. Se cambiano entrambi, qualcos'altro si è mosso con essa.

Un valore più basso può ridurre il sintomo aggiungendo però overhead, quindi il numero più piccolo possibile non è l'obiettivo. L'obiettivo è una dimensione che il percorso trasporti in modo affidabile con il minimo spreco. Annota il valore, il percorso e la versione del client nel ticket, perché lo stesso numero applicato altrove è una supposizione.

Se lo stesso profilo funziona da un'altra rete fidata, mantieni quella differenza nella diagnosi invece di dichiarare il client riparato. La variabile cambiata è il percorso, e il percorso è ciò che la sonda ha misurato.