Картина знакомая. Без VPN тест показывает 300 Мбит/с, после подключения остается 70. Списать потерянные 230 Мбит на шифрование было бы удобно, но почти наверняка неправильно. Криптография создает нагрузку, однако скорость VPN чаще ограничивает сочетание маршрута, сервера, процессора устройства, протокола, размера пакетов и качества самой линии.
Универсальной нормы потери скорости не существует. Для близкого сервера, современного компьютера и стабильного проводного соединения я считаю потерю примерно 5-20% хорошим результатом. Просадка на 20-40% сама по себе еще не доказывает неисправность. Если при тех же условиях остается меньше половины исходной скорости, я уже ищу конкретное узкое место. Такая шкала не стандарт VPN, а практический диагностический ориентир. Потеря с 300 до 70 Мбит/с вполне возможна, но считать ее неизбежной «ценой шифрования» нельзя.
Что VPN делает с каждым пакетом
Без туннеля путь можно сильно упростить до такой схемы.
устройство → провайдер → интернет → сайтПосле включения VPN появляется промежуточный узел.
устройство → провайдер → VPN-сервер → интернет → сайтПричем VPN-клиент не просто меняет адрес назначения. Исходный IP-пакет попадает в виртуальный сетевой интерфейс, шифруется и помещается внутрь нового пакета. VPN-сервер снимает внешнюю оболочку, расшифровывает содержимое и отправляет исходный пакет дальше.
Уже на этом этапе появляются несколько потенциальных ограничений. Пакету приходится пройти дополнительный маршрут, клиент и сервер тратят вычислительные ресурсы, а инкапсуляция увеличивает количество передаваемых байтов. VPN-сервер имеет собственные сетевые порты, процессоры и лимиты, поэтому бесконечной пропускной способности у него нет.
Полезно отделить накладные расходы протокола от остальных потерь. На примере WireGuard хорошо видно, почему одними заголовками невозможно объяснить четырехкратное падение скорости. Транспортное сообщение WireGuard содержит 16 байт собственного заголовка и 16 байт тега аутентификации. С внешними IPv4 и UDP-заголовками получается минимум около 60 дополнительных байт, с IPv6 около 80 байт, не считая возможного выравнивания. Подробный формат протокола открыт и достаточно компактен.
На пакетах размером около полутора килобайт такие накладные расходы измеряются единицами процентов. На множестве мелких пакетов относительная доля становится выше, но превращение 300 Мбит/с в 70 Мбит/с одними дополнительными заголовками все равно не объяснить.
Зато инкапсуляция приводит к другой проблеме. В обычной Ethernet-сети часто встречается MTU 1500 байт. Если попытаться засунуть внутрь туннеля полноценный пакет такого размера и сверху добавить VPN-заголовки, внешний пакет уже может не поместиться в MTU следующего участка пути. Хорошие реализации уменьшают MTU виртуального интерфейса или корректируют TCP MSS. Например, wg-quick умеет рассчитывать MTU автоматически.
При неудачной настройке возникают фрагментация, дополнительные операции с пакетами или проблемы с обнаружением допустимого MTU пути. Характерный симптом выглядит странно. Небольшие запросы проходят нормально, а крупные передачи тормозят, зависают или работают нестабильно. Поэтому совет «просто увеличьте MTU до 1500» для VPN иногда дает прямо противоположный результат.
Материал посвящен диагностике и законному применению VPN для защиты соединений и доступа к собственным или корпоративным сетям. При работе с VPN нужно соблюдать законодательство своей страны, включая законодательство России, а также правила используемых сервисов. Инструкции нельзя применять для несанкционированного доступа, слежки, взлома или незаконного обхода ограничений.
Почему пинг вырос, хотя мегабиты почти не изменились
Пропускная способность и задержка измеряют разные свойства сети. Канал способен передавать 300 Мбит каждую секунду и одновременно доставлять отдельный пакет заметно дольше. Поэтому после включения VPN можно получить 285 Мбит/с вместо 300 Мбит/с, но увидеть рост задержки с 8 до 45 мс.
Причина часто находится в маршруте. Без VPN запрос идет к сайту по маршруту, который выбрали операторы между пользователем и сервером сайта. С VPN весь подходящий трафик сначала должен дойти до VPN-узла. Если узел находится далеко или путь к нему проходит через несколько перегруженных сетей, RTT растет. Географически ближайший сервер при этом не обязательно окажется сетево ближайшим. Пиринг и маршрутизация операторов иногда отправляют трафик к соседней стране весьма странным крюком.
Задержка влияет не только на игры и видеозвонки. TCP управляет количеством неподтвержденных данных с помощью окна перегрузки и реагирует на потери. Чем дольше приходится ждать подтверждений и чем чаще теряются пакеты, тем сложнее одному соединению использовать широкий канал полностью. Современные алгоритмы управления перегрузкой отличаются друг от друга, но физику RTT отменить не могут.
Есть еще одна причина, которую легко пропустить. Проверять нужно не только пинг на свободном канале, но и задержку под нагрузкой. Если очередь на роутере, VPN-шлюзе или другом узком участке начинает расти во время скачивания, пинг может увеличиться на десятки или сотни миллисекунд. Такое явление называют bufferbloat. В результате Speedtest показывает красивые мегабиты, а голосовая связь и удаленный рабочий стол начинают дергаться именно во время активной загрузки.
Потому два VPN с одинаковыми 200 Мбит/с могут ощущаться совершенно по-разному. Первый держит RTT около 20 мс даже под нагрузкой, второй раздувает задержку до 200 мс. Для браузера разница уже заметна, для игры или удаленного рабочего стола становится критичной.
Отдельный неприятный случай связан с туннелированием TCP внутри TCP. Некоторые VPN умеют использовать TCP в качестве внешнего транспорта. Если внутри такого туннеля передается обычный TCP-трафик и на линии начинаются потери, два механизма надежной доставки способны мешать друг другу. Внешний TCP ждет потерянный сегмент и задерживает следующие данные, внутренний TCP видит задержку и тоже начинает реагировать на предполагаемые потери. Поэтому TCP-транспорт VPN не следует автоматически считать «надежнее и значит быстрее».
Почему один и тот же VPN дает 400 Мбит/с на ПК и 80 на роутере
Гигабитные порты маршрутизатора не означают гигабитный VPN. Обычный NAT и маршрутизацию современный роутер может выполнять с аппаратным ускорением, тогда как обработка туннеля идет по другому пути и сильнее нагружает центральный процессор. Роутер одновременно обслуживает NAT, межсетевой экран, Wi-Fi, таблицу соединений и криптографию. На слабом ARM-процессоре предел может наступить задолго до гигабита.
Так появляется характерное плато. Интернет без VPN показывает 800 Мбит/с, WireGuard или OpenVPN на роутере стабильно упирается, например, в 90 Мбит/с, а тот же профиль на мощном компьютере дает 500 Мбит/с. Повышение тарифа в такой ситуации не поможет. Ограничитель находится после интернет-канала.
Старые сравнения протоколов тоже нужно читать осторожно. WireGuard изначально проектировали как компактный VPN поверх UDP и на Linux реализовали в ядре. Классический OpenVPN долго обрабатывал канал данных в пользовательском пространстве, что требовало дополнительных копирований пакетов между ядром и процессом OpenVPN.
Современный OpenVPN умеет работать иначе. Механизм DCO переносит обработку канала данных в ядро и сокращает часть прежних накладных расходов. В Linux поддержка соответствующего драйвера ovpn вошла в основное ядро, а ветка OpenVPN 2.7 активно использует новую архитектуру. Поэтому фраза «WireGuard всегда быстрее OpenVPN» слишком категорична. WireGuard часто показывает отличную производительность, особенно на ограниченном оборудовании, но итог определяют версия клиента, операционная система, сервер, процессор и сетевые условия.
На телефонах картина похожая. VPN конкурирует за процессор с остальной системой, а длительная высокая нагрузка может привести к нагреву и снижению частот. На беспроводном соединении добавляются помехи, качество радиоканала и переключения между диапазонами. Поэтому сравнивать VPN на ноутбуке по Ethernet с VPN на смартфоне через слабый Wi-Fi бессмысленно.
| Что наблюдаю | Что проверяю первым |
|---|---|
| Скорость всегда упирается примерно в одну цифру на роутере | Загрузку процессора и реальную производительность VPN роутера |
| Один VPN-сервер медленный, остальные быстрые | Загрузку сервера и маршрут до него |
| Скорость нормальная, пинг резко вырос | Расстояние, маршрут и задержку под нагрузкой |
| Мелкие запросы работают, крупные передачи зависают | MTU, MSS и обнаружение MTU пути |
| VPN медленный только по Wi-Fi | Сначала сам беспроводной канал без VPN |
| TCP-вариант туннеля резко хуже на нестабильной линии | Потери пакетов и влияние TCP внутри TCP |
Как измерить скорость VPN так, чтобы тест что-нибудь доказывал
Один Speedtest без VPN и один после подключения легко вводят в заблуждение. Сервис выбирает тестовый узел с учетом доступных серверов и задержки. После включения VPN внешний IP и сетевой маршрут меняются, поэтому автоматически может выбраться совсем другой сервер. В итоге человек сравнивает не только VPN, но и две разные точки назначения.
Для диагностики я делаю два разных сравнения. Первое проверяет именно накладные расходы туннеля. Здесь стараюсь использовать один и тот же тестовый сервер до и после подключения. Второе показывает реальный пользовательский сценарий. Здесь разрешаю тесту автоматически подобрать оптимальный узел в обоих режимах. Цифры отвечают на разные вопросы, поэтому смешивать их не стоит.
- Убираю Wi-Fi из эксперимента. Если возможно, подключаю компьютер кабелем.
- Делаю несколько измерений без VPN. Один случайный пик ничего не доказывает.
- Повторяю серию через VPN. Сравниваю медиану, а не лучший результат.
- Смотрю отдельно download, upload и RTT. Один показатель не описывает соединение целиком.
- Проверяю другой VPN-сервер. Большая разница сразу отделяет локальную проблему от серверной или маршрутной.
- Повторяю тест на другом устройстве. Особенно полезно сравнить роутер и современный ПК.
Пинг можно быстро сравнить обычной командой.
ping example.comЕсли требуется проверить собственный VPN-шлюз без влияния публичного Speedtest, полезнее iperf3. На контролируемом сервере запускается принимающая сторона, а клиент измеряет пропускную способность непосредственно до нее.
iperf3 -c SERVER_IPТакой тест особенно полезен для корпоративной сети или собственного сервера. Если iperf3 внутри контролируемого маршрута показывает 500 Мбит/с, а конкретный сайт скачивается со скоростью 50 Мбит/с, туннель сам по себе уже выглядит менее подозрительно.
Смотреть нужно и на разброс. Результаты 190, 195, 187 и 193 Мбит/с говорят о стабильном потолке. Последовательность 220, 70, 180 и 45 Мбит/с больше похожа на перегрузку, потери, нестабильный беспроводной канал или меняющиеся очереди.
Поэтому мой ответ на вопрос про 300 и 70 Мбит/с простой. Четырехкратное падение возможно, но нормой по умолчанию я бы его не считала. Сначала проверила бы тот же VPN на современном ПК по кабелю, затем другой сервер, пинг без нагрузки и под нагрузкой, загрузку процессора роутера и стабильность нескольких тестов. В большинстве случаев такой порядок быстро показывает, исчезают мегабиты на домашнем устройстве, на пути к VPN-серверу или уже на самом узле.
VPN всегда уменьшает скорость интернета?
Небольшие накладные расходы почти неизбежны, но заметное падение бывает не всегда. Иногда разница укладывается в погрешность обычных измерений. В редких случаях новый маршрут через VPN даже дает более высокую скорость до конкретного ресурса, если прямой маршрут провайдера оказался хуже.
Какая потеря скорости через VPN считается нормальной?
Официальной нормы нет. Для близкого сервера и современного устройства потерю около 5-20% я считаю хорошим ориентиром. Если стабильно исчезает больше половины скорости, уже имеет смысл искать ограничение в сервере, маршруте, протоколе или устройстве.
Почему VPN сильно увеличивает пинг?
Трафик сначала идет до VPN-сервера, поэтому путь часто становится длиннее. Дополнительную задержку создают очереди, загрузка узлов и иногда слабое оборудование. Высокий пинг при почти неизменной пропускной способности вполне возможен.
Почему VPN на роутере медленнее, чем на компьютере?
Частая причина заключается в производительности процессора роутера. Гигабитные Ethernet-порты показывают скорость физического интерфейса, а не скорость шифрования VPN-трафика.
WireGuard всегда быстрее OpenVPN?
Нет. WireGuard часто работает быстрее и экономнее на ограниченном оборудовании, но современный OpenVPN с DCO устранил часть старых архитектурных накладных расходов. Реальный результат зависит от платформы, версии, процессора и сети.
Может ли VPN сделать интернет быстрее?
Иногда конкретный ресурс действительно работает быстрее через VPN, если туннель случайно получает более удачный маршрут. Такое ускорение не относится к штатным свойствам VPN и не означает, что шифрование само по себе повышает скорость линии.
Небольшая потеря мегабит у VPN естественна, потеря в несколько раз требует объяснения. Самый полезный подход состоит не в поиске магического процента, а в последовательном исключении ограничителей. Сначала устройство и Wi-Fi, затем VPN-сервер и маршрут, потом протокол, MTU, потери и задержка под нагрузкой. Такой тест показывает реальную причину гораздо точнее, чем любая реклама «самого быстрого VPN».
