MTU, nebo MSS? Co změna VPN skutečně opraví

Pingy procházejí, velké přenosy zamrzají a tunel se hlásí jako zdravý. Někdo sníží MTU rozhraní, jiný omezí MSS a problém občas zmizí z důvodů, které nikdo nezaznamená. Ta dvě čísla popisují různé objekty, takže změna toho nesprávného přinese opravu, která vypadá jako štěstí. Tady je postup: určete vrstvu, použijte odpovídající úpravu a poté testujte na novém spojení.

Dvě čísla, dva objekty

MTU patří lince nebo rozhraní: je to největší paket, který lze předat bez rozdělení. MSS patří TCP: je to největší množství TCP payloadu, které může segment nést, a nezahrnuje hlavičky TCP ani IP. Na běžné lince Ethernet s IPv4 dává MTU 1500 bajtů známé MSS 1460 bajtů. Tato čísla popisují různé vrstvy a vyměňují se různými mechanismy. Plést si je je snadné, protože obě se měří v bajtech a obě se pohybují kolem 1500.

Jedno přichází jako nastavení rozhraní. Druhé přichází jako volba uvnitř segmentu SYN, sjednaná mezi koncovými body, které vaše rozhraní nikdy nevidí.

Kam dopadá vnější režie

VPN vkládá vnitřní paket do jiného a vnější paket se musí vejít do fyzické cesty. Hlavičky zapouzdření, vnější IP hlavička, transportní hlavička a případná autentizační značka spotřebovávají bajty, které vnitřní paket nemůže použít. Ponecháte-li tunelové rozhraní na 1500, vnější paket pravidelně překročí to, co cesta unese. S nastaveným bitem 'nefragmentovat' jej směrovač zahodí a má poslat zpět chybu ICMP; pokud je tato chyba filtrována, odesílatel se to nikdy nedozví.

Proto porucha vypadá selektivně. Malé požadavky se dokončí a všechno, co naplní segment, se zasekne, protože se zahazují jen velké pakety. Tunel, který propustí ping, není tunel, který přenáší data.

Omezování MSS a kde platí

Omezování MSS přepisuje hodnotu v segmentu SYN, když prochází zvoleným bodem, takže oba konce zvolí menší payload, aniž by věděly proč. V Linuxu je to cíl tabulky mangle uplatněný explicitním pravidlem a musí zasáhnout pakety SYN ve směru, který zamýšlíte. Omezte ho na tunelové rozhraní a rozsah adres, protože široké pravidlo mění chování provozu, který do tunelu nikdy nevstoupí.

Účinek je pouze na TCP. UDP aplikace, relace QUIC a jakýkoli protokol, který si staví vlastní datagramy, tím nejsou dotčeny.

Diagnostika po pevné cestě

Držte vždy jednu proměnnou. Testujte paketem, jehož velikost si zvolíte, a nastavte příznak 'nefragmentovat', aby jádro výsledek ohlásilo, místo aby ho skrylo.

Zaznamenejte, kde porucha začíná: uvnitř tunelu, na tunelovém rozhraní, nebo na fyzické cestě po zapouzdření. Potom změňte jedno číslo a opakujte stejný test, ne jiný. Existující spojení si ponechávají MSS, který vyjednala, takže změna politiky je vidět jen na novém spojení, a proto uložená stránka nic nedokazuje ani v jednom směru. Pokud jeden velký upload začne fungovat, dozvěděli jste se o té cestě, a ne o každém protokolu na ní.

Co která změna neopraví

Snížení MTU rozhraní nezmění MSS již navázané relace. Omezení MSS nepomůže UDP toku a neopraví cestu, kde se chyby ICMP filtrují jen jedním směrem. Každá změna opraví jednu třídu problémů a ostatní ponechá přesně tak, jak byly.

Zapište, kterou úpravu jste použili, kde a který test ukázal rozdíl, protože jinak příští inženýr použije obě a ztratí schopnost říci, která měla význam. Pokud je omezení skutečné a trvalé, dejte přednost tunelovému MTU, které ho odráží, před omezením, které ho zakrývá. Pokud omezovat musíte, ponechte pravidlo omezené a okomentované, protože nevysvětlené pravidlo mangle se ve výchozím nastavení stává trvalým.