Regolazione del MSS TCP su un gateway Linux IPsec: cosa corregge

Il ping funziona, SSH funziona, una pagina piccola si carica, poi ogni risposta grande resta bloccata finché non scade il tempo. Lo schema classico punta alla dimensione del pacchetto e non alla raggiungibilità: il percorso trasporta l'handshake e i primi kilobyte, poi un segmento a dimensione piena scompare. Su un gateway Linux IPsec, una regola TCP MSS è spesso la soluzione, ma solo se capite cosa cambia e dove si trova davvero il pacchetto che tocca. L'ordine qui sotto segue il pacchetto dal sintomo al posizionamento della regola, così potete fermarvi non appena la spiegazione smette di calzare.

Il sintomo che suggerisce MSS

TCP negozia una dimensione massima del segmento nell'handshake. Se quel valore è maggiore di quanto il percorso può trasportare dopo l'incapsulamento, il mittente continua a produrre segmenti che non arrivano mai, e la connessione si blocca dopo il primo scambio. Le risposte piccole passano; quelle grandi no.

Il feedback ICMP può salvare la connessione tramite la scoperta dell'MTU del percorso, e un firewall che scarta quei messaggi trasforma il blocco in un buco nero silenzioso. Per questo lo stesso tunnel funziona per un'applicazione e fallisce per un'altra senza alcuna differenza evidente nella configurazione.

Cosa fa una regola TCPMSS e cosa non fa

La regola riscrive l'opzione MSS nei pacchetti di handshake TCP mentre passano. Non imposta l'MTU dell'interfaccia del tunnel, non cambia la politica IPsec e sui kernel attuali abbassa solo un valore annunciato invece di alzare uno già più piccolo. Inoltre tocca solo TCP; i carichi UDP, il comportamento di DNS e i selettori di traffico negoziati restano fuori dalla sua portata.

Poiché il cambiamento avviene durante l'handshake, una connessione esistente stabilita prima della regola mantiene il suo vecchio valore. Provate con una connessione nuova e aspettatevi che il primo tentativo dopo la modifica sia quello che vi dice qualcosa. Nulla nella regola raggiunge una connessione già aperta. Per questo una correzione applicata nel mezzo di un incidente può sembrare che non abbia fatto assolutamente nulla.

Mettete la regola sul percorso TCP interno

Su un gateway Linux basato su policy, il pacchetto inoltrato sembra ancora TCP normale quando lo vede il firewall. La politica IPsec decide che il pacchetto sarà protetto; il firewall non vede un'intestazione ESP per il flusso interno, quindi confrontare con ESP qui descrive un pacchetto del tutto diverso. È questa discordanza che fa sembrare corrette alcune regole che poi non corrispondono mai.

In termini di iptables, la regola appartiene alla tabella mangle sul percorso di inoltro, limitata ai pacchetti di handshake: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Il numero è un esempio, non una costante universale; ricavatelo dal sovraccarico dell'incapsulamento e dall'MTU reale del percorso. Un equivalente nftables imposta la dimensione massima del segmento in una catena forward o postrouting.

Tenete le regole di ascolto esterne per IKE ed ESP separate dalle regole di inoltro interne. Una sola regola che tenta di autorizzare sia il flusso dell'applicazione sia il protocollo esterno finisce per non corrispondere in modo affidabile a nessuno dei due.

Rispettate il proprietario del firewall e l'ordine del NAT

Se UFW gestisce il firewall dell'host, aggiungete le modifiche a mangle e inoltro tramite la sua configurazione persistente supportata invece di digitare un comando che sparisce al ricaricamento successivo. Una regola inserita nella tabella sbagliata o dopo una regola terminale non ha alcun effetto, e la tabella attiva ve lo nasconde.

La traduzione della sorgente è una decisione separata che spesso interagisce con questa. Un'eccezione posta prima di una regola masquerade generale impedisce al traffico protetto di perdere la sorgente che la sua politica richiede; non ripara un problema di dimensione, e una regola di dimensione non ripara un problema di traduzione.

Verificate in modo stretto, poi fermatevi

Aprire una connessione nuova al servizio che fallisce e osservate sia l'applicazione sia i contatori della regola. Se il blocco scompare, avete prove su quel percorso TCP con quell'incapsulamento. Non avete prove che ogni protocollo VPN si adatti, che ogni applicazione UDP sia corretta o che un servizio specifico a monte fosse la causa originale.

Lasciate funzionare il feedback di dimensione ICMP dove la politica lo consente, e trattate con cautela la regolazione automatica basata sull'MTU della rotta quando il percorso IPsec esterno non è rappresentato dalla rotta interna. Più stretta è la conclusione, più facile è diagnosticare l'incidente successivo.