Содержание

Что делать, если утечка MTU ломает SSH, туннели и мониторинг

Если SSH через VPN зависает после входа, HTTPS работает нестабильно, а Zabbix теряет метрики без видимой причины — проблема может быть не в самих сервисах, а в неправильном MTU.

При этом обычный ping может работать нормально.

MTU (Maximum Transmission Unit) — это максимальный размер пакета на канальном уровне. Если он больше, чем реальная пропускная способность промежуточных узлов, пакеты начинают теряться без уведомлений. Особенно часто это происходит, когда ICMP заблокирован (так называемый ICMP blackhole).

Как это проявляется?

Диагностика

1. tracepath — сразу показывает проблемный узел

$ tracepath 77.88.8.8

Если на каком-то участке TTL доходит, но MTU резко падает — это и есть узкое место.

2. ping с запретом фрагментации

$ ping -M do -s 1472 77.88.8.8

Если пинг с размером 1472 не проходит, а с 1400 — работает, значит, MTU завышен.

3. tcpdump — анализ TCP и ICMP

# tcpdump -ni wg0 icmp or tcp port 443

Ищите пропущенные ACK или неожиданные RST.

Как исправить?

1. Уменьшаем MTU на интерфейсе VPN (WireGuard, OpenVPN)

Для WireGuard:

# ip link set wg0 mtu 1380

Выберите значение чуть меньше, чем реально проходит по пути (например, 1380 вместо 1500).

2. Клэмпим MSS через iptables (если нельзя менять настройки клиента)

# iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Это автоматически корректирует MSS в зависимости от PMTU Discovery.

3. Проверка текущего MTU

# ip link show dev wg0

4. На сетевом оборудовании

На маршрутизаторах и фаерволах:

Заключение

Проблемы с MTU могут выглядеть как глюки приложений, но на самом деле они связаны с сетевой инфраструктурой. Особенно это критично при использовании туннелей (WireGuard, OpenVPN), где накладываются дополнительные заголовки, уменьшая допустимый размер полезной нагрузки.

Не забывайте проверять MTU, если у вас:

Правильный MTU — залог стабильной работы всей сети.