MTU или MSS? Што навистина поправа една промена на VPN

Пинговите поминуваат, големите преноси заглавуваат, а тунелот се пријавува како здрав. Некој ја намалува MTU на интерфејсот, друг ја ограничува MSS, и понекогаш проблемот исчезнува од причини што никој не ги запишува. Двата броја опишуваат различни објекти, па промената на погрешниот дава поправка што изгледа како среќа. Еве ја постапката: определете го слојот, применете го соодветното прилагодување и потоа тестирајте на нова врска.

Два броја, два објекти

MTU ѝ припаѓа на врска или интерфејс: тоа е најголемиот пакет што може да се предаде без да се подели. MSS му припаѓа на TCP: тоа е најголемото количество TCP-содржина што еден сегмент може да го носи, и ги исклучува и TCP- и IP-заглавието. На обична Ethernet-врска со IPv4, MTU од 1500 бајти дава познатата MSS од 1460 бајти. Овие броеви опишуваат различни слоеви и се разменуваат со различни механизми. Лесно е да се збунат бидејќи двете се мерат во бајти и двете се близу 1500.

Едното доаѓа како поставка на интерфејсот. Другото доаѓа како опција во сегмент SYN, договорена меѓу крајни точки што никогаш не го гледаат вашиот интерфејс.

Каде слетува надворешниот дополнителен товар

VPN го става внатрешниот пакет во друг, а надворешниот пакет мора да се вклопи во физичката патека. Заглавијата за инкапсулација, надворешното IP-заглавие, транспортното заглавие и секоја ознака за автентикација трошат бајти што внатрешниот пакет не може да ги користи. Оставете го тунелскиот интерфејс на 1500 и надворешниот пакет редовно го надминува она што патеката може да го носи. Кога е поставен битот 'не фрагментирај', рутерот го отфрла и треба да врати ICMP-грешка; ако таа грешка се филтрира, испраќачот никогаш не дознава.

Затоа дефектот изгледа селективен. Малите барања завршуваат, а сѐ што ќе наполни сегмент заглавува, бидејќи се отфрлаат само големите пакети. Тунел што пропушта пинг не е тунел што носи податоци.

Ограничување на MSS и каде важи

Ограничувањето на MSS ја препишува вредноста во сегментот SYN додека тој минува низ избрана точка, што прави двата краја да изберат помала содржина без ниту еден да знае зошто. На Linux тоа е цел во табелата mangle што се применува со експлицитно правило, и мора да ги погоди SYN-пакетите во насоката што ја сакате. Ограничете го на тунелскиот интерфејс и опсегот на адреси, бидејќи широкото правило го менува однесувањето на сообраќајот што никогаш не влегува во тунелот.

Ефектот е само на TCP. UDP-апликација, QUIC-сесија и секој протокол што гради свои датаграми остануваат недопрени.

Дијагностицирајте со фиксна патека

Држете една променлива одеднаш. Тестирајте со пакет чија големина ја избирате сами, и поставете го знаменцето 'не фрагментирај' за јадрото да го пријави резултатот наместо да го скрие.

Запишете каде почнува дефектот: внатре во тунелот, на тунелскиот интерфејс или на физичката патека по инкапсулацијата. Потоа сменете еден број и повторете го истиот тест, а не друг. Постојните врски ја задржуваат договорената MSS, па промената на политиката е видлива само на нова врска, и затоа кешираната страница не докажува ништо во ниту една насока. Ако еден голем пренос почне да работи, научивте за таа патека, а не за секој протокол на неа.

Што не поправа секоја промена

Намалувањето на MTU на интерфејсот не ја менува MSS на веќе воспоставена сесија. Ограничувањето на MSS не помага на UDP-тек и не ја поправа патеката каде ICMP-грешките се филтрираат само во една насока. Секоја промена поправа една класа проблеми, а останатите ги остава точно такви какви што биле.

Запишете кое прилагодување сте го примениле, каде и кој тест ја покажал разликата, инаку следниот инженер ќе ги примени двете и ќе ја загуби способноста да каже која била важна. Ако ограничувањето е вистинско и трајно, претпочитајте тунелска MTU што го одразува наместо ограничување што го сокрива. Ако мора да ограничувате, оставете го правилото ограничено и со коментар, бидејќи необјаснето mangle-правило по правило станува трајно.