Los paquetes grandes desaparecen por IPsec mientras los pings pequeños siguen funcionando
Las sondas pequeñas responden y las copias de archivos se atascan, la firma de una decisión de tamaño tomada antes del cifrado. Averigüe qué lado divide el paquete y por qué.
Los shells remotos siguen respondiendo, las sondas pequeñas responden y entonces una copia de archivo se arrastra y se atasca sin ningún error que alguien pueda señalar. Un ping con una carga mayor lo reproduce al instante, y la misma transferencia funciona desde la red local. Nada del cifrado es lento; ciertos paquetes nunca llegan. Dos divisiones distintas pueden producir esa firma, y dejan pruebas diferentes.
Dos lugares donde se puede dividir un paquete
Antes del cifrado, el enrutador puede dividir un paquete interno demasiado grande y proteger cada trozo por separado. Después del cifrado, lo que se divide es el paquete externo ya terminado, y el extremo lejano tiene que reensamblarlo antes de descifrar nada. Mismo síntoma, trabajo distinto para el receptor y mandos distintos para usted.
La distinción importa porque una corrección dirigida al lado equivocado cambia un número sin mover el fallo. Un paquete rechazado en la interfaz nunca llega a ser un paquete externo, así que ningún ajuste del lado externo puede rescatarlo.
Dónde se toma realmente la decisión de tamaño
Una interfaz de túnel lleva una IP MTU, y ese valor puede rechazar un paquete interno demasiado grande mucho antes de que lo vea la etapa IPsec. Poner un bit en la cabecera externa no revisa esa decisión anterior, porque el paquete ya había sido rechazado. Por eso subir la MTU interna a veces empeora las cosas en lugar de mejorarlas. Lea el valor de la interfaz y el comportamiento externo antes de cambiar cualquiera de los dos, porque el cambio más barato suele ser el que explica el síntoma.
Compruebe primero el valor de la interfaz y luego el comportamiento externo. Dos números, dos etapas, y normalmente solo una de ellas es la responsable.
El presupuesto externo no es el presupuesto interno
Cada encapsulación gasta bytes en cabeceras, y la cantidad depende del transporte, de la familia de direcciones y de si hay traversal de NAT. Un paquete interno que cabe en el enlace local todavía puede producir un paquete externo que no cabe en la ruta más allá. Mida la sobrecarga en lugar de suponerla, porque cada cabecera opcional se suma a la factura. Un túnel con traversal de NAT paga más que uno desnudo, y la diferencia basta para romper una transferencia que ayer funcionaba.
Cuando el paquete externo lleva el bit de no fragmentar, un salto que no puede reenviarlo lo descarta y debería devolver un mensaje ICMP. Si ese mensaje se filtra en algún punto, el emisor sigue reintentando y el usuario ve un atasco sin explicación. Ese descarte silencioso es la razón habitual de que un problema de tamaño se reporte como un problema de velocidad.
IPv6 elimina una de las opciones
Los enrutadores IPv6 no fragmentan en tránsito, así que el paquete externo o cabe o desaparece con un mensaje Packet Too Big. Ese mensaje se convierte en el único canal de retroalimentación, y bloquearlo rompe el descubrimiento de ruta para cada transferencia grande que venga después. Los enrutadores IPv4 pueden fragmentar un paquete grande cuando el bit está claro, lo que oculta el fallo hasta que algo más pone ese bit.
En una pila mixta, el mismo túnel puede comportarse de forma distinta para las dos familias, por eso una prueba sobre IPv4 no resuelve una queja sobre IPv6. Una comprobación que ejercita una familia deja la mitad de la respuesta sin medir.
La política de segmentos TCP no es una respuesta general
Limitar el tamaño máximo de segmento ayuda a los flujos TCP, y es un control legítimo cuando el problema se limita a ellos. No tiene ningún efecto sobre UDP, que transporta DNS, algunos protocolos de voz y una parte creciente del tráfico web.
Aplíquelo y luego pruebe la carga que falló. Si el caso UDP sigue fallando, la política de segmentos nunca fue la respuesta y el presupuesto de la interfaz todavía necesita atención. Identifique primero el protocolo de la carga que falla y luego elija el control que le corresponde.
El orden en que trabajar
Anote la carga más grande que sobrevive, luego la MTU de la interfaz, luego si el paquete externo lleva el bit de no fragmentar y por último si la retroalimentación ICMP llega al emisor. Esa secuencia acota el fallo sin adivinar. Guarde cada observación con una marca de tiempo y un extremo, porque los cuatro números se mueven cuando cambia la ruta.
Cambie un valor, vuelva a probar la transferencia original y guarde el resultado. Un túnel que pasa una sonda grande pero sigue atascándose en la aplicación ha pasado a otro problema, y eso es un avance que merece anotarse. La siguiente persona prefiere los números a la conclusión.