MTU o MSS? Què arregla realment un canvi de VPN

Els pings funcionen, les transferències grans es pengen i el túnel informa que està sa. Algú baixa l’MTU de la interfície, un altre ajusta l’MSS i, de tant en tant, el problema desapareix per motius que ningú no anota. Els dos números descriuen objectes diferents, així que canviar el número equivocat produeix una solució que sembla sort. Aquí teniu el procediment: identifiqueu la capa, apliqueu l’ajust corresponent i després proveu-ho en una connexió nova.

Dos números, dos objectes

L’MTU pertany a un enllaç o a una interfície: és el paquet més gran que es pot lliurar sense dividir-lo. L’MSS pertany a TCP: és la quantitat més gran de càrrega TCP que pot portar un segment, i exclou tant les capçaleres TCP com les IP. En un enllaç Ethernet corrent amb IPv4, un MTU de 1500 bytes dona l’MSS conegut de 1460 bytes. Aquests números descriuen capes diferents i s’intercanvien per mecanismes diferents. Confondre’ls és fàcil perquè tots dos es mesuren en bytes i tots dos se situen prop de 1500.

Un arriba com a paràmetre de la interfície. L’altre arriba com a opció dins d’un segment SYN, negociada entre extrems que mai no veuen la vostra interfície.

On acaba la sobrecàrrega exterior

Una VPN posa el paquet intern dins d’un altre, i el paquet exterior ha de cabre al camí físic. Les capçaleres d’encapsulament, la capçalera IP exterior, la capçalera de transport i qualsevol etiqueta d’autenticació consumeixen bytes que el paquet intern no pot utilitzar. Deixeu la interfície del túnel a 1500 i el paquet exterior superarà habitualment el que el camí pot transportar. Amb el bit 'no fragmentis' activat, l’encaminador el descarta i hauria d’enviar un error ICMP; si aquest error es filtra, l’emissor no ho sabrà mai.

Per això la fallada sembla selectiva. Les peticions petites es completen i qualsevol cosa que ompli un segment s’encalla, perquè només es descarten els paquets grans. Un túnel que passa un ping no és un túnel que transporta dades.

Ajustar l’MSS i on s’aplica

L’ajust de l’MSS reescriu el valor del segment SYN quan travessa un punt escollit, cosa que fa que tots dos extrems triïn una càrrega més petita sense saber per què. A Linux és un objectiu de la taula mangle aplicat per una regla explícita, i ha de colpir els paquets SYN en la direcció que voleu. Limiteu-lo a la interfície del túnel i al rang d’adreces, perquè una regla àmplia canvia el comportament del trànsit que mai no entra al túnel.

L’efecte és només per a TCP. Una aplicació UDP, una sessió QUIC i qualsevol protocol que construeixi els seus propis datagrames no es veuen afectats.

Diagnostiqueu amb un camí fix

Mantingueu una variable alhora. Proveu amb un paquet la mida del qual trieu vosaltres, i activeu el flag 'no fragmentis' perquè el nucli informi del resultat en lloc d’amagar-lo.

Anoteu on comença la fallada: dins del túnel, a la interfície del túnel o al camí físic després de l’encapsulament. Després canvieu un número i repetiu la mateixa prova, no una altra. Les connexions existents conserven l’MSS que han negociat, així que un canvi de política només es veu en una connexió nova, i per això una pàgina en memòria cau no demostra res en cap sentit. Si una càrrega gran comença a funcionar, heu après sobre aquell camí i no sobre cada protocol que hi passa.

Què no arregla cada canvi

Baixar l’MTU de la interfície no altera l’MSS d’una sessió ja establerta. Ajustar l’MSS no ajuda un flux UDP i no repara un camí on els errors ICMP es filtren en una sola direcció. Cada canvi arregla una classe de problema i deixa la resta exactament com era.

Anoteu quin ajust heu aplicat, on i quina prova ha mostrat la diferència, perquè si no el següent enginyer aplica tots dos i perd la capacitat de dir quin era el que importava. Si la restricció és real i permanent, preferiu un MTU de túnel que la reflecteixi abans que un ajust que l’amagui. Si heu d’ajustar, deixeu la regla limitada i comentada, ja que una regla mangle sense explicació esdevé permanent per defecte.