Pacchetto IPv6 troppo grande: perché i trasferimenti VPN grandi si bloccano

Il ping funziona, il browser carica una pagina piccola e il trasferimento di file si blocca, tutto su IPv6 attraverso lo stesso tunnel. Questo schema di solito significa che il mittente non ha mai appreso la dimensione reale del percorso, non che il tunnel sia lento. IPv6 si aspetta che i router segnalino il problema con un messaggio Packet Too Big, e l’incapsulamento aggiunge sovraccarico prima ancora che un pacchetto raggiunga la rete esterna. Se quel messaggio viene filtrato, il mittente continua a ripetere una dimensione che non può passare.

Richieste piccole, blocchi grandi

Un tunnel avvolge ogni pacchetto in un’altra intestazione, quindi la dimensione utilizzabile all’interno è più piccola della dimensione all’esterno. Un pacchetto dimensionato per il collegamento fisico prima dell’incapsulamento diventa troppo grande dopo. I router IPv4 possono frammentare lungo il percorso, mentre i router IPv6 non lo fanno per conto del mittente, quindi il mittente deve adattarsi da solo. E questo adattamento dipende interamente dal ricevere il riscontro.

Un solo messaggio perso basta a produrre il sintomo classico: le strette di mano e le risposte piccole riescono, e un elenco di directory o un caricamento si blocca sempre nello stesso punto. Gli utenti lo descrivono come VPN lenta, e i registri non mostrano nulla di sbagliato nell’autenticazione. Entrambe le osservazioni sono accurate e nessuna delle due individua il guasto.

Packet Too Big è un riscontro, non traffico

Un messaggio ICMPv6 Packet Too Big porta la dimensione che il salto successivo può accettare, e il mittente la usa per abbassare la sua stima. Filtrare quel messaggio equivale a togliere un segnale stradale e poi incolpare i conducenti. Una regola che scarta tutto l’ICMPv6 sembra severa e allo stesso tempo rompe la scoperta del percorso su ogni collegamento che ne ha bisogno. Il messaggio è informazione di controllo sul percorso, non carico utile dell’applicazione.

Il filtraggio selettivo resta ragionevole. Le richieste di eco e la scoperta dei vicini svolgono un ruolo diverso dai messaggi di errore, e una policy può trattarli in modo diverso. Seguite le linee guida di filtraggio documentate della piattaforma invece di accettare o scartare l’intero protocollo, perché RFC 8201 definisce come quel riscontro guida la scoperta.

Provate le due famiglie di indirizzi separatamente

Provate IPv6 da solo, perché un trasferimento IPv4 riuscito non dimostra nulla sul percorso IPv6. Poi catturate i messaggi di controllo mentre il trasferimento grande si blocca. I due registri insieme mostrano che il riscontro esce, oppure provano che non è mai arrivato.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

La sonda invia un pacchetto con il bit do-not-fragment impostato e riporta la dimensione alla quale fallisce, cioè il numero che il tunnel deve contenere. L’interrogazione di route nomina l’interfaccia che porterebbe la destinazione, così sapete quale MTU del collegamento si applica. La cattura filtra ICMPv6 tipo 2, il messaggio Packet Too Big, e mostra se arriva a questo host. Se il messaggio compare nella cattura e il trasferimento si blocca ancora, il mittente lo ignora, il che sposta l’indagine nello stack invece che nella rete.

Regolate la dimensione del tunnel solo dopo le prove

Abbassare l’MTU del tunnel può nascondere un messaggio filtrato e far sparire il sintomo, al costo di più sovraccarico su ogni pacchetto. È un aggiramento e non una diagnosi, e dovrebbe seguire la cattura invece di sostituirla. Un valore basso arbitrario non rompe nulla di visibile, ed è per questo che sopravvive per anni nelle configurazioni. Cambiatelo deliberatamente, annotate il valore e indicate quale misura lo ha giustificato.

Quando controllate il gateway, esaminate la regola che scarta il messaggio invece di disattivare il firewall. Una regola corretta è più stretta di un’eccezione di policy e molto più facile da difendere in seguito. Lo stesso ragionamento vale per i timeout: non ogni blocco è un problema di dimensione, ed è la cattura che separa i due casi.