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 правило по правилу постаје трајно.