Por que unha VPN colga nas transferencias grandes e non nas pequenas

Unha páxina carga, un ping responde e unha copia de ficheiro colga sempre no mesmo punto. Ese patrón apunta ao tamaño do paquete, non ao ancho de banda nin ás credenciais. A encapsulación engade bytes a cada paquete, así que unha carga útil que cabía na ruta orixinal pode superar o límite unha vez que pasa por un túnel. Nestas conversas chámase MTU a tres números distintos, e confundilos leva a un axuste que arranxa unha aplicación e rompe outra.

Tres números que a xente chama MTU

A MTU da interface é o límite configurado para un paquete nesa ligazón. A MTU da ruta é o límite máis pequeno ao longo do camiño, e descóbrese en lugar de configurarse. A MSS de TCP é o tamaño de carga útil que un par anuncia que pode recibir, e derívase dos outros dous en vez de ser un límite físico aparte.

Un túnel ten unha visión interior e outra exterior. O paquete exterior transporta o encapsulado máis as cabeceiras que o protocolo necesita, así que o tamaño interior utilizábel é menor do que permite a ruta exterior. A ruta ata o servidor VPN tamén é distinta da ruta do servidor ata o destino.

O descubrimento da MTU de ruta permite a un emisor coñecer o tamaño que funciona, pero depende de que chegue a realimentación. Cando un dispositivo intermedio filtra as mensaxes ICMP pertinentes, o emisor segue transmitindo paquetes que nunca se completan, e ese é o burato negro clásico. O síntoma é inconfundíbel cando o coñeces: o handshake ten éxito, a primeira carga de tamaño completo desaparece e a conexión acaba reiniciándose ou colgándose. Nada no rexistro da aplicación parece un problema de rede.

Sondar a ruta cunha carga que controles

Unha sonda é unha proba sobre unha ruta e un tamaño, non un axuste recomendado. Usa un host que responda e varía só o tamaño da carga.

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

O primeiro comando envía unha sonda de Linux coa fragmentación desactivada e unha carga de 1372 bytes, e o segundo fai o mesmo en Windows, onde a carga se fixa con -l. Unha resposta significa que ese tamaño sobreviviu á ruta. Unha mensaxe de fragmentación necesaria é informativa, mentres que un tempo de espera é ambiguo porque o host ou un dispositivo intermedio poden simplemente descartar ICMP.

Baixa o tamaño en uns poucos pasos en lugar de facer unha busca binaria ata o byte. Intentas establecer se existe un teito de tamaño, non publicar un número para cada rede. O número que atopes aplícase a esta ruta, este protocolo e esta familia de enderezos.

IPv4 e IPv6 fragmentan de forma distinta, así que o resultado dunha familia non di nada sobre a outra. Proba a familia que a aplicación usa de verdade.

O axuste de MSS só axuda a TCP

En TCP a carga útil efectiva négociase durante o handshake, e un router da ruta pode reescribir ese valor á baixa para que ambos extremos envíen segmentos máis pequenos. Iso é o que fai o axuste de MSS, e funciona sen tocar o 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

A primeira regra axusta a MSS anunciada á MTU da ruta para os handshakes TCP reenviados, e a segunda mostra a MTU propia da interface do túnel para que a compares co que permite a ruta. O axuste é a reparación menos invasiva para unha aplicación TCP que colga tras o handshake.

Para UDP non fai nada. Un cliente de voz ou de xogos que envía datagramas grandes ignorará por completo un axuste de MSS, porque non hai handshake que reescribir. Se a aplicación que falla é UDP, mira no seu lugar as opcións de tamaño de paquete do propio cliente. Os dous protocolos fallan de forma distinta e repáranse con ferramentas distintas, por iso o protocolo pertence á primeira frase do ticket.

OpenVPN expón opcións como tun-mtu, mssfix e axustes relacionados coa fragmentación, e o seu comportamento depende da versión e de se o canal de datos é AEAD. Le o manual da versión en uso e cambia unha opción cada vez.

Cambia un só axuste admitido e repite as dúas probas

Conserva o perfil orixinal, cambia un único valor admitido e repite tanto a petición pequena que funcionaba como a transferencia grande que fallaba. Se só cambia a grande, ías detrás do tamaño. Se cambian as dúas, algo máis se moveu con ela.

Un valor máis baixo pode reducir o síntoma á vez que engade sobrecarga, así que o número máis pequeno posíbel non é o obxectivo. O obxectivo é un tamaño que a ruta leve de forma fiable co mínimo desperdicio. Anota o valor, a ruta e a versión do cliente no ticket, porque aplicar o mesmo número noutro sitio é unha conxectura.

Se o mesmo perfil funciona desde outra rede de confianza, mantén esa diferenza no diagnóstico en lugar de declarar o cliente arranxado. A variable que cambiou é a ruta, e a ruta é o que mediu a sonda.