Traceroute и ping через VPN: что нормально, а что нет

MAATRIX

Подняли WireGuard или OpenVPN, запустили ping — и цифра выросла в два-три раза. Или сделали traceroute и увидели десяток хопов вместо трёх. Первая реакция — «что-то сломалось». Но в большинстве случаев туннель работает ровно так, как должен: он оборачивает трафик, добавляет маршрут через сервер и меняет то, что видят диагностические утилиты. Разберёмся, где рост задержки и хопов — это нормальная плата за туннелирование, а где — сигнал реальной проблемы.

Почему пинг через VPN всегда выше, чем напрямую

Без VPN пакет идёт от вас до целевого сервера по кратчайшему маршруту, который выбирают провайдеры на BGP-таблицах. С VPN путь другой: клиент → VPN-сервер → целевой хост, и часто ещё обратно тем же путём. Это уже минимум одно дополнительное плечо в оба конца.

Если вы измеряете пинг до сайта через VPN-сервер, стоящий в Лондоне, а сайт физически ближе к вам напрямую, задержка растёт закономерно — вы физически удлинили маршрут. Разница обычно укладывается в 15-40 мс на трансконтинентальных направлениях, но зависит от конкретной пары локаций — точные цифры замеряйте сами, ориентиры по направлениям есть в статье про задержку между локациями.

Второй фактор — накладные расходы протокола. Каждый пакет заворачивается в новый заголовок (encapsulation), у WireGuard это ChaCha20-Poly1305 плюс UDP/IP-заголовок сверху, у OpenVPN — TLS-запись плюс собственный протокольный оверхед. Шифрование и расшифровка занимают процессорное время на обоих концах туннеля. На современном железе это доли миллисекунды, но на слабом VPS или роутере с младшим процессором может дать заметный вклад в задержку, особенно под нагрузкой.

Типичный ориентир: WireGuard добавляет к базовому пингу до сервера единицы миллисекунд накладных расходов протокола, OpenVPN в режиме UDP — чуть больше из-за более тяжёлого стека, TCP-режим OpenVPN — заметно больше из-за отдельного механизма надёжной доставки поверх уже надёжного TCP. Это ориентировочные соотношения, не измеренные цифры — на вашем канале и железе они будут другими.

Как читать вывод traceroute через туннель

Внутри VPN-подключения traceroute (Linux/macOS) или tracert (Windows) видит совсем другую картину, чем без туннеля.

traceroute -n 8.8.8.8

Первый хоп теперь — не ваш домашний роутер, а VPN-интерфейс (обычно 10.x.x.1 или похожий адрес из подсети туннеля). Это ожидаемо: с точки зрения операционной системы весь трафик, попадающий под маршруты VPN, сначала уходит в виртуальный интерфейс wg0 или tun0.

Дальше возможны три сценария:

• Один хоп — VPN-сервер, дальше сразу цель или её провайдер. Это нормально для WireGuard: он работает на UDP без промежуточных ретрансляций, и провайдер сервера часто не отвечает на ICMP TTL-exceeded, из-за чего несколько реальных хопов «сливаются» в один звёздный ряд (* * *), а затем сразу показывается ответ от цели.
• **Несколько «пустых» хопов подряд (* * *), а затем нормальные ответы.** Это не обрыв маршрута — многие транзитные роутеры в магистральных сетях просто не генерируют ICMP-ответы или блокируют их по политике. Traceroute всё равно продолжает считать TTL и получает ответы дальше по цепочке.
• Traceroute обрывается на VPN-сервере и не идёт дальше. Вот это уже стоит проверить отдельно — либо на сервере отключён форвардинг, либо файрвол режет исходящий ICMP/UDP от туннельной подсети.

Важный нюанс: traceroute по умолчанию использует UDP-пакеты (Linux) или ICMP (Windows tracert), а через VPN оба инкапсулируются в тот же зашифрованный туннель. Если хотите сравнить путь до VPN-сервера отдельно от пути внутри туннеля, гоняйте traceroute сначала до самого VPN-сервера (по его публичному IP, вне туннеля), а затем — до конечной цели через туннель. Так вы разделите два независимых участка маршрута и не будете путать проблему провайдера VPN-сервера с проблемой на стороне цели.

Нормальный рост числа хопов — и когда он ненормальный

Сравните два traceroute: без VPN до example.com — условно 9-12 хопов, через VPN до того же адреса — условно 14-18. Разница возникает из-за того, что маршрут теперь идёт: клиент → интернет до дата-центра VPN-сервера → сам сервер → его исходящий маршрут до цели. Вы буквально проезжаете лишний участок сети, и на нём есть свои промежуточные роутеры.

Это нормально, если рост хопов пропорционален добавленному расстоянию: сервер в другой стране почти всегда добавит 5-10 хопов на пути туда и обратно. Ненормально — когда:

• Число хопов внутри туннеля скачет от замера к замеру (то 12, то 25) при статичном маршруте — признак нестабильной магистрали или проблем на upstream-провайдере VPN-сервера.
• После входа в туннель появляется петля: один и тот же IP повторяется несколько раз подряд с растущим TTL — это может быть неправильная настройка маршрутизации на сервере (двойной NAT, конфликт таблиц маршрутизации) либо провайдер сознательно отдаёт "антиtraceroute" защиту, которая выглядит как петля, но не влияет на реальную доставку пакетов.
• Traceroute показывает резкий скачок задержки на одном хопе и такой же резкий возврат к норме на следующем — это почти всегда особенность обработки ICMP на конкретном роутере (он отвечает медленнее, чем форвардит трафик), а не реальная проблема с маршрутом.

Если сомневаетесь, зачтётся ли конкретный паттерн как проблема, лучший тест — не traceroute, а прямое измерение полезной нагрузки: скачать файл, померить джиттер под mtr, проверить реальную скорость. Traceroute показывает топологию, а не гарантирует, что именно на этом хопе теряются ваши пакеты.

MTU, фрагментация и скрытые причины роста пинга

Отдельная категория проблем — не собственно рост пинга, а его нестабильность: маленькие пакеты (ping -s 56) проходят нормально, а обычный веб-трафик или большие ICMP-пакеты тормозят или вовсе не проходят.

Причина почти всегда в MTU. VPN добавляет заголовки к каждому пакету, и если итоговый размер превышает MTU канала (типично 1500 байт на Ethernet), пакет либо фрагментируется, либо — если где-то по пути установлен флаг Don't Fragment и никто не шлёт ICMP "Fragmentation Needed" в ответ — просто теряется. WireGuard обычно требует MTU интерфейса около 1420 байт (1500 минус заголовки IP/UDP/WireGuard), у OpenVPN ориентир чуть отличается в зависимости от протокола и режима сжатия — точное значение стоит подбирать под конкретный канал, а не считать универсальной константой.

Проверить гипотезу можно вручную бинарным поиском по размеру пакета:

# Linux/macOS: -M do запрещает фрагментацию, -s задаёт размер payload
ping -M do -s 1472 8.8.8.8   # 1472 + 28 байт IP/ICMP = 1500

# Windows: -f запрещает фрагментацию
ping -f -l 1472 8.8.8.8

Уменьшайте -s/-l шагами, пока пакет не перестанет отваливаться с Packet needs to be fragmented but DF set — это и есть рабочий MTU минус заголовки IP/ICMP. Дальше выставляете MTU интерфейса туннеля с запасом. Для WireGuard это правится в конфиге:

[Interface]
MTU = 1400

Для OpenVPN — параметром tun-mtu или mssfix в конфиге сервера и клиента. Если после этого пинг стабилизировался, а сайты, которые раньше подвисали при загрузке, стали открываться нормально — вы нашли причину. Если у вас поверх WireGuard работает ещё и обфускация (например, через AmneziaWG), это добавляет свои байты заголовков и требует ещё меньшего MTU — при переходе на такой стек стоит пересчитать значение заново, детали в статье про AmneziaWG и разницу с обычным WireGuard.

Практика: разбираем реальный пример пошагово

Возьмём ситуацию: до VPN-сервера в Германии пинг с домашнего канала в России стабильно держится в разумных пределах, а вот пинг до сайта через туннель заметно выше и временами скачет.

Шаг 1 — измерьте базовую задержку до самого VPN-сервера, вне туннеля:

ping -c 20 <публичный IP сервера>

Если здесь уже нестабильность — проблема на участке клиент-сервер, туннель ни при чём. Это может быть загруженность вашего провайдера в часы пик или маршрутизация до конкретного дата-центра — тут поможет сравнение с другими локациями, см. методику в статье как измерить реальный пинг до сервера.

Шаг 2 — поднимите туннель и измерьте пинг до сервера уже через его туннельный адрес:

ping -c 20 10.8.0.1

Здесь задержка должна быть близка к шагу 1 плюс единицы миллисекунд на обработку шифрования. Если разница большая — не хватает CPU на сервере (актуально для дешёвых VPS с shared vCPU под нагрузкой) либо на сервере запущен инспектирующий трафик софт (DPI-детект, лишний файрвол-модуль), который тормозит каждый пакет.

Шаг 3 — traceroute от туннельного интерфейса до конечной цели:

traceroute -n -T -p 443 example.com

Флаг -T переключает на TCP SYN-пакеты по 443 порту — это полезно, когда обычный UDP-traceroute режется файрволами по пути (частая ситуация с магистральными провайдерами), а TCP на 443 почти всегда пропускается, так как имитирует обычный HTTPS-трафик.

Шаг 4 — если конкретный участок вызывает подозрение, погоняйте mtr (сочетание ping + traceroute с непрерывным замером) на 100+ пакетов, чтобы отличить разовый всплеск от системной потери на конкретном хопе:

mtr -rwc 100 example.com

Колонка Loss% на конкретной строке — это не всегда реальная потеря пакетов до цели. Если потери есть только на промежуточном хопе, а на последней строке (сама цель) потерь нет — транзитный роутер просто приоритизирует форвардинг ICMP ниже, чем обычный форвардинг. Ориентируйтесь на потери и задержку последней строки, а не промежуточных.

Когда рост задержки и хопов — реальный повод для действий

Отделить норму от проблемы помогает простое правило: сравнивайте не абсолютные цифры, а их стабильность и пропорциональность.

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

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