Windows L2TP відкриває лише частину сайтів: очистіть біт DF на pfSense

Ноутбук підключається, інтранет відкривається, а кілька публічних сайтів зависають. Автентифікація й маршрутизація явно працюють, тому поясненням залишається розмір пакета. У тунелі L2TP/IPsec доступний MTU менший за той, який адаптер ще оголошує, і клієнт продовжує надсилати пакети повного розміру з увімкненим бітом «не фрагментувати». Шлюзу pfSense можна наказати очистити цей біт, і це найшвидший спосіб підтвердити діагноз перед правильним виправленням.

Почніть зі сторінок, які не відкриваються

Перш ніж торкатися будь-якого налаштування, запишіть, які адресати не працюють, а які працюють. Рукостискання, що залишаються нижче межі тунелю, завершуються нормально, а передавання, яким потрібен сегмент повного розміру, зупиняються на півдорозі. Цей поділ є підписом проблеми розміру, а не фільтра, бо заблокований адресат відмовляє під час встановлення з'єднання, а не посеред сторінки. Обидва спостереження нічого не коштують і одразу звужують пошук.

Перевірте пінгом, який установлює біт і керує розміром корисного навантаження. Найбільше навантаження, що проходить, повідомляє реальний MTU шляху, а оголошене значення адаптера показує, наскільки вони далекі.

Запишіть обидва числа. Виправлення залежить від того, яке хибне, і саме пару згодом підтвердить запис.

Що робить біт DF на виході

Причина розбіжності чисел — інкапсуляція. IPsec додає ESP, L2TP додає ще один заголовок, тому тунель несе менше корисного навантаження, ніж фізичний канал. Windows і далі повідомляє 1500 байтів на адаптері й ставить «не фрагментувати» на те, що надсилає. Коли такий пакет не вміщається, правильна відповідь шлюзу — повідомлення ICMP із проханням до відправника зменшитися. Тому тунель, що пропускає малі пінги, все одно може провалити завантаження файлу.

Це повідомлення часто так і не приходить. Якийсь вузол може фільтрувати ICMP, або ніщо його не створює, і відправник повторює той самий розмір, доки передавання не здасться.

Тиша тут — звичайний прояв, тому симптом читається як вибіркове блокування. Ніщо в журналі клієнта не фіксує відсутнє повідомлення ICMP.

Опція pfSense і чого вона не робить

Опція розташована на сторінці Система, Додатково, Брандмауер і NAT із написом «Очищати недійсні біти DF замість відкидання пакетів». Замість того щоб відкидати завеликий пакет із прапорцем, фільтр знімає прапорець і дозволяє пакету ділитися далі. Пакет вважається недійсним, коли не може пройти вихідний інтерфейс одним шматком.

Опція відновлює зв'язність, не торкаючись клієнта, тому вона популярна. Це й обхідний шлях: фрагментація коштує процесорного часу й робить кожен втрачений фрагмент дорожчим.

Вона стосується лише пересиланого трафіку, а не трафіку, який створює сам брандмауер. Та сама сторінка пропонує «Вимкнути очищення брандмауера», що повністю вимикає нормалізацію, і це значно ширша зміна, ніж потрібно цій проблемі.

Вужче виправлення, що зберігає TCP нефрагментованим

Майже всі застряглі потоки — TCP, а TCP може узгодити менший сегмент замість того, щоб покладатися на фрагментацію. Обмеження MSS на інтерфейсі тунелю переписує оголошене значення під час рукостискання, тож кожна сторона надсилає те, що справді вміщається. Шлях тоді поводиться передбачувано, і жоден пакет не потрібно ділити.

Це залишає UDP виявленню або опції DF. Коли збійні сайти — звичайні веб-сторінки, обмеження і є бажаною зміною.

Клієнт може повідомити власний MTU адаптера через netsh interface ipv4 show subinterfaces. Порівняйте це число з тим, що сервер вважає узгодженим, бо вони не завжди збігаються. Саме це значення операційна система реально використає, хоч би що повідомили переговори.

Підтвердьте записом, потім скиньте стан

Перед рішенням зробіть запис з обох боків: один слід там, де йде тунель, і другий там, де працює інтерфейс WAN. Пакети, що виходять повного розміру без ICMP, який повертається, вказують на обмеження як на правильний рівень. Відповіді, що приходять і потім гинуть на зворотному шляху, вказують натомість на MTU тунелю.

Очистьте таблицю станів перед повторною спробою, бо наявні потоки зберігають старі розміри сегментів. Потім завантажте сторінку, яка не відкрилася, і читайте подання станів для двостороннього трафіку, а не однобічні лічильники. Якщо вона все ще зависає, зробіть запис знову, а не пробуйте інший прапорець.