Paquet IPv6 massa gran: per què s’encallen les transferències grans per VPN

El ping funciona, el navegador carrega una pàgina petita i la transferència de fitxers es penja, tot per IPv6 a través del mateix túnel. Aquest patró normalment vol dir que l’emissor mai no va aprendre la mida real del camí, no que el túnel sigui lent. IPv6 espera que els encaminadors informin del problema amb un missatge Packet Too Big, i l’encapsulament afegeix sobrecost abans que un paquet arribi mai a la xarxa exterior. Si aquest missatge es filtra, l’emissor continua repetint una mida que no pot passar.

Sol·licituds petites, bloquejos grans

Un túnel embolcalla cada paquet en una altra capçalera, de manera que la mida útil a dins és més petita que la mida a fora. Un paquet dimensionat per a l’enllaç físic abans de l’encapsulament es torna massa gran després. Els encaminadors IPv4 poden fragmentar pel camí, mentre que els encaminadors IPv6 no ho fan en nom de l’emissor, així que l’emissor s’ha d’ajustar ell mateix. I aquest ajust depèn totalment de rebre la retroalimentació.

Un sol missatge perdut ja n’hi ha prou per produir el símptoma clàssic: els intercanvis de salutació i les respostes petites funcionen, i un llistat de directori o una pujada es penja sempre al mateix punt. Els usuaris ho descriuen com que la VPN va lenta, i els registres no mostren res dolent a l’autenticació. Totes dues observacions són exactes i cap de les dues localitza la falla.

Packet Too Big és retroalimentació, no trànsit

Un missatge ICMPv6 Packet Too Big porta la mida que el següent salt pot acceptar, i l’emissor l’utilitza per baixar la seva estimació. Filtrar-lo equival a treure un senyal de trànsit i després culpar els conductors. Una regla que descarta tot l’ICMPv6 sembla estricta mentre trenca el descobriment del camí a cada enllaç que el necessita. El missatge és informació de control sobre el camí, no càrrega útil de l’aplicació.

El filtratge selectiu encara és raonable. Les sol·licituds d’eco i el descobriment de veïns tenen papers diferents dels missatges d’error, i una política els pot tractar de manera diferent. Seguiu les directrius de filtratge documentades de la plataforma en lloc d’acceptar o descartar tot el protocol, perquè RFC 8201 defineix com aquesta retroalimentació impulsa el descobriment.

Proveu les dues famílies d’adreces per separat

Proveu IPv6 per separat, perquè una transferència IPv4 correcta no demostra res sobre el camí IPv6. Després captureu missatges de control mentre la transferència gran es penja. Els dos registres junts o bé mostren que la retroalimentació surt, o bé proven que no va arribar mai.

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 envia un paquet amb el bit de no fragmentar activat i informa de la mida a la qual falla, que és el número que el túnel ha d’absorbir. La consulta de ruta nomena la interfície que portaria la destinació, així que sabeu quin MTU d’enllaç s’aplica. La captura filtra ICMPv6 tipus 2, el missatge Packet Too Big, i mostra si arriba a aquest host. Si el missatge apareix a la captura i la transferència encara es penja, l’emissor l’ignora, cosa que trasllada la investigació a la pila en lloc de la xarxa.

Ajusteu la mida del túnel només després de les proves

Baixar l’MTU del túnel pot amagar un missatge filtrat i fer desaparèixer el símptoma, a costa de més sobrecost a cada paquet. És una solució temporal i no un diagnòstic, i hauria de seguir la captura en lloc de substituir-la. Un valor baix arbitrari tampoc no trenca res visible, i per això sobreviu anys a les configuracions. Canvieu-lo deliberadament, anoteu el valor i indiqueu quina mesura el justificava.

Quan controleu la passarel·la, reviseu la regla que descarta el missatge en lloc de desactivar el tallafocs. Una regla corregida és més estreta que una excepció de política i molt més fàcil de defensar després. El mateix raonament val per als temps d’espera: no tots els bloquejos són un problema de mida, i la captura és el que separa els dos casos.