Por qué una VPN se atasca en transferencias grandes y no en las pequeñas

Una página carga, un ping responde y una copia de archivo se cuelga siempre en el mismo punto. Ese patrón apunta al tamaño de paquete, no al ancho de banda ni a las credenciales. La encapsulación añade bytes a cada paquete, así que una carga útil que cabía en la ruta original puede superar el límite una vez que pasa por un túnel. En estas conversaciones se llama MTU a tres números distintos, y confundirlos lleva a un ajuste que arregla una aplicación y rompe otra.

Tres números que la gente llama MTU

La MTU de la interfaz es el límite configurado para un paquete en ese enlace. La MTU de la ruta es el límite más pequeño a lo largo del camino, y se descubre en lugar de configurarse. La MSS de TCP es el tamaño de carga útil que un par anuncia que puede recibir, y se deriva de los otros dos en lugar de ser un límite físico aparte.

Un túnel tiene una vista interior y otra exterior. El paquete exterior transporta el encapsulado más las cabeceras que el protocolo necesita, así que el tamaño interior utilizable es menor que lo que permite la ruta exterior. La ruta hasta el servidor VPN también es distinta de la ruta del servidor hasta el destino.

El descubrimiento de la MTU de ruta permite a un emisor conocer el tamaño que funciona, pero depende de que llegue la realimentación. Cuando un dispositivo intermedio filtra los mensajes ICMP pertinentes, el emisor sigue transmitiendo paquetes que nunca se completan, y ese es el agujero negro clásico. El síntoma es inconfundible cuando lo conoces: el handshake tiene éxito, la primera carga de tamaño completo desaparece y la conexión acaba reiniciándose o colgándose. Nada en el registro de la aplicación parece un problema de red.

Sondea la ruta con una carga que controles

Una sonda es una prueba sobre una ruta y un tamaño, no un ajuste recomendado. Usa un host que responda y varía solo el tamaño de la carga.

ping -M do -s 1372 -c 2 203.0.113.20
ping -4 -f -l 1372 vpn.example

El primer comando envía una sonda de Linux con la fragmentación desactivada y una carga de 1372 bytes, y el segundo hace lo mismo en Windows, donde la carga se fija con -l. Una respuesta significa que ese tamaño sobrevivió a la ruta. Un mensaje de fragmentación necesaria es informativo, mientras que un tiempo de espera es ambiguo porque el host o un dispositivo intermedio pueden simplemente descartar ICMP.

Baja el tamaño en unos pocos pasos en lugar de hacer una búsqueda binaria hasta el byte. Intentas establecer si existe un techo de tamaño, no publicar un número para cada red. El número que encuentres se aplica a esta ruta, este protocolo y esta familia de direcciones.

IPv4 e IPv6 fragmentan de forma distinta, así que el resultado de una familia no dice nada sobre la otra. Prueba la familia que la aplicación usa realmente.

El ajuste de MSS solo ayuda a TCP

En TCP, la carga útil efectiva se negocia durante el handshake, y un router de la ruta puede reescribir ese valor a la baja para que ambos extremos envíen segmentos más pequeños. Eso es lo que hace el ajuste de MSS, y funciona sin tocar el cliente en absoluto.

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip link show tun0

La primera regla ajusta la MSS anunciada a la MTU de la ruta para los handshakes TCP reenviados, y la segunda muestra la MTU propia de la interfaz del túnel para que la compares con lo que permite la ruta. El ajuste es la reparación menos invasiva para una aplicación TCP que se cuelga tras el handshake.

Para UDP no hace nada. Un cliente de voz o de juegos que envíe datagramas grandes ignorará por completo un ajuste de MSS, porque no hay handshake que reescribir. Si la aplicación que falla es UDP, mira en cambio las opciones de tamaño de paquete del propio cliente. Los dos protocolos fallan de forma distinta y se reparan con herramientas distintas, por eso el protocolo pertenece a la primera frase del ticket.

OpenVPN expone opciones como tun-mtu, mssfix y ajustes relacionados con la fragmentación, y su comportamiento depende de la versión y de si el canal de datos es AEAD. Lee el manual de la versión en uso y cambia una opción cada vez.

Cambia un solo ajuste admitido y repite las dos pruebas

Conserva el perfil original, cambia un único valor admitido y repite tanto la petición pequeña que funcionaba como la transferencia grande que fallaba. Si solo cambia la grande, ibas detrás del tamaño. Si cambian las dos, algo más se movió con ella.

Un valor más bajo puede reducir el síntoma al tiempo que añade sobrecarga, así que el número más pequeño posible no es el objetivo. El objetivo es un tamaño que la ruta lleve de forma fiable con el mínimo desperdicio. Anota el valor, la ruta y la versión del cliente en el ticket, porque aplicar el mismo número en otro sitio es una conjetura.

Si el mismo perfil funciona desde otra red de confianza, mantén esa diferencia en el diagnóstico en lugar de declarar arreglado el cliente. La variable que cambió es la ruta, y la ruta es lo que midió la sonda.