Windows L2TP зарежда част от сайтовете: изчистете DF бита на pfSense

Лаптопът се свързва, вътрешната мрежа се зарежда, а няколко публични сайта забиват. Удостоверяването и маршрутизирането очевидно работят, което оставя размера на пакета като обяснение. В тунел L2TP/IPsec използваемият MTU е по-малък от този, който адаптерът още обявява, и клиентът продължава да изпраща пакети с пълен размер с установен бит „не фрагментирай“. На pfSense шлюз може да се нареди да изчисти този бит и това е най-бързият начин да потвърдите диагнозата, преди да я поправите както трябва.

Започнете със страниците, които се провалят

Отбележете кои дестинации се провалят и кои успяват, преди да пипате каквато и да е настройка. Ръкостисканията, които остават под лимита на тунела, завършват нормално, докато трансферите, нуждаещи се от сегмент с пълен размер, засядат по средата. Това разделение е подписът на проблем с размера, а не на филтър, защото блокирана дестинация се проваля при установяване на връзката, а не по средата на страницата. И двете наблюдения не струват нищо и веднага стесняват търсенето.

Проверете с ping, който задава бита и контролира размера на полезния товар. Най-големият товар, който оцелее, ви казва реалния MTU на пътя, а обявената стойност на адаптера показва колко далеч са двете.

Запишете и двете числа. Поправката зависи от това кое е грешно, а двойката е това, което заснемането по-късно потвърждава.

Какво прави DF битът на изхода

Инкапсулацията е причината числата да се различават. IPsec добавя ESP, L2TP добавя още един заглавен блок и затова тунелът носи по-малко полезен товар от физическата връзка. Windows все още съобщава 1500 байта на адаптера и задава „не фрагментирай“ върху това, което изпраща. Когато такъв пакет не се побира, правилният отговор от шлюза е ICMP съобщение, което моли подателя да се свие. Затова тунел, който пропуска малки ping-ове, все още може да провали изтегляне на файл.

Това съобщение често така и не пристига. Някой хоп може да филтрира ICMP или нищо не го генерира, и подателят повтаря същия размер, докато трансферът се откаже.

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

Опцията на pfSense и какво не прави

Опцията се намира на страницата „Система, Разширени, Защитна стена и NAT“ с етикет „Изчисти невалидните DF битове вместо да отхвърляш пакетите“. Вместо да изхвърля прекалено голям пакет, носещ флага, филтърът премахва флага и позволява пакетът да бъде разделен по-надолу. Пакетът се брои за невалиден, когато не може да пресече изходящия интерфейс на едно парче.

Опцията възстановява свързаността, без да пипа клиента, затова е популярна. Тя е и заобиколно решение: фрагментацията струва CPU и прави всеки изгубен фрагмент по-скъп.

Прилага се само за препратен трафик, не за трафик, който самата защитна стена създава. Същата страница предлага „Изключи почистването на защитната стена“, което изключва нормализацията напълно, а това е много по-широка промяна, отколкото трябва на този проблем.

По-тясна поправка, която оставя TCP нефрагментиран

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

Това оставя UDP на откриването или на DF опцията. Когато провалящите се сайтове са обикновени уеб страници, ограничаването е промяната, на която да се даде предимство.

Клиентът може да съобщи собствения MTU на адаптера чрез netsh interface ipv4 show subinterfaces. Сравнете това число с това, което сървърът смята, че е договорил, защото двете не винаги съвпадат. Тази стойност е тази, която операционната система действително ще използва, каквото и да е съобщило договарянето.

Потвърдете със заснемане, после нулирайте състоянието

Заснемете от двете страни, преди да решите: един запис там, където минава тунелът, и друг там, където работи WAN интерфейсът. Пакетите, които излизат с пълен размер без връщащ се ICMP, сочат ограничаването като правилния слой. Отговорите, които пристигат и после умират на обратния път, сочат вместо това MTU на тунела.

Изчистете таблицата на състоянията, преди да опитате отново, защото съществуващите потоци пазят старите си размери на сегмента. После заредете страницата, която се провали, и прочетете изгледа на състоянията за двупосочен трафик, а не едностранни броячи. Ако все още забива, заснемете отново, вместо да пробвате друга отметка.