Маленький ответ проходит, большой зависает: как проверить Path MTU

После подключения туннеля страница состояния открывается, а загрузка отчёта останавливается. DNS отвечает, TCP соединяется, небольшие HTTP-ответы приходят. Увеличение общего таймаута лишь заставляет дольше ждать. В этой ситуации стоит проверить допустимый размер IP-пакета по пути: туннель добавляет заголовки, а полезному пакету остаётся меньше места.

Path MTU — наименьший размер пакета, который проходит весь путь без необходимости фрагментации на соответствующем участке. Для TCP отправитель старается подобрать подходящий размер. Если сообщения о слишком большом пакете теряются, соединение может установиться, а передача данных — застрять.

Подтвердите зависимость от размера

curl --connect-timeout 5 --max-time 20 -o /dev/null https://files.example/small.txt
curl --connect-timeout 5 --max-time 20 -o /dev/null https://files.example/report.bin
tracepath -n files.example

Используйте подготовленные файлы одного сервиса и разрешённый объём трафика. Разница между маленьким и большим объектом даёт направление поиска, но ещё не доказывает PMTU: обработка отчёта на сервере тоже может быть медленной. Лучше брать уже готовый статический файл, чтобы не смешивать генерацию данных и передачу.

tracepath отправляет UDP-пробы и пытается обнаружить MTU пути. Ищите изменение pmtu и участок, после которого перестают приходить ответы. Отсутствие ответов от промежуточного узла не означает, что тот перестал пересылать обычный трафик: он может фильтровать диагностические сообщения. Успешная короткая трассировка тоже не измеряет производительность загрузки.

Сопоставьте результат с направлением передачи

ip link show
ip route get 192.0.2.80
tracepath -4 -n 192.0.2.80

Выясните, какой интерфейс действительно используется и какое MTU у туннеля. Проверяйте направление, в котором передаются большие данные. Успех запроса от клиента к серверу не исключает проблемы обратного пути: ответ идёт обратно, и именно сервер выбирает размер исходящих пакетов.

Предположим, обычный интерфейс допускает 1500 байт, а туннель сообщает меньшее значение. Это ожидаемо при инкапсуляции. Проблема возникает, если отправитель продолжает передавать слишком большие пакеты и не получает пригодной обратной связи. Размер конкретного туннеля нужно брать из его конфигурации, а не копировать распространённое число из чужой инструкции.

Передайте сетевой команде адреса концов, размеры интерфейсов, наблюдаемое PMTU и сценарий воспроизведения. Важно проверить прохождение ICMP-сообщений, необходимых для определения размера, а не просто разрешить ping. Для IPv6 сообщения Packet Too Big особенно существенны: маршрутизаторы не фрагментируют пакеты, как это возможно в IPv4.

Меняйте MTU осмысленно

Случайное уменьшение MTU на всех серверах может снять симптом и создать труднообъяснимую постоянную настройку. Исправление должно соответствовать реальной инкапсуляции и политике сети. На согласованном стенде сравните передачу до и после изменения, затем повторите тест большого файла несколько раз.

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

Развивайте навык диагностики по наблюдаемому поведению. Курс Linux и Bash для DevOps-инженеров связывает сетевые настройки с доступностью учебного приложения. Откройте программу, чтобы выстроить практику: сформулировать гипотезу, выбрать проверку и записать понятный runbook для повторения сбоя.

Ещё по теме

• CLOSE_WAIT растёт: почему перезапуск сети не закрывает сокеты приложения
• dig находит адрес, приложение нет: сравниваем DNS и системное разрешение имён