Измерение скорости VPN через iperf3

MAATRIX

Если вы сравниваете скорость VPN «на глаз» через speedtest.net в браузере — вы измеряете не туннель, а браузер, TLS-сессию до ближайшего CDN-узла и текущую загрузку чужого сервера. Разница между двумя такими замерами в 20-30% ничего не говорит о том, стал ли туннель быстрее. iperf3 убирает почти все посторонние переменные и показывает, сколько байт реально проходит между двумя точками в единицу времени — с настраиваемым числом потоков, протоколом и длительностью теста. Ниже — рабочая методика, которой можно доверять при сравнении протоколов, локаций или тарифов.

Почему браузерные спидтесты врут

Спидтест в браузере одновременно тестирует несколько вещей, и вы не можете разделить их вклад:

• TLS-хендшейк и HTTP-оверхед — на короткий тест (10-15 секунд) уходит заметная доля времени на установку соединения, а не на передачу данных.
• Один TCP-поток — пропускная способность одного TCP-соединения ограничена произведением bandwidth × latency (BDP) и размером окна получателя. На канале с задержкой 80-150 мс (типично для туннеля через океан) один поток может не выбрать и половины реальной емкости канала, даже если труба шире.
• Чужой сервер спидтеста — вы не контролируете его загрузку, маршрут CDN и то, использует ли он ту же магистраль, что и ваш VPN-провайдер.
• Локальный Wi-Fi и NAT клиента — переменная, которая никак не относится к серверу или туннелю, но полностью смешивается с результатом.

iperf3 убирает три из четырёх переменных: вы сами поднимаете сервер (на своём VPS или на другом конце туннеля), сами задаёте число потоков и протокол, сами контролируете длительность теста. Остаётся только собственно канал — то, что вы и хотите измерить.

Устанавливаем iperf3 на обоих концах

iperf3 нужен на двух машинах: одна работает сервером (слушает порт), вторая — клиентом (открывает поток и шлёт данные). Для честного замера туннеля сервер поднимаете на удалённой стороне VPN (например, на арендованном VPS в нужной локации), клиент — на своей машине или на другом сервере, подключённом к тому же туннелю.

# Debian/Ubuntu
sudo apt update && sudo apt install -y iperf3

# AlmaLinux/Rocky
sudo dnf install -y iperf3

# macOS
brew install iperf3

# Windows — бинарник с iperf.fr, или через Chocolatey
choco install iperf3

На сервере открываете порт (по умолчанию iperf3 слушает 5201/tcp и udp):

sudo ufw allow 5201/tcp
sudo ufw allow 5201/udp
# или iptables
sudo iptables -A INPUT -p tcp --dport 5201 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 5201 -j ACCEPT

Важный нюанс: если тестируете именно туннель, а не публичный интернет, порт 5201 должен быть открыт на внутреннем VPN-интерфейсе (wg0, tun0), а сам сервер iperf3 — слушать на VPN-адресе сервера, а не на публичном IP. Иначе вы случайно замерите скорость до публичного IP напрямую, в обход туннеля, и результат будет бессмысленным.

Запуск сервера:

iperf3 -s -B 10.66.0.1   # -B — bind на VPN-адрес интерфейса

Базовый замер: TCP, UDP и параллельные потоки

Простейший TCP-тест с клиента:

iperf3 -c 10.66.0.1 -t 20 -i 5

-t 20 — длительность 20 секунд, -i 5 — вывод промежуточных отчётов каждые 5 секунд (полезно видеть, стабилизировалась ли скорость или колеблется). В конце получите строку вида:

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec   245 MBytes  102 Mbits/sec   14   sender
[  5]   0.00-20.00  sec   238 MBytes  99.8 Mbits/sec        receiver

Столбец Retr — число ретрансмиссий TCP за тест. Если он растёт от прогона к прогону — это не «медленный VPN», а потери пакетов или перегрузка где-то на маршруте (в том числе на самом туннеле при инкапсуляции UDP-пакетов WireGuard/OpenVPN, если MTU настроен неверно).

Один TCP-поток на канале с большой задержкой часто не выбирает всю доступную полосу — упирается в размер окна. Проверяйте несколькими параллельными потоками:

iperf3 -c 10.66.0.1 -t 20 -P 4

-P 4 открывает 4 параллельных TCP-соединения и суммирует их bitrate. Если суммарный результат с -P 4 заметно (в разы) больше, чем с -P 1, — узкое место было не в туннеле, а в TCP-окне одного потока, и «реальная» пропускная способность канала ближе к результату с несколькими потоками.

Для протоколов, которые сами инкапсулируются в UDP (WireGuard всегда, OpenVPN в UDP-режиме), полезно измерить и UDP-производительность:

iperf3 -c 10.66.0.1 -u -b 500M -t 20

-b 500M задаёт целевую скорость отправки (по умолчанию UDP-тест ограничен 1 Мбит/с, если не указать -b). В отчёте смотрите на Jitter и Lost/Total Datagrams — если потери выше 1-2%, канал (или сам туннель) не справляется с такой скоростью, и это отдельная проблема от «просто медленно».

Сравниваем канал без VPN и через туннель

Чтобы понять, сколько именно съедает сам туннель, нужны два замера между теми же (или максимально похожими) точками: напрямую по публичным IP и через VPN-интерфейс.

# Напрямую, минуя туннель
iperf3 -c 203.0.113.10 -t 20 -P 4

# Через WireGuard/OpenVPN
iperf3 -c 10.66.0.1 -t 20 -P 4

Разница между этими числами — это оверхед инкапсуляции плюс, если он есть, оверхед шифрования на CPU. У WireGuard заголовок на пакет — около 60 байт (20 IP + 8 UDP + 32 WireGuard header) поверх исходного пакета, поэтому на MTU 1420 доля служебных данных обычно в пределах нескольких процентов от полезной нагрузки — но это ориентир, а не гарантия: реальная цифра зависит от размера пакетов в вашем трафике и настроенного MTU. У OpenVPN оверхед обычно выше — добавляются TLS-заголовки и HMAC на каждый пакет, плюс сам OpenVPN однопоточен по умолчанию и на слабом CPU может упираться не в канал, а в производительность ядра, обрабатывающего шифрование.

Если разница между «напрямую» и «через туннель» больше 15-20% — стоит проверить:

• MTU — фрагментация из-за заниженного MTU на туннельном интерфейсе резко бьёт по TCP-throughput. ping -M do -s 1400 10.66.0.1 со стороны клиента покажет, проходит ли пакет такого размера без фрагментации.
• Шифрование на CPU — htop во время теста на обеих сторонах покажет, не упирается ли один из процессов (openvpn, wireguard-go на не-Linux системах) в одно ядро на 100%.
• Congestion control — на канале с большой задержкой разница между cubic и bbr (sysctl net.ipv4.tcp_congestion_control) может быть существенной именно для одиночного TCP-потока.

Если вы выбираете между протоколами для нового сервера, сравнение через iperf3 в одинаковых условиях — единственный способ получить сопоставимые цифры; общие рассуждения о том, WireGuard или OpenVPN выбрать для сервера, дают направление, но конкретное решение стоит проверять замером на своём канале.

Автоматизация регулярных замеров

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

Вывод в JSON удобно парсить и логировать:

iperf3 -c 10.66.0.1 -t 15 -J > /var/log/iperf3-$(date +%Y%m%d-%H%M).json

Извлечь ключевые метрики через jq:

jq '{
  sent_mbps: (.end.sum_sent.bits_per_second / 1000000),
  recv_mbps: (.end.sum_received.bits_per_second / 1000000),
  retransmits: .end.sum_sent.retransmits
}' /var/log/iperf3-20260830-1200.json

Простой cron-замер раз в 30 минут, с ротацией лога:

*/30 * * * * /usr/bin/iperf3 -c 10.66.0.1 -t 10 -J | jq -c '{ts: now, mbps: (.end.sum_received.bits_per_second/1000000)}' >> /var/log/vpn-iperf.jsonl

Накопив за пару суток такой лог, легко посчитать медиану и разброс (например, через jq -s 'map(.mbps) | sort | .[length/2|floor]') — это куда честнее одного «удачного» замера в 3 часа ночи, когда канал никем не занят. Если у вас несколько пользователей на одном сервере и вы хотите не просто мерить, а управлять полосой по клиенту, это отдельная задача — она разобрана в статье про ограничение скорости и трафика на пользователя VPN.

Типичные ошибки при замере

• Слишком короткий тест. 5-секундный прогон в основном меряет slow start TCP, а не установившуюся скорость. Берите минимум 15-20 секунд, для важных сравнений — 60.
• Один поток на канале с большой задержкой. Уже разобрано выше — обязательно сверяйте -P 1 с -P 4 или -P 8, прежде чем делать вывод про «медленный туннель».
• Тест на слабом VPS с 1 vCPU. Если сервер iperf3 сам упирается в CPU (особенно с шифрованием AES без аппаратного ускорения AES-NI), вы меряете не канал, а мощность процессора. Проверьте openssl speed -evp aes-256-gcm на обеих сторонах, чтобы исключить это до теста.
• Сравнение серверов в разных дата-центрах без учёта расстояния. Разница в latency между RU, US и UK локациями сама по себе меняет поведение TCP-окна — сравнивать пропускную способность между площадками имеет смысл только с одинаковым -P, и с пониманием, что более высокая задержка снижает throughput одного потока независимо от реальной ширины канала. Для ориентира по конкретным регионам полезно смотреть скорость и uptime серверов в России — там методика замеров и типичные цифры разобраны отдельно.
• Замер в момент пиковой нагрузки на хостинге. Разовый тест в 20:00 буднего дня и в 04:00 воскресенья на одном и том же тарифе может отличаться в разы просто из-за соседей по гипервизору — отсюда и совет собирать серию, а не полагаться на один прогон.
• Забытый файрвол или NAT-петля. Если тест внезапно даёт 0 Мбит/с или зависает — проверьте, что порт 5201 действительно открыт на нужном интерфейсе, а не заблокирован на промежуточном роутере или в security group облака.

Для постоянного контроля состояния туннеля (а не только разовых замеров скорости) удобно завести отдельный мониторинг доступности — это дополняет iperf3, а не заменяет его; подробнее — в статье про мониторинг доступности VPN-сервера через Uptime Kuma.

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