IPIP dentro de WireGuard: los 20 bytes extra que nadie presupuestó

Los pings pequeños cruzan el túnel todo el día, llega el banner SSH y luego la sesión se congela en el momento en que empieza una transferencia de archivos. Ese patrón apunta a un presupuesto de bytes contado en la capa equivocada, donde el túnel exterior se dimensionó para su propio sobrecoste y nadie restó el interior. Un paquete IPIP anidado es solo otro paquete IP para WireGuard, y por eso mismo consume bytes que nunca reservó. La corrección es aritmética, y cabe en tres comandos y una tabla.

El síntoma que lo delata

Los problemas de fragmentación se anuncian por el tamaño, nunca por las direcciones. Su par responde a un ping de 56 bytes durante una hora y luego calla a 1400 bytes mientras el túnel sigue levantado y ninguna ruta ha cambiado. El saludo cabe, la primera ventana TCP completa no, y la transferencia se atasca segundos después de haber parecido sana.

Mida el techo antes de editar nada, porque un techo sin medir es uno que perseguirá dos veces. Envíe una sonda por debajo del tamaño sospechoso con el bit do-not-fragment activado, ping -M do -s 1000 10.9.0.2, y repítala después con un tamaño que ya sabe que es demasiado grande. Cuando el vuelco sigue el tamaño de la carga útil mientras el destino no cambia, el enrutamiento hace su trabajo y falta una cabecera en el presupuesto.

Cuente cada cabecera una vez, en la capa correcta

Parta del MTU más pequeño del camino y no de la interfaz del túnel, porque el muro está por encima de ambos extremos. WireGuard gasta 60 bytes en un transporte exterior IPv4: 20 para IP, 8 para UDP y 32 para su propia cabecera, y 80 bytes cuando ese transporte es IPv6. Un wg0 de 1420 bytes guarda 20 bytes de margen bajo los 1440 que un camino de 1500 bytes puede entregar de verdad, y por eso la cifra copiada de una wiki sigue encajando aquí. Dibuje toda la pila en el diagrama, porque quien cambie el MTU después elegirá si no un número redondo nuevo y heredará su error.

La quinta fila es donde fallan los presupuestos, porque los 1400 bytes que lleva una interfaz anidada ya incluyen los 40 bytes de cabeceras del paquete original. Solo 1360 de esos bytes llegan al proceso que lee el archivo. Trate 1400 como carga útil de la aplicación, como le invita a hacer cualquier diagrama sin esa columna, y el dispositivo interior acaba 40 bytes demasiado generoso contra un muro que no se ha movido.

Fije los dos MTU por separado

El portador y el dispositivo anidado son objetos separados, así que cada uno necesita su propio valor. Aplíquelos en este orden, porque el dispositivo anidado no hereda nada del portador:

ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400

La regla que vale la pena memorizar: MTU interior = MTU exterior - 20 cuando el paquete que lleva el túnel IPIP es IPv4, y - 40 en cuanto cualquier lado del paquete interior es IPv6, porque la cabecera anidada crece de 20 bytes a 40. Nada más pertenece a esa resta. El sobrecoste de WireGuard ya se gastó cuando eligió 1420, y cobrarlo dos veces produce un túnel que funciona perfectamente y se queda lento mientras nadie lo mida. Un despliegue en el que ambos dispositivos llevan un 1400 redondo es la huella exacta de ese error.

IPv6 en cualquiera de los lados del paquete anidado invalida cada cifra anterior, así que recalcule en lugar de copiar un número de un sitio parecido. Las cabeceras restadas son de 40 bytes cada una en cuanto IPv6 aparece en el camino exterior o en el datagrama original, y la cifra de carga útil baja exactamente otro tanto.

La regla de cortafuegos que probablemente no necesita

Entre dos pares de WireGuard lo único que hay en el cable es UDP, así que una regla de entrada para el protocolo 4, el número que RFC 2003 asigna a la encapsulación IPv4-dentro-de-IPv4, ni crea el camino anidado ni lo mantiene vivo. La cabecera IPIP vive dentro de la carga útil cifrada, donde ningún cortafuegos de borde la ve. Abrir el protocolo 4 de todos modos no compra nada más allá de una vía permitida más hacia el host.

La política que menciona las fuentes y destinos del paquete original pertenece después de la desencapsulación, en las interfaces del túnel y en la tabla de enrutamiento. Póngala allí y la regla de borde puede quedarse cerrada.

Qué valida realmente WireGuard

AllowedIPs juzga el origen del paquete que WireGuard transporta, y lo que transporta es el paquete encapsulado en IPIP. Un origen IPIP permitido se acepta incluso cuando la cabecera interior nombra un host al que preferiría no enrutar. El origen original, por tanto, no es lo que el par comprobó por usted, y ese par interior de direcciones necesita su propia aplicación después de la desencapsulación.

El envoltorio aporta estructura de enrutamiento, no una segunda capa de criptografía. Llamar a IPIP protección extra dentro de WireGuard describe un diseño distinto.

Verifique con una escalera, no con un solo ping

Sondee tamaños que rodeen la frontera que calculó y luego confirme qué cree el núcleo sobre ambos dispositivos. Con 1360 bytes de carga útil más 40 bytes de cabeceras que hacen 1400, el primer eco de abajo cabe y el segundo se sitúa un byte más allá del techo:

ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0

Un paso limpio por debajo del techo y un fallo en el primer tamaño por encima significan que la aritmética se sostiene de extremo a extremo. Después vuelva a ejecutar la transferencia que originalmente se atascó, porque una sonda sintética demuestra el presupuesto y no dice nada sobre los tamaños de escritura del remitente. Si el camino anidado sigue rompiéndose con un tamaño que usted demostró que cabe, inspeccione la desencapsulación y las rutas del extremo lejano antes de recortar diez bytes más del MTU.