Perché bloccare tutto l'ICMP rompe un percorso VPN che funziona
I messaggi di riscontro sulla dimensione non sono risposte ping. Quando non arrivano mai, i pacchetti piccoli passano, quelli grandi svaniscono e il tunnel sembra sfarfallare.
Un tunnel che si autentica, trasporta un ping e poi si blocca al primo trasferimento grande è la firma classica di un messaggio ICMP mancante e non di una VPN guasta. Il mittente non scopre mai che un pacchetto era troppo grande, ritenta la stessa dimensione e l'applicazione resta in attesa. Correggerlo è una decisione di politica del firewall, non una reinstallazione del client. L'ordine conta: misurate dove si trova il limite di dimensione, poi restringete la regola che ha inghiottito il rapporto.
Che cosa trasporta davvero ICMP su questo percorso
Rilevamento dell'MTU di percorso IPv4 si basa su un router che segnala che un pacchetto con il bit don't-fragment impostato non è stato inoltrato. Quel rapporto è un messaggio ICMP Fragmentation Needed e, senza di esso, il mittente non ha motivo di ridurre la dimensione del segmento. IPv6 è più rigido: i router non frammentano in transito, quindi un messaggio ICMPv6 Packet Too Big è l'unico segnale che fa restringere il mittente.
Entrambi i messaggi sono riscontri del piano di controllo e nessuno dei due è un eco diagnostico. Una politica che blocca ping e una che blocca tutto l'ICMP si somigliano in un elenco di regole ma si comportano in modo molto diverso sulla rete. La seconda può trasformare un tunnel dimensionato correttamente in un percorso a senso unico per qualunque cosa superi l'anello più piccolo della catena.
Alcuni trasporti implementano il proprio rilevamento con pacchetti di sonda, come descrive l'RFC 4821, e dipendono meno da questo riscontro. È un argomento per verificare quale trasporto eseguite, non per supporre che ogni tunnel sia immune.
| Messaggio | Scopo sul percorso | Se bloccato |
|---|---|---|
| ICMPv4 tipo 3 codice 4 | Il pacchetto era troppo grande per il collegamento successivo | Il mittente ritenta e si blocca |
| ICMPv6 tipo 2 | Packet Too Big, l'equivalente IPv6 | Lo stesso blocco, senza ripiego sulla frammentazione |
| ICMP tipo 11 | Tempo superato, usato da traceroute | La diagnostica perde salti, il traffico continua a fluire |
| Richiesta e risposta di eco ICMP | Test di raggiungibilità | Il ping fallisce, il percorso può essere a posto |
Il guasto dipende dalla dimensione
Chiedete se il guasto è correlato alla dimensione del pacchetto. Una pagina di accesso, una query DNS e una breve chiamata API passano, mentre un caricamento di file, una risposta grande o un download di immagine si bloccano. Questo schema indica un limite di dimensione da qualche parte tra i due estremi, non l'autenticazione o l'instradamento. Un piccolo ping riuscito non dice quasi nulla su dove si trovi quel confine.
Dentro un tunnel ci sono due livelli da considerare: il pacchetto di payload e il pacchetto esterno incapsulato. Il mittente interno può comportarsi correttamente mentre il percorso esterno è più piccolo di quanto il tunnel presupponga, ed è per questo che contano sia l'impostazione MTU del tunnel sia il collegamento fisico sottostante.
Misurate prima di modificare le regole
Sondate con il bit don't-fragment e una dimensione di payload che scegliete voi, dal client guasto verso un indirizzo protetto:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7Un payload di 1472 byte più 28 byte di intestazioni è un pacchetto di 1500 byte. Se la sonda grande fallisce con un errore di frammentazione e quella piccola passa, avete trovato il confine; correggete per l'overhead del tunnel e ripetete finché la dimensione funzionante non è stabile.
Poi confermate che il divario è il rapporto stesso. Se la sonda fallisce in silenzio, senza errore e senza risposta, il messaggio viene probabilmente scartato invece che consegnato, e la regola è la sospetta.
Restringete la regola, poi ricontrollate il compito
La correzione dovrebbe consentire i messaggi di controllo specifici, non l'intero protocollo. Su un host con iptables la forma è un'accettazione per tipo; adattate la sintassi a ciò che gestisce il firewall sulla vostra piattaforma:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTLasciate bloccate le risposte di eco se è la politica locale, perché il percorso non ne ha bisogno. Poi ricontrollate il trasferimento che era fallito, da una nuova connessione, e confermate che i contatori della regola mostrano i messaggi in arrivo.
Se il trasferimento grande si blocca ancora dopo aver consentito i messaggi, il limite rimanente è altrove: un MTU del tunnel troppo alto, un proxy che riscrive i pacchetti o un apparato intermedio che scarta invece di segnalare. La regola ICMP era necessaria, non sufficiente.