MTU e MSS sui tunnel: niente più siti lenti o a metà
Ogni VPN aggiunge overhead: se non gestisci MTU e MSS, ottieni pagine che non caricano, download bloccati e VoIP a scatti, soprattutto su link radio. Guida pratica con overhead per protocollo e MSS clamping.
È il problema VPN più frequente e più sottovalutato: il tunnel "si connette" ma alcuni siti non caricano, gli upload si bloccano a metà, la VoIP gracchia. Quasi sempre è un problema di MTU: ogni protocollo di tunneling incapsula i pacchetti aggiungendo header, riducendo la dimensione utile del payload. Se un pacchetto pieno (1500 byte) entra in un tunnel che ne può portare 1420, va frammentato o scartato.
Perché succede (Path MTU Discovery rotto)
I sistemi usano PMTUD per scoprire la MTU del percorso: inviano pacchetti con flag "Don't Fragment" e si aspettano un messaggio ICMP "Fragmentation Needed" quando sono troppo grandi. Se un firewall lungo il percorso blocca l'ICMP (succede spesso), PMTUD fallisce in silenzio: il pacchetto grande viene scartato e basta. Risultato: l'handshake TCP passa (pacchetti piccoli) ma i trasferimenti grandi si bloccano ("black hole").
Overhead indicativo per protocollo
| Tunnel | Overhead ~ | MTU interfaccia consigliata | MSS consigliata (IPv4) |
|---|---|---|---|
| WireGuard | 60 byte | 1420 | 1380 |
| GRE (no IPsec) | 24 byte | 1476 | 1436 |
| GRE + IPsec | ~70-90 byte | 1400-1420 | 1360-1380 |
| IPIP | 20 byte | 1480 | 1440 |
| IPsec ESP (tunnel) | ~56-73 byte | ~1420-1440 | ~1380-1400 |
| EoIP | 42 byte | 1458 (L2) | clamp lato L3 |
| VXLAN | 50 byte | 1450 | 1410 |
La soluzione regina: MSS clamping
Il MSS clamping riscrive l'opzione TCP MSS nei pacchetti SYN che attraversano il tunnel, forzando i due estremi a usare segmenti più piccoli — così non si genera mai un pacchetto troppo grande da frammentare. È la cura definitiva al "sito che non carica" perché agisce sul TCP a prescindere dal PMTUD.
# 'clamp-to-pmtu' calcola da solo l'MSS corretto in base alla MTU del tunnel. # Applicalo al traffico che ENTRA o ESCE dalle interfacce tunnel. /ip/firewall/mangle/add \ chain=forward \ protocol=tcp tcp-flags=syn \ out-interface=wg-siteB \ action=change-mss new-mss=clamp-to-pmtu \ comment="MSS clamp uscita tunnel" /ip/firewall/mangle/add \ chain=forward \ protocol=tcp tcp-flags=syn \ in-interface=wg-siteB \ action=change-mss new-mss=clamp-to-pmtu \ comment="MSS clamp ingresso tunnel"
# Alternativa: forza un MSS preciso (es. WireGuard a 1380) /ip/firewall/mangle/add \ chain=forward \ protocol=tcp tcp-flags=syn \ tcp-mss=!0-1380 \ out-interface=wg-siteB \ action=change-mss new-mss=1380 \ comment="MSS fisso 1380 sul tunnel WireGuard"
# Esempio: MTU coerente per WireGuard /interface/wireguard/set wg-siteB mtu=1420 # Per GRE /interface/gre/set gre-siteB mtu=1476
Diagnosi rapida
# Ping 'do-not-fragment' verso l'altro capo del tunnel. # Riduci size finché non passa: quella + 28 (header IP+ICMP) = MTU utile. /ping 10.255.255.2 size=1472 do-not-fragment count=3 /ping 10.255.255.2 size=1400 do-not-fragment count=3 /ping 10.255.255.2 size=1380 do-not-fragment count=3
chain=forward su TUTTE le interfacce tunnel della rete.Continua con
Configura senza fatica con l'AI
In WispOS l'agente AI genera la configurazione RouterOS dalle tue parole e un tutor ti guida passo passo.
Prova WispOS