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 туннеля.

Очистите таблицу состояний перед повторной попыткой, потому что существующие потоки сохраняют старые размеры сегментов. Затем загрузите страницу, которая не открылась, и читайте представление состояний для двустороннего трафика, а не односторонние счётчики. Если она всё ещё зависает, сделайте запись снова, а не пробуйте ещё один флажок.