La sobrecarga de IPsec: el modo, el NAT-T y los algoritmos la cambian
Una sola cifra publicada de sobrecarga describe un encapsulado en una ruta. Sume las cabeceras que su túnel negocia de verdad y luego mida la ruta.
En algún lugar de una guía hay un número, normalmente entre sesenta y ochenta bytes, que alguien restó de 1500 para obtener una MTU de interfaz. Ese número describe un encapsulado concreto en una ruta concreta. Cambie el modo, la familia de direcciones exterior, el cifrado o la presencia de NAT, y la aritmética ya no se aplica a su túnel.
El número vino de otro túnel
La sobrecarga no es una propiedad de IPsec en abstracto. Es una propiedad del paquete que realmente se construye: un modo negociado, una cabecera exterior, una cabecera de protección, relleno, un campo de integridad y quizá una envoltura UDP adicional.
Una cifra citada para el modo transporte con IPv4 y sin NAT describe un paquete más pequeño que el modo túnel con IPv6 bajo travesía de NAT. Ambas son correctas para su propio caso. Copiar cualquiera de ellas a un despliegue distinto es como la gente acaba con una MTU que rompe las transferencias grandes. El fallo es silencioso porque las peticiones pequeñas siguen funcionando.
Sume las capas que realmente están ahí
Empiece por la cabecera IP exterior y avance hacia dentro. En modo túnel el paquete original está dentro, así que la cabecera exterior es un añadido y no un reemplazo. RFC 4303 describe la cabecera ESP, el relleno y los datos de integridad que la siguen.
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
Ninguna de esas filas es constante entre despliegues, y la fila del relleno no es constante ni siquiera dentro de un mismo despliegue. Esa es toda la razón por la que una sola cifra publicada de sobrecarga decepciona.
Dos sedes pueden discrepar sobre el mismo túnel
El paquete protegido sigue teniendo que cruzar la ruta exterior, y la ruta exterior no es la misma en todas partes. Un enlace de acceso PPPoE lleva menos que un segmento Ethernet limpio. Una red móvil puede encogerse más, y un proveedor que tuneliza su propio tráfico añade otro encapsulado que nadie mencionó. Un túnel que funciona en un enlace y falla en otro está describiendo el segundo enlace, no el protocolo.
Las dos direcciones también pueden diferir. Una ruta asimétrica puede darle una subida que funciona y una bajada atascada, lo que se lee como un problema de aplicación hasta que mira los tamaños de paquete en lugar de la alcanzabilidad. Un ping pequeño que funciona demuestra muy poco sobre una respuesta de tamaño completo.
Mida en lugar de restar
Encuentre el datagrama más grande que sobrevive a la ruta. Luego compárelo con el valor que informa la interfaz:
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
Baje el tamaño del ping hasta que lleguen respuestas, y tome el mayor valor que funcione como presupuesto para esa ruta. La salida de xfrm le dice qué modo y qué algoritmos se negociaron, que es la entrada de cualquier cálculo honesto. La captura confirma si en el cable hay ESP o ESP encapsulado en UDP, lo que resuelve la cuestión del NAT sin adivinar.
Reserve también un valor para el plano de control. Los paquetes de saludo IKE tienen una estructura distinta de la de los paquetes de datos, así que un tamaño derivado de una captura de saludo no es una MTU del plano de datos.
Ponga el número donde corresponde
Para TCP a través de un túnel, un ajuste de MSS suele ser el control menos invasivo, porque reduce lo que envían los extremos sin cambiar el túnel mismo. Para un túnel basado en rutas, fije la MTU de la interfaz del túnel a propósito y documente por qué. Hacer las dos cosas a la vez y después medir no le da ninguna información sobre cuál ayudó.
Mantenga juntos en el ticket el modo negociado, la familia exterior, la condición de NAT y el síntoma reproducible. Un conjunto registrado de cuatro hechos supera a una constante recordada, y es la única versión de esto que sobrevive a la próxima actualización del cliente.