OpenVPN mssfix: por que un cliente se atasca en transferencias grandes

Un só portátil atáscase nas subidas a través do túnel mentres todos os demais dispositivos do mesmo servidor seguen funcionando. Ese patrón apunta a unha ruta, non á configuración do servidor, e é a entrada habitual á cuestión de mssfix. A opción pode axudar, pero só para as conexións TCP que realmente reescribe. Coñecer o seu alcance evita que cambie un servidor que funciona para rescatar un cliente.

Que reescribe a opción

mssfix edita o tamaño máximo de segmento anunciado nos handshakes TCP que atravesan o túnel, de xeito que o lado emisor escolle segmentos que caben no orzamento encapsulado. Actúa sobre o handshake, o que significa que unha conexión aberta antes do cambio conserva o valor que negociou.

Non reduce os datagramas UDP nin fixa a MTU do túnel. Dous problemas distintos producen o mesmo síntoma: un emisor TCP que ignora o límite da ruta e unha ruta que descarta en silencio paquetes grandes de calquera tamaño. mssfix aborda o primeiro e non fai nada polo segundo.

Esa distinción explica os experimentos decepcionantes. Fixar un valor menor nunha ruta con burato negro cambia o tamaño do segmento, pero non a caída que segue, así que a transferencia falla noutro punto.

O alcance é TCP dentro do túnel

Só se reescribe o tráfico TCP. Unha sesión QUIC, un xogo ou unha aplicación que envía datagramas UDP grandes conservará os seus propios tamaños de paquete, e se esas son as transferencias que se atascan, a solución pertence máis ben á MTU do túnel ou da ruta. Lea que protocolo usa a transferencia que falla antes de acudir a unha opción TCP, porque a capa equivocada ten a súa propia solución.

A dirección tamén importa. Un axuste do cliente afecta o tráfico que ese cliente envía ao túnel, mentres que o servidor cobre os fluxos que reenvía cara aos clientes. Se só se atascan as descargas entrantes, o valor do lado do cliente non é toda a historia.

O número e a palabra clave non son portables

A versión comunitaria de OpenVPN 2.6 acepta unha palabra clave opcional despois do valor. Con mtu, o número describe o tamaño do paquete exterior, incluídas as cabeceiras IP e UDP; sen ela, o argumento segue outra convención contable. Por iso, unha liña copiada entre versións non describe o mesmo orzamento de paquetes. Consulte a páxina do manual que acompaña a compilación que realmente executa, en lugar dun titorial para outra versión.

A sintaxe ten este aspecto:

mssfix 1400 mtu

Trate 1400 como un marcador de posición, non como unha recomendación para a súa ruta. Deduza o valor da ruta medida e da encapsulación que realmente se usa, e lembre que os clientes con versións antigas ou outras implementacións poden rexeitar ou reinterpretar a palabra clave.

Confírmeo primeiro no único cliente

Mida a ruta desde a máquina que falla antes de cambiar nada. Unha carga útil que a ruta poida transportar sen fragmentación é o número que busca:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

A primeira proba cabe nun paquete de 1500 bytes unha vez engadidos os 28 bytes de cabeceiras. Se falla cun erro de fragmentación e a máis pequena ten éxito, o tamaño utilizable está nalgún punto entre ambas, e a sobrecarga do túnel réstase por arriba.

Despois repita a transferencia que se atascou, nunha conexión nova, e compare. Se o cliente único mellora mentres os demais quedan intactos, atopou o alcance do problema. Se se atascan todos os clientes, o valor do lado do servidor é o que hai que revisar. Ningún dos dous resultados xustifica un cambio en hardware que nunca estivo na ruta que falla.