MTU ou MSS? Que arregla realmente un cambio de VPN

Os ping funcionan, as transferencias grandes colgan e o túnel declárase san. Alguén baixa a MTU da interface, outro axusta a MSS e, de cando en vez, o problema desaparece por motivos que ninguén anota. Os dous números describen obxectos distintos, así que cambiar o equivocado produce unha solución que parece sorte. Este é o procedemento: identifique a capa, aplique o axuste correspondente e logo probe nunha conexión nova.

Dous números, dous obxectos

A MTU pertence a un enlace ou a unha interface: é o paquete máis grande que se pode entregar sen dividilo. A MSS pertence a TCP: é a maior cantidade de carga TCP que pode levar un segmento, e exclúe tanto as cabeceiras TCP como as IP. Nun enlace Ethernet normal con IPv4, unha MTU de 1500 bytes dá a coñecida MSS de 1460 bytes. Esas cifras describen capas distintas e intercámbianse mediante mecanismos distintos. Confundilas é doado porque ambas se miden en bytes e ambas roldan 1500.

Unha chega como axuste da interface. A outra chega como opción dentro dun segmento SYN, negociada entre extremos que nunca ven a súa interface.

Onde acaba a sobrecarga exterior

Unha VPN mete o paquete interior dentro doutro, e o paquete exterior ten que caber na ruta física. As cabeceiras de encapsulación, a cabeceira IP exterior, a cabeceira de transporte e calquera etiqueta de autenticación consomen bytes que o paquete interior non pode usar. Deixe a interface do túnel en 1500 e o paquete exterior superará habitualmente o que a ruta pode transportar. Co bit 'non fragmentar' activado, o encamiñador descártao e debería devolver un erro ICMP; se ese erro se filtra, o emisor nunca se entera.

Por iso o fallo parece selectivo. As peticións pequenas compóñense e todo o que enche un segmento atasca, porque só se descartan os paquetes grandes. Un túnel que pasa un ping non é un túnel que transporta datos.

Axustar a MSS e onde se aplica

O axuste de MSS reescribe o valor no segmento SYN cando cruza un punto escollido, o que fai que ambos extremos elixan unha carga menor sen que ningún saiba por que. En Linux é un destino da táboa mangle que aplica unha regra explícita, e debe afectar os paquetes SYN na dirección que vostede quere. Limíteo á interface do túnel e ao rango de enderezos, porque unha regra ampla cambia o comportamento de tráfico que nunca entra no túnel.

O efecto é só para TCP. Unha aplicación UDP, unha sesión QUIC e calquera protocolo que constrúa os seus propios datagramas non se ven afectados.

Diagnostique cunha ruta fixa

Manteña unha variable á vez. Probe cun paquete cuxo tamaño elixa vostede, e active o indicador 'non fragmentar' para que o núcleo informe do resultado en lugar de ocultalo.

Anote onde comeza o fallo: dentro do túnel, na interface do túnel ou na ruta física despois da encapsulación. Logo cambie un número e repita a mesma proba, non outra. As conexións existentes conservan a MSS que negociaron, así que un cambio de política só se ve nunha conexión nova, e por iso unha páxina na caché non demostra nada en ningún sentido. Se unha carga grande comeza a funcionar, aprendeu sobre esa ruta e non sobre cada protocolo que pasa por ela.

Que non arregla cada cambio

Baixar a MTU da interface non altera a MSS dunha sesión xa establecida. Axustar a MSS non axuda a un fluxo UDP e non repara unha ruta na que os erros ICMP se filtran nunha soa dirección. Cada cambio arregla unha clase de problema e deixa o resto exactamente como estaba.

Anote que axuste aplicou, onde e que proba mostrou a diferenza, porque se non o seguinte enxeñeiro aplica ambos e perde a capacidade de dicir cal importaba. Se a restrición é real e permanente, prefira unha MTU de túnel que a reflicta antes que un axuste que a oculte. Se ten que axustar, deixe a regra acoutada e comentada, xa que unha regra mangle sen explicación vólvese permanente por defecto.