Packet loss на VPN: как диагностировать

MAATRIX

Видеозвонок рассыпается на слова, игра лагает рывками, SSH-сессия периодически «замирает» — и первым делом грешат на сам VPN. На деле потери пакетов почти никогда не рождаются «в туннеле» просто так: они либо приходят снаружи, с маршрута до сервера, либо появляются из-за неверно подобранного MTU. Ниже — методика, которая за 20-30 минут показывает, где именно теряются пакеты.

Три точки, где могут теряться пакеты

Прежде чем что-то чинить, разделите маршрут на три участка:

• До сервера, вне туннеля — обычный сетевой путь: провайдер, магистральные каналы, пиринги. Потери здесь наследуются VPN, а не создаются им.
• Инкапсуляция на самом сервере — VPN оборачивает трафик в дополнительный заголовок и фрагментирует пакеты, если итоговый размер не проходит по пути. Отдельный источник потерь, которого без туннеля не было бы.
• После сервера, до целевого ресурса — слабый аплинк дата-центра тоже спишут на «VPN тормозит», хотя туннель ни при чём.

Диагностику стоит вести параллельно на всех трёх участках, иначе легко «полечить» не там, где сидит причина.

Сравниваем потери вне туннеля и внутри

Самый информативный тест — сопоставить потери на голом IP сервера и потери внутри уже поднятого туннеля. Если процент и хопы совпадают — дело в сети, а не в VPN. Сначала без VPN напрямую до IP сервера, затем то же самое внутри туннеля до внутреннего VPN-адреса (10.8.0.1 для OpenVPN, адрес из AllowedIPs для WireGuard), и третий замер — сквозь туннель до внешнего ресурса, который уже мерили без VPN:

mtr -rwzbc 200 203.0.113.10
mtr -rwzbc 200 10.8.0.1
mtr -rwzbc 200 1.1.1.1

Разовый «ping до сервера с потерями» ничего не говорит о причине — только сравнение показывает диагноз.

MTU и фрагментация — причина номер один

Если потери есть именно внутри туннеля при чистом маршруте снаружи — в большинстве случаев это MTU. VPN добавляет к пакету служебный заголовок (у WireGuard около 60 байт для IPv4, у OpenVPN через UDP — порядка 40-60 байт). Пакет, близкий к MTU физического интерфейса, после инкапсуляции вылезает за его границу — и либо фрагментируется, либо, если на маршруте заблокирован ICMP «Fragmentation Needed», молча пропадает. Второй случай называют MTU black hole — самая коварная форма packet loss: обычный ping мелкими пакетами её не покажет.

Характерный симптом: ping и SSH работают идеально, а скачивание файла или видеозвонок рвутся — ICMP echo по умолчанию мелкий (56-64 байта) и проходит через любое MTU, а реальный трафик приложений нет.

Реальный MTU пути ищется бинарным поиском через ping с флагом «не фрагментировать»:

ping -M do -s 1472 203.0.113.10

Если пакет не проходит («Frag needed and DF set» или таймаут) — уменьшайте размер (1472, 1400, 1350...), пока не пройдёт. Рабочий размер + 28 байт заголовка = реальный MTU пути. На Windows — ping -f -l 1472 203.0.113.10, быстрее автообнаружение на Linux — tracepath 203.0.113.10.

Сверьте найденное значение с MTU туннельного интерфейса (ip link show wg0 / tun0). Дефолты: WireGuard — 1420, OpenVPN — 1500. Если реальный Path MTU ниже (частая причина — PPPoE у провайдера с MTU 1492), дефолт окажется завышен — и вы получите потери, растущие с размером пакета.

Тюнинг MTU в WireGuard и OpenVPN

WireGuard — MTU в конфиге интерфейса:

[Interface]
Address = 10.0.0.2/24
MTU = 1380

Отправная точка — не 1420 по умолчанию, а расчёт от реального Path MTU минус оверхед (около 60 байт) с запасом 10-20 байт. Путь держит 1492 (PPPoE) — ставьте MTU = 1420; путь у́же (встроенный туннель у оператора) — ставьте около 1340.

OpenVPN гибче — можно зафиксировать MTU туннеля и подстроить TCP MSS:

tun-mtu 1400
mssfix 1360
fragment 1300

mssfix подрезает MSS TCP-соединений (веб, SSH), но не помогает UDP-трафику приложений (игры, VoIP) — там важен корректный tun-mtu. fragment — подстраховка на крайний случай: фрагментация сама увеличивает число пакетов и риск потери одного из них. После изменения MTU переподнимите интерфейс и повторите замер — если потери, растущие с размером пакета, исчезли, причина была именно в этом.

Что смотреть отдельно в WireGuard и OpenVPN

WireGuard не разрывает соединение явно — при потерях он просто «молчит». Проверяйте время последнего хендшейка командой wg show wg0: если latest handshake не обновляется больше 2-3 минут при активном трафике, это уже не рядовой packet loss, а обрыв UDP-сессии (часто NAT-таймаут), см. хендшейк WireGuard есть, а трафика нет. Для клиента за NAT полезен PersistentKeepalive = 25 — не лечит потери, но не даёт NAT-маппингу вымыться раньше времени.

OpenVPN честнее логирует происходящее (tail -f /var/log/openvpn/openvpn.log) — регулярные TLS Error: TLS handshake failed при стабильном в целом соединении отдельная история про перегруженный CPU, см. частые ошибки OpenVPN на сервере.

Для количественной оценки потерь на UDP полезнее не ping, а iperf3:

# на сервере
iperf3 -s
# у клиента, поверх туннеля
iperf3 -u -c 10.8.0.1 -b 20M -t 30

Отчёт покажет процент потерянных датаграмм напрямую — честнее оценки по ICMP, потому что нагружает канал реальным UDP-потоком, похожим на трафик приложения.

Когда виноват не туннель

Если потери есть и вне туннеля, на одних и тех же хопах, а MTU ни при чём — почти наверняка проблема в сети:

• зафиксируйте mtr-отчёт с потерями по конкретным хопам и отдайте поддержке хостинга или провайдеру — ASN и проценты ускоряют разбор;
• проверьте, не совпадают ли потери по времени с часами пиковой нагрузки — тогда это лечится сменой локации или терпением;
• потери привязаны именно к UDP-порту VPN и не проявляются на TCP до того же сервера — возможен шейпинг или DPI на узле; помогает смена порта на 443/tcp или обфусцированный протокол вроде AmneziaWG.

Не спешите переустанавливать сервер, пока не прогнали связку «до/после туннеля» и проверку MTU. Небольшой стабильный процент потерь на длинном межконтинентальном маршруте иногда норма — ориентиры есть в материале про замеры пинга и латентности между локациями. После того как причина найдена, стоит поставить постоянный мониторинг — например, Uptime Kuma для VPN-сервера.

Частые вопросы