OpenVPN mssfix: perché un client si blocca nei trasferimenti grandi

Un solo portatile si blocca durante gli invii attraverso il tunnel mentre ogni altro dispositivo sullo stesso server continua a funzionare. Questo schema indica un percorso, non la configurazione del server, ed è l’ingresso abituale alla questione mssfix. L’opzione può aiutare, ma solo per le connessioni TCP che riscrive davvero. Conoscerne la portata vi evita di modificare un server che funziona per salvare un solo client.

Cosa riscrive l’opzione

mssfix modifica la dimensione massima del segmento annunciata negli handshake TCP che attraversano il tunnel, così il lato mittente sceglie segmenti che rientrano nel budget incapsulato. Agisce sull’handshake, il che significa che una connessione aperta prima della modifica conserva il valore negoziato.

Non riduce i datagrammi UDP e non imposta l’MTU del tunnel. Due problemi diversi producono lo stesso sintomo: un mittente TCP che ignora il limite del percorso e un percorso che scarta silenziosamente pacchetti grandi di qualsiasi dimensione. mssfix affronta il primo e non fa nulla per il secondo.

Questa distinzione spiega gli esperimenti deludenti. Impostare un valore più piccolo su un percorso con buco nero cambia la dimensione del segmento ma non lo scarto che segue, quindi il trasferimento fallisce in un altro punto.

La portata è TCP dentro il tunnel

Viene riscritto solo il traffico TCP. Una sessione QUIC, un gioco o un’applicazione che invia datagrammi UDP grandi manterrà le proprie dimensioni dei pacchetti, e se sono quei trasferimenti a bloccarsi, la correzione appartiene piuttosto all’MTU del tunnel o del percorso. Leggete quale protocollo usa il trasferimento che fallisce prima di ricorrere a un’opzione TCP, perché lo strato sbagliato ha la propria correzione.

Anche la direzione conta. Un’impostazione del client influisce sul traffico che quel client invia nel tunnel, mentre il server copre i flussi che inoltra verso i client. Se si bloccano solo i download in entrata, il valore lato client non è tutta la storia.

Il numero e la parola chiave non sono portabili

La versione community di OpenVPN 2.6 accetta una parola chiave opzionale dopo il valore. Con mtu, il numero descrive la dimensione del pacchetto esterno, incluse le intestazioni IP e UDP; senza, l’argomento segue un’altra convenzione di calcolo. Una riga copiata tra versioni non descrive quindi lo stesso budget di pacchetti. Consultate la pagina di manuale fornita con la build che eseguite davvero, invece di un tutorial per un’altra release.

La sintassi è questa:

mssfix 1400 mtu

Trattate 1400 come segnaposto, non come raccomandazione per il vostro percorso. Ricavate il valore dal percorso misurato e dall’incapsulamento realmente in uso, e ricordate che i client su versioni più vecchie o altre implementazioni possono rifiutare o reinterpretare la parola chiave.

Confermatelo prima sull’unico client

Misurate il percorso dalla macchina che fallisce prima di cambiare qualsiasi cosa. Un carico utile che il percorso può trasportare senza frammentazione è il numero che cercate:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

La prima sonda entra in un pacchetto da 1500 byte una volta aggiunti i 28 byte di intestazioni. Se fallisce con un errore di frammentazione e quella più piccola riesce, la dimensione utilizzabile è da qualche parte tra le due, e l’overhead del tunnel viene sottratto dall’alto.

Poi ripetete il trasferimento che si era bloccato, su una nuova connessione, e confrontate. Se il client unico migliora mentre gli altri restano intatti, avete trovato la portata del problema. Se si bloccano tutti i client, il valore lato server è quello da rivedere. Nessuno dei due risultati giustifica una modifica su hardware che non è mai stato sul percorso guasto.