Descubrimento do MTU da ruta a través dunha VPN: tamaño e o oco do ICMP

Un túnel completa o seu handshake, as solicitudes pequenas volven, e a primeira transferencia grande detense. Ese patrón apunta ao MTU da ruta moito antes de apuntar ao rendemento. Cada enlace ao longo da ruta limita o tamaño do paquete, e a encapsulación gasta parte dese marxe en cabeceiras externas, polo que o paquete interno debe ser menor do que suxeriría a ruta bruta. O fallo é silencioso, e iso é o que o fai caro de diagnosticar.

Que mide realmente o MTU da ruta

O MTU da ruta é o MTU de enlace máis pequeno na ruta entre dous equipos, non o MTU impreso na túa interface local. O valor local é onde comeza a estimación, e a ruta decide onde debe rematar. Por iso un túnel idéntico pode funcionar nunha rede de acceso e deterse noutra: cambiou a ruta, non a configuración. Medir unha vez e asumir en todas partes é o erro que mantén vivo este problema.

Para un túnel, o número que importa é o MTU interno, que é o marxe da ruta externa menos o que consome a encapsulación. WireGuard engade unha cabeceira IP externa e unha cabeceira UDP; outros transportes engaden as súas. Pon o tamaño interno demasiado alto e cada paquete de tamaño completo necesita unha fragmentación que pode que nunca ocorra.

Por que un túnel reduce o paquete útil

Se a interface do túnel mantén o MTU do enlace físico, cada paquete grande depende de que alguén máis adiante estea disposto a fragmentalo. IPv4 permíteo en principio, pero un router ao que se lle di que non fragmente devolve un erro no seu lugar. Os routers IPv6 nunca fragmentan en tránsito, así que a mesma configuración compórtase de forma distinta segundo a familia de enderezos. En calquera caso o emisor non aprende nada ata que algo informa de volta.

A consecuencia práctica é un tamaño que encaixa no handshake e non na carga útil. Un TLS ClientHello ou unha consulta DNS é o suficientemente pequeno para cruzar unha ruta reducida sen tocar, mentres que unha transferencia masiva non o é. Os síntomas, xa que logo, agrúpanse arredor de operacións concretas e non de equipos concretos.

O descubrimento só funciona cando chega a realimentación

O descubrimento IPv4 baséase no bit don't-fragment: un router que non pode reenviar o paquete devolve ICMP fragmentation-needed co MTU do seguinte salto, e o emisor baixa a súa estimación. IPv6 usa mensaxes Packet Too Big no seu lugar, porque os routers non fragmentan en tránsito. Ambos os mecanismos supoñen que a mensaxe atopa o camiño de volta ao emisor, a través do túnel e máis aló de calquera firewall na ruta de retorno. Cando esa suposición falla, o emisor segue reintentando un tamaño que a ruta non pode transportar.

Un firewall que permite echo request e echo reply non necesariamente permitiu eses tipos de erro. ICMP é unha familia, e os membros que importan aquí son os erros, non o par de eco. Comproba a política de tráfico de control nos dous extremos do túnel e na ruta entre eles, e segue a guía admitida pola plataforma en lugar de permitir todos os tipos ICMP en todas partes.

O mesmo filtrado pode estar dentro do túnel. Se a ruta interna descarta o erro pero a externa transpórtao, o emisor pode adaptarse a un límite que o tráfico encapsulado nunca ve de verdade.

Proba a ruta en lugar de adiviñar un número

Mantén fixos o destino, a rede de acceso e o túnel, e varía só o tamaño do paquete. Unha proba don't-fragment que falla cunha indicación de MTU dache o límite do seguinte salto; repite ata que pase un tamaño, e anota tanto o tamaño como a familia de enderezos.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Un ping que encaixa non demostra que encaixen os segmentos de tamaño completo dunha aplicación real, así que repite a proba coa transferencia que fallou de verdade. Compara a proba máis grande que funcionou co MTU do túnel que configuraste, e mantén os dous números separados nas túas notas. Se difiren aproximadamente nunha cabeceira, atopaches a sobrecarga da encapsulación e non un fallo.

PLPMTUD, descrito na RFC 4821, proba cara arriba e usa confirmacións de transporte en lugar de confiar nos erros entregados. Axuda nas rutas que filtran ICMP, pero o soporte varía segundo a pila e a aplicación. Un fluxo TCP pode recuperarse por si só mentres unha aplicación UDP cun tamaño de datagrama fixo segue fallando.

Escolle un valor e rexistra o razoamento

Baixar o MTU do túnel é á vez un diagnóstico e unha corrección lexítima unha vez que coñeces a ruta. Non substitúe saber que ruta e que mecanismo de realimentación estaban implicados, porque un valor axustado para un enlace móbil será innecesariamente pequeno nunha conexión de fibra. Rexistra o tamaño elixido, a proba que o xustificou e o paso de reversión.

O mecanismo IPv4 descríbese na RFC 1191 e a guía de paquetización IPv6 na RFC 8201; nomear ambos evita que o seguinte enxeñeiro volva derivar a suposición. Se a transferencia aínda se detén no tamaño que escolleches, deixa de baixar o número e mira a capa seguinte. Unha ruta que falla con todos os tamaños non é un problema de MTU.