Ограничаване на MSS на VPN шлюз: какво поправя и какво не

Малките заявки работят, големите изтегляния висят, и някой предлага ограничаване на MSS. Това предложение е достатъчно често правилно, за да си заслужава опит в правилния ред, и достатъчно често грешно, за да пропилее един следобед, ако го приложите сляпо. Трите проверки по-долу отделят истински проблем с размера на TCP от проблем с UDP, от счупено откриване на path-MTU и от ограничаване, което никога не вижда ръкостискането, което трябва да пренапише.

Започнете с формата на повредата

Повредата в размера има подпис: връзката се установява, удостоверяването и малките отговори успяват, а после преносът виси за неопределено време, щом му потрябва сегмент с пълен размер. Страниците, които зареждат текст, но никога не довършват изображение, са същата повреда в по-малък мащаб. Ако изобщо нищо не се свързва, проблемът е по-рано по пътя и ограничаването няма да помогне. Ограничаването не може да поправи ръкостискане, което никога не е пристигнало.

Подписът съществува, защото ръкостискането е мястото, където се договаря размерът на сегмента. Всяка страна обявява максимален размер на сегмента като опция на TCP и изпращачите уважават обявеното от партньора. Ако пътят не може да пренесе толкова голям сегмент, повредата се появява по-късно, когато изпращачът най-накрая опита такъв.

Дръжте транспорта под око, докато четете този симптом. Ограничаването е пренаписване на опция на TCP, така че гласово или видео обаждане, което виси под същия тунел, не е проблем с MSS и няма да се подобри от него. Запишете транспорта, преди да пипате опция на TCP.

Оценете пътя, после го сравнете с тунела

Две числа имат значение и често се бъркат. path-MTU е най-големият пакет, който пътят ще пренесе без фрагментация, а обявеният MSS за IPv4 е тази стойност минус 40 байта заглавия на IP и TCP, или минус 60 за IPv6. Тунелната инкапсулация изяжда част от бюджета още преди вътрешният пакет да започне.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

Ping с бита „не фрагментирай“ ви казва дали пакет с този размер на полезния товар оцелява; променяйте размера, докато се провали, и сте намерили границата на пътя емпирично. Изходът на tracepath съобщава MTU, открит по маршрута, което е по-бързо, когато работи, и по-малко надеждно, когато междинен хоп филтрира сондите.

Сега извадете разходите на тунела. Външно IP заглавие, UDP заглавие и заглавие, специфично за тунела, излизат от едни и същи 1500 байта, така че използваемият вътрешен MTU върху типична Ethernet основа е по-нисък, отколкото физическата връзка подсказва. Ако изчисленият вътрешен MTU е под обявеното от партньорите ви, намерили сте истински кандидат за ограничаване, а не догадка. Ако изчислената стойност вече е над обявеното от партньорите, спрете тук и търсете другаде.

Поставете ограничаването там, където минава ръкостискането

Ограничаването работи, като пренаписва опцията MSS в пакетите SYN и SYN-ACK, докато пресичат шлюза. Ако правилото стои на интерфейс, който нито една посока никога не пресича, договарянето завършва непроменено и симптомът остава, затова разположението решава изхода повече от стойността.

Посоката е другата половина. Ограничаването на една посока оправя половината потоци и оставя останалите да се провалят по начин, който изглежда периодичен, затова го прилагайте в двете посоки на препращания трафик. Класическата форма в Linux за тунелен интерфейс е правило mangle, съвпадащо с пакети SYN:

iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Забележете какво всъщност прави --clamp-mss-to-pmtu: то извежда стойността от MTU на маршрута, което не винаги е истинският бюджет на полезния товар на тунела. При тунел на базата на маршрут, където вътрешният маршрут и външният път се различават, явна стойност, изчислена в предишната проверка, е по-предсказуема от автоматична.

Проверете с нова връзка и поддържайте обратната връзка жива

Установената връзка запазва MSS, който е договорила, така че тестването в същата сесия не доказва нищо. Отворете нова връзка след промяната и четете договорената стойност директно, вместо да я извеждате от пренос, който случайно завършва.

ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSS

Първата команда съобщава MSS на сокета заедно със състоянието му на задръстване, което е най-бързото потвърждение, че ограничаването е подействало. Втората потвърждава, че правилото, което мислите, че сте добавили, е правилото, което съществува, в таблицата, където е поставено.

После защитете механизма, който не сте поправили. Откриването на path-MTU зависи от достигащите до изпращача съобщения ICMP fragmentation-needed, така че защитна стена, която ги изхвърля, ще продължи да чупи големи преноси дори с правилно ограничаване. Разрешете тези съобщения за пътя на тунела или приемете, че ограничаването компенсира политика, която вие сте избрали.

Накрая устоите на изкушението да третирате ограничаването като копче за настройка. То ограничава размера на сегмента, което струва пропускателна способност по пътища, които никога не са се нуждаели от него. Приложено след трите проверки, то е целенасочен ремонт; приложено първо, то е промяна, която скрива първоначалната повреда и добавя втора променлива към всеки следващ тест. Тази размяна си заслужава да се направи умишлено, не по подразбиране.

Запишете path-MTU, който измерихте, разходите на тунела, които извадихте, правилото, което добавихте, и MSS, който видяхте след това. Четири числа превръщат следващия инцидент в справка, а не в разследване.