MSS clamping su un gateway VPN: cosa risolve e cosa no

Le richieste piccole funzionano, i download grandi si bloccano e qualcuno suggerisce l'MSS clamping. Quel suggerimento è abbastanza spesso giusto da meritare una prova nell'ordine corretto, e abbastanza spesso sbagliato da far perdere un pomeriggio se lo si applica alla cieca. I tre controlli seguenti separano un vero problema di dimensione TCP da un problema UDP, da una scoperta path-MTU rotta e da un clamp che non vede mai l'handshake che dovrebbe riscrivere.

Iniziate dalla forma del guasto

Un guasto di dimensione ha una firma: la connessione si stabilisce, autenticazione e risposte piccole riescono, poi un trasferimento si blocca indefinitamente appena serve un segmento a dimensione piena. Le pagine che caricano testo ma non completano mai un'immagine sono lo stesso guasto su scala minore. Se non si connette nulla, il problema è più a monte nel percorso e il clamping non aiuterà. Un clamp non può riparare un handshake che non è mai arrivato.

La firma esiste perché l'handshake è il punto in cui si concorda la dimensione del segmento. Ogni lato annuncia una dimensione massima del segmento come opzione TCP, e i mittenti rispettano l'annuncio della controparte. Se il percorso non riesce a trasportare un segmento così grande, il guasto appare più tardi, quando il mittente ne prova finalmente uno.

Tenete il trasporto sott'occhio mentre leggete quel sintomo. Il clamping è una riscrittura di un'opzione TCP, quindi una chiamata voce o video che si blocca sotto lo stesso tunnel non è un problema di MSS e non migliorerà per questo. Annotate il trasporto prima di toccare un'opzione TCP.

Valutate il percorso, poi confrontatelo con il tunnel

Due numeri contano e spesso vengono confusi. La path-MTU è il pacchetto più grande che il percorso trasporta senza frammentazione, e l'MSS annunciato per IPv4 è quel valore meno i 40 byte di intestazioni IP e TCP, oppure meno 60 per IPv6. L'incapsulamento del tunnel consuma parte del budget prima ancora che il pacchetto interno inizi.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

Il ping con il bit do-not-fragment vi dice se un pacchetto di quella dimensione di carico sopravvive; regolate la dimensione finché fallisce e avete trovato empiricamente il limite del percorso. L'output di tracepath riporta l'MTU scoperto lungo la rotta, che è più rapido quando funziona e meno affidabile quando un salto intermedio filtra le sonde.

Ora sottraete l'overhead del tunnel. Un'intestazione IP esterna, un'intestazione UDP e un'intestazione specifica del tunnel escono tutte dagli stessi 1500 byte, quindi l'MTU interno utilizzabile su una base Ethernet tipica è inferiore a quanto suggerisce il collegamento fisico. Se l'MTU interno calcolato è sotto quello annunciato dalle controparti, avete trovato un candidato reale al clamp e non una congettura. Se il valore calcolato è già sopra l'annuncio delle controparti, fermatevi qui e cercate altrove.

Collocate il clamp dove passa l'handshake

Un clamp funziona riscrivendo l'opzione MSS nei pacchetti SYN e SYN-ACK mentre attraversano il gateway. Se la regola si trova su un'interfaccia che nessuna delle due direzioni attraversa mai, la negoziazione si completa invariata e il sintomo persiste, per questo la collocazione decide l'esito più del valore.

La direzione è l'altra metà. Applicare il clamp a una sola direzione corregge metà dei flussi e lascia il resto a fallire in un modo che sembra intermittente, quindi applicatelo a entrambe le direzioni del traffico inoltrato. La forma classica in Linux per un'interfaccia di tunnel è una regola mangle che corrisponde ai pacchetti SYN:

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

Notate cosa fa realmente --clamp-mss-to-pmtu: deriva il valore dall'MTU della rotta, che non è sempre il budget reale di carico del tunnel. Su un tunnel basato su rotta dove la rotta interna e il percorso esterno differiscono, un valore esplicito calcolato nel controllo precedente è più prevedibile di uno automatico.

Verificate con una nuova connessione e mantenete vivo il riscontro

Una connessione stabilita conserva l'MSS negoziato, quindi provare nella stessa sessione non dimostra nulla. Aprite una nuova connessione dopo la modifica e leggete il valore negoziato direttamente invece di dedurlo da un trasferimento che per caso si completa.

ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSS

Il primo comando riporta l'MSS del socket insieme al suo stato di congestione, che è la conferma più rapida che il clamp ha avuto effetto. Il secondo conferma che la regola che credete di aver aggiunto è la regola esistente, nella tabella in cui è stata inserita.

Poi proteggete il meccanismo che non avete corretto. La scoperta path-MTU dipende dall'arrivo dei messaggi ICMP fragmentation-needed al mittente, quindi un firewall che li scarta continuerà a rompere i trasferimenti grandi anche con un clamp corretto. Consentite quei messaggi per il percorso del tunnel, oppure accettate che il clamping compensi una politica che avete scelto.

Infine, resistete alla tentazione di trattare il clamp come una manopola di regolazione. Limita la dimensione del segmento, il che costa throughput su percorsi che non ne hanno mai avuto bisogno. Applicato dopo i tre controlli è una riparazione mirata; applicato per primo è una modifica che nasconde il guasto originale e aggiunge una seconda variabile a ogni test successivo. Quello scambio vale la pena farlo deliberatamente, non per impostazione predefinita.

Annotate la path-MTU misurata, l'overhead del tunnel sottratto, la regola aggiunta e l'MSS visto dopo. Quattro numeri trasformano il prossimo incidente in una consultazione invece che in un'indagine.