OpenVPN mssfix: почему один клиент зависает на больших передачах

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

Что переписывает опция

mssfix редактирует максимальный размер сегмента, объявляемый в TCP-рукопожатиях, проходящих через туннель, чтобы отправляющая сторона выбирала сегменты, укладывающиеся в инкапсулированный бюджет. Он действует на рукопожатие, а значит, соединение, открытое до изменения, сохраняет согласованное значение.

Он не уменьшает UDP-датаграммы и не задаёт MTU туннеля. Две разные проблемы дают одинаковый симптом: TCP-отправитель, игнорирующий ограничение пути, и путь, который молча отбрасывает крупные пакеты любого размера. mssfix решает первую и ничего не делает для второй.

Это различие объясняет разочаровывающие эксперименты. Установка меньшего значения на пути с чёрной дырой меняет размер сегмента, но не последующее отбрасывание, поэтому передача срывается в другом месте.

Охват — TCP внутри туннеля

Переписывается только трафик TCP. Сеанс QUIC, игра или приложение, отправляющее крупные UDP-датаграммы, сохранит собственные размеры пакетов, и если именно эти передачи зависают, исправление относится скорее к MTU туннеля или пути. Прочитайте, какой протокол использует сбойная передача, прежде чем браться за опцию TCP, потому что у неправильного уровня своё исправление.

Направление тоже важно. Настройка клиента влияет на трафик, который этот клиент отправляет в туннель, тогда как сервер охватывает потоки, которые он пересылает клиентам. Если зависают только входящие загрузки, значение на стороне клиента — не вся история.

Число и ключевое слово не переносимы

Общественная версия OpenVPN 2.6 принимает необязательное ключевое слово после значения. С mtu число описывает размер внешнего пакета, включая заголовки IP и UDP; без него аргумент следует иной учётной конвенции. Поэтому строка, скопированная между версиями, не описывает тот же бюджет пакета. Проверьте страницу руководства, поставляемую со сборкой, которую вы действительно запускаете, а не руководство для другого выпуска.

Синтаксис выглядит так:

mssfix 1400 mtu

Считайте 1400 заполнителем, а не рекомендацией для вашего пути. Выводите значение из измеренного пути и фактически используемой инкапсуляции и помните, что клиенты на старых версиях или в других реализациях могут отвергнуть или истолковать ключевое слово иначе.

Сначала подтвердите на одном клиенте

Измерьте путь с проблемной машины, прежде чем что-либо менять. Полезная нагрузка, которую путь способен провести без фрагментации, — это искомое число:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

Первая проверка укладывается в пакет 1500 байт, когда добавляются 28 байт заголовков. Если она завершается ошибкой фрагментации, а меньшая проходит, пригодный размер находится где-то между ними, а накладные расходы туннеля вычитаются сверху.

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