Почему туннель «подтормаживает»: история одного MTU

Нам написал заказчик с классической жалобой: «туннель между офисами поднимается, пинг идёт, но стоит начать копировать файлы — всё замирает». По телефону это звучит как мистика, на практике — почти всегда одна и та же история.

Симптомы

• мелкие запросы проходят: ping, DNS, короткие HTTP-ответы;
• большие ответы и передача файлов зависают без ошибок;
• SSH подключается, но «замирает» на первом большом выводе.

Такая картина почти всегда означает одно: пакеты с максимальным размером не пролезают в канал, а ICMP-сообщения об этом по дороге где-то теряются.

Диагностика за десять минут

Не трогаем конфигурацию, просто измеряем. С любой стороны туннеля:

for size in 1500 1472 1420 1400 1360 1280; do
  ping -M do -s $((size - 28)) -c 2 -W 2 10.0.0.1 > /dev/null 2>&1 \
    && echo "$size OK" || echo "$size FAIL"
done

В нашем случае 1500 и 1472 «падали», а 1360 проходил стабильно. Вычитаем 28 байт заголовков — получаем честный потолок канала.

Причина

Между площадками оказалась цепочка из трёх инкапсуляций, каждая из которых съедала свои байты полезной нагрузки. Суммарно — больше сотни байт, которые никто не закладывал в расчёт. Формально каждый участок был настроен «по методичке».

Что сделали

Срезали MTU на туннельных интерфейсах до измеренного значения с запасом и добавили корректировку MSS для TCP-сессий. Файлы поехали сразу, а в мониторинг добавили метрику «максимальный проходящий размер пакета» — теперь деградация видна до жалоб пользователей.

Вывод простой: если канал «жив, но не едет» — не начинайте с перезагрузки оборудования. Начните с измерения. Это дешевле.