Paquete IPv6 demasiado grande: por que se atascan as transferencias grandes por VPN

O ping funciona, o navegador carga unha páxina pequena e a transferencia de ficheiros colga, todo por IPv6 a través do mesmo túnel. Ese patrón adoita significar que o emisor nunca aprendeu o tamaño real da ruta, non que o túnel sexa lento. IPv6 espera que os encamiñadores informen do problema cunha mensaxe Packet Too Big, e a encapsulación engade sobrecarga antes de que un paquete chegue á rede exterior. Se esa mensaxe se filtra, o emisor segue repetindo un tamaño que non pode pasar.

Solicitudes pequenas, bloqueos grandes

Un túnel envolve cada paquete noutra cabeceira, así que o tamaño utilizábel dentro é menor que o tamaño fóra. Un paquete dimensionado para a ligazón física antes da encapsulación vólvese demasiado grande despois. Os encamiñadores IPv4 poden fragmentar na ruta, mentres que os encamiñadores IPv6 non o fan no nome do emisor, así que o emisor ten que axustarse el mesmo. E ese axuste depende por completo de recibir a retroalimentación.

Unha soa mensaxe perdida abonda para producir o síntoma clásico: os apretóns de mans e as respostas pequenas funcionan, e unha listaxe de directorio ou unha subida atáscase sempre no mesmo punto. Os usuarios descríbeno como que a VPN vai lenta, e os rexistros non amosan nada malo na autenticación. Ambas as observacións son exactas e ningunha localiza a avaría.

Packet Too Big é retroalimentación, non tráfico

Unha mensaxe ICMPv6 Packet Too Big leva o tamaño que o seguinte salto pode aceptar, e o emisor úsaa para baixar a súa estimación. Filtrala equivale a quitar un sinal de tráfico e logo culpar os condutores. Unha regra que descarta todo o ICMPv6 parece estrita mentres rompe o descubrimento de ruta en cada ligazón que o necesita. A mensaxe é información de control sobre a ruta, non carga útil da aplicación.

O filtrado selectivo segue sendo razoábel. As solicitudes de eco e o descubrimento de veciños desempeñan papeis distintos das mensaxes de erro, e unha política pode tratalos de forma diferente. Siga as directrices de filtrado documentadas da plataforma en lugar de aceptar ou descartar todo o protocolo, porque RFC 8201 define como esa retroalimentación impulsa o descubrimento.

Probe as dúas familias de enderezos por separado

Probe IPv6 por separado, porque unha transferencia IPv4 correcta non demostra nada sobre a ruta IPv6. Despois capture mensaxes de control mentres a transferencia grande se atasca. Os dous rexistros xuntos ou ben amosan que a retroalimentación sae, ou ben proban que nunca chegou.

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'

A sonda envía un paquete co bit de non fragmentar activado e informa do tamaño no que falla, que é o número que o túnel ten que absorber. A consulta de ruta nomea a interface que levaría o destino, así que sabe que MTU de ligazón se aplica. A captura filtra ICMPv6 tipo 2, a mensaxe Packet Too Big, e mostra se chega a este host. Se a mensaxe aparece na captura e a transferencia segue atascada, o emisor ignóraa, o que traslada a investigación á pila en lugar de á rede.

Ajuste o tamaño do túnel só despois das probas

Baixar o MTU do túnel pode ocultar unha mensaxe filtrada e facer desaparecer o síntoma, a costa de máis sobrecarga en cada paquete. É unha volta e non un diagnóstico, e debería seguir a captura en lugar de substituíla. Un valor baixo arbitrario tampouco rompe nada visíbel, e por iso sobrevive anos nas configuracións. Cámbieo a propósito, anote o valor e indique que medición o xustificou.

Cando controle a pasarela, revise a regra que descarta a mensaxe en lugar de desactivar a devasa. Unha regra corrixida é máis estreita que unha excepción de política e moito máis fácil de defender despois. O mesmo razoamento vale para os tempos de espera: non todo bloqueo é un problema de tamaño, e a captura é o que separa os dous casos.