Корпоративные VPN сервисы: сравнение скорости и шифрования

Поэтому вопрос о том, сколько пропускной способности теряется на туннеле, давно не академический. Разработчики замечают медленный доступ к тестовым средам, менеджеры жалуются на видеозвонки, а служба безопасности выясняет, можно ли расширить шлюз без пересмотра всего бюджета. На один VPN-шлюз часто возлагают сразу маршрутизацию, шифрование, авторизацию и аутентификацию.

Проблема обычно не в том, что VPN просто медленный. Часто неизвестно, насколько именно он замедляет соединение и что служит причиной. Инженер открывает публичный спидтест, видит не ту цифру, которую ожидал, и винит провайдера или алгоритм шифрования. Такой результат мало что говорит о производительности самого шлюза. Чтобы понять, как проверить сравнение скорости и шифрования, нужно отделить работу туннеля от состояния внешней сети, а затем сравнивать протоколы в одинаковых условиях.

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

При подозрении на медленный VPN инженер нередко запускает speedtest-cli или открывает веб-спидтест через туннель. Получает результат, сопоставляет его с ожиданиями и закрывает тикет. Но измеренная таким образом скорость не является чистой оценкой VPN-шлюза.

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

Чтобы измерить пропускную способность туннеля, нужны две контролируемые точки: клиент за одним концом VPN и сервер за другим. Для такой задачи часто используют iperf3. Он создаёт TCP- или UDP-потоки между заданными узлами и показывает, сколько данных прошло по тестируемому маршруту. Условия можно менять: запускать один поток или несколько, выбирать транспорт и повторять тест при сопоставимой нагрузке.

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

Один TCP-поток помогает увидеть поведение отдельного соединения. Несколько потоков дают другую картину и могут лучше показать, как канал ведёт себя при параллельной передаче. Ни один режим сам по себе не описывает нагрузку всех корпоративных приложений. Если сотрудники одновременно обращаются к репозиториям, облачным системам и видеосервисам, стоит проверять и одиночные потоки, и параллельную нагрузку, а заодно фиксировать задержку и потери пакетов.

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

WireGuard против OpenVPN: архитектура важнее лозунга

На вопрос, почему WireGuard часто оказывается быстрее OpenVPN, легко ответить рекламной формулой: он современнее. Это не объясняет, откуда берётся разница. Важнее устройство обработки пакетов.

WireGuard был создан Джейсоном Доненфельдом и вошёл в ядро Linux в версии 5.6. Его реализация компактна по сравнению со многими сетевыми решениями. В Linux обработка пакетов может идти в ядре: это сокращает число переходов между ядром и пользовательским пространством, которые нужны при пересылке данных. Меньше лишней работы на пакет особенно важно, когда шлюз обрабатывает большой поток.

Классический OpenVPN работает как процесс в пользовательском пространстве. Пакеты туннельного интерфейса передаются этому процессу, где они обрабатываются и затем возвращаются в сетевой стек. На маршруте возникают переключения контекста и копирование данных. Сами по себе они не означают, что OpenVPN непременно будет медленным: результат зависит от процессора, настроек, транспорта и размера пакетов. Но при высокой нагрузке такие накладные расходы могут стать заметной частью общей работы шлюза.

Компактность WireGuard часто приводят как аргумент в пользу меньшей поверхности атаки. Это разумный аспект сравнения, но число строк кода не заменяет аудит безопасности и не гарантирует отсутствие уязвимостей. Есть и практическая оговорка: базовая конфигурация WireGuard не предоставляет привычный многим администраторам встроенный корпоративный контур управления пользователями, каталогами и отзывом доступа. Для централизованного управления обычно требуется дополнительная инфраструктура или стороннее решение.

Быстрый туннель полезен, когда его можно безопасно разворачивать, обновлять и отключать для конкретного пользователя. Производительность не отменяет задачу управления доступом.

OpenVPN, напротив, предлагает гибкие способы настройки и поддерживает интеграции, востребованные в корпоративной среде. Гибкость помогает совместимости, но расширяет число параметров, которые нужно поддерживать и проверять. Ошибка в конфигурации может ослабить защиту или ухудшить производительность. Поэтому сравнивать протоколы только по максимальной скорости в лабораторном прогоне недостаточно: важно учитывать, как устроены аутентификация, управление ключами и отзыв доступа.

Шифр не виноват: AES-256-GCM, ChaCha20-Poly1305 и AES-NI

Споры о том, какой алгоритм быстрее, редко имеют универсальный ответ. Производительность AES-256-GCM и ChaCha20-Poly1305 зависит от процессора и конкретной реализации. Важная деталь для AES — наличие и использование аппаратного ускорения AES-NI на совместимом процессоре.

На сервере с AES-NI AES-256-GCM может обрабатываться очень эффективно. На процессоре без такого ускорения ChaCha20-Poly1305 может оказаться предпочтительнее, поскольку его операции хорошо подходят для программной реализации. Поэтому алгоритм, который выигрывает на одном шлюзе, необязательно окажется быстрее на другом. Виртуальная машина тоже требует проверки: поддержка инструкций зависит не только от физического процессора, но и от того, доступны ли эти инструкции гостевой системе.

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

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

В корпоративной инфраструктуре стоит учитывать несколько условий:

• На сервере с AES-NI AES-256-GCM может работать быстро, но наличие инструкции само по себе не доказывает, что конкретная VPN-реализация её использует.
• На ARM-устройстве, маломощном маршрутизаторе или виртуальной машине без доступного аппаратного ускорения соотношение производительности может быть другим.
• Если процессор почти полностью занят, проверьте размер пакетов и настройки потоков: предел может задавать общая нагрузка, а не выбор алгоритма.
• Для честного сравнения зафиксируйте модель и конфигурацию шлюза, доступные процессору инструкции, версию VPN-программы и остальные параметры теста.

ГОСТ-алгоритмы в некоторых сборках OpenVPN могут быть доступны через криптографические библиотеки. Их выбор связан с требованиями к криптографии и регулированию. Сам по себе факт поддержки алгоритма не позволяет предсказать скорость: это отдельный тест на конкретном оборудовании и при нужной конфигурации.

TCP-over-TCP: почему блокировка UDP обходится дорого

Когда межсетевой экран блокирует UDP, администратор иногда переводит OpenVPN на TCP, например чтобы туннель мог проходить через сети с жёсткими ограничениями. Но меняется не только порт. TCP начинает управлять передачей внешнего туннеля, а приложения внутри него могут использовать собственные TCP-соединения.

Так возникает эффект, известный как TCP-over-TCP meltdown. Внутренний TCP и внешний TCP независимо реагируют на задержки и потери. Внешний уровень может задержать доставку данных и выполнить повторную передачу, а внутренний в это время тоже решает, что соединение столкнулось с потерей или перегрузкой. Из-за этого механизмы контроля перегрузки мешают друг другу: растут задержки, а восстановление потока становится менее предсказуемым.

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

Случайное сканирование UDP-порта WireGuard не должно получать характерный сигнатурный ответ: обычно неаутентифицированные пакеты он молча отбрасывает. Это важно не только как поправка к описанию протокола, но и для практической оценки заметности сервиса. Нельзя считать, что случайный запрос сам по себе подтвердит наличие WireGuard.

IKEv2/IPsec: аппаратное ускорение и бесшовный роуминг

В спорах о скорости WireGuard иногда называют IPsec устаревшим решением. Для корпоративной инфраструктуры это слишком широкое обобщение. Производительность IKEv2/IPsec зависит от реализации, настроек и аппаратуры. На шлюзах с поддержкой AES-NI шифрование может эффективно использовать возможности процессора; на отдельных маршрутизаторах часть обработки выполняют специализированные аппаратные компоненты. Это нужно подтверждать измерениями на конкретном устройстве.

У IKEv2 есть важная для мобильной работы возможность MOBIKE, описанная в RFC 4555. Она помогает сохранять VPN-соединение при смене сетевого адреса, например при переходе между Wi-Fi и мобильной сетью, если клиент и сервер поддерживают соответствующую функцию и правильно настроены. Для сотрудника, который перемещается между сетями, это может оказаться важнее небольшого выигрыша в пропускной способности.

IPsec/IKEv2 также часто выбирают там, где уже настроена работа с сертификатами X.509, централизованной аутентификацией и управлением мобильными устройствами. Конкретные возможности интеграции зависят от реализации и корпоративной инфраструктуры. Поэтому сравнивать нужно не абстрактное название протокола, а тот набор шлюзов, клиентов и инструментов администрирования, который реально будет развёрнут.

Установление соединения тоже требует аккуратного сравнения. Сообщения IKE_SA_INIT образуют обмен запросом и ответом, то есть занимают один RTT. Далее идёт продолжение согласования IKEv2, поэтому время полного установления туннеля зависит от последующих обменов, а также от задержки сети и настроек аутентификации. Сравнивать один этап протокола с полным установлением другого соединения некорректно.

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

Как проверить сравнение скорости и шифрования на своём шлюзе

Хороший тест отвечает не только на вопрос, какая цифра получилась, но и на вопрос, что именно изменилось. Для этого достаточно последовательного плана и одинаковых условий для каждого прогона.

1. Задайте контролируемый маршрут. Разместите iperf3-сервер за одним концом туннеля, а клиент за другим. Убедитесь, что тестовый сервер и оба сетевых сегмента способны передавать данные быстрее, чем вы рассчитываете получить через VPN.

2. Измерьте базовый уровень. Проверьте передачу между теми же узлами без VPN, если архитектура сети это позволяет. Запишите задержку и доступную пропускную способность: без такого сравнения сложно понять, какой предел задаёт сам маршрут.

3. Меняйте по одному параметру. Сначала сравните протоколы при одинаковом шифре, где это возможно, затем отдельно проверьте транспорт или число потоков. Не меняйте одновременно алгоритм, настройки маршрута и конфигурацию клиента.

4. Запустите одиночные и параллельные потоки. Один поток помогает оценить отдельное соединение, несколько дают представление о поведении при параллельной передаче. Число потоков и тип трафика фиксируйте вместе с результатами.

5. Смотрите не только на пропускную способность. Замеряйте задержку, потери пакетов и загрузку процессора шлюза. Высокая загрузка может указывать на ограничение вычислительных ресурсов; рост задержки при скромной загрузке требует проверить маршрут и очереди.

6. Повторите тест в обоих направлениях. Сравните передачу от клиента к серверу и обратно. Асимметрия иногда связана с маршрутизацией или ограничениями на одной стороне.

7. Запишите конфигурацию. Сохраните версии ОС и VPN-программ, параметры шифрования, сведения о доступном аппаратном ускорении и настройки теста. Иначе результаты будет трудно воспроизвести после изменения конфигурации или обновления.

Для проверки AES-NI на Linux можно посмотреть сведения о процессоре, но важно удостовериться и в том, что используемая сборка действительно применяет соответствующее ускорение. Сам факт наличия инструкции в CPU не объясняет результат теста. Его нужно сопоставить с загрузкой шлюза и поведением потока.

Такой подход позволяет отделить ограничения канала от накладных расходов VPN. Если результат почти не меняется при переходе между шифрами, но заметно зависит от транспорта, причину стоит искать не в AES-256-GCM или ChaCha20-Poly1305, а в работе туннеля и сети. Если же скорость упирается в загрузку процессора, имеет смысл проверить аппаратное ускорение, сборку программы и возможности самого шлюза.

Выбор начинается с измерений

Производительность корпоративного VPN определяется не одним шифром. На неё влияют архитектура протокола, реализация, транспорт, процессор, маршрут и настройки. Поэтому публичный спидтест годится для оценки пути до своего тестового узла, но не заменяет контролируемое сравнение шлюзов.

WireGuard может дать высокую производительность и простую криптографическую конфигурацию, но корпоративное управление доступом нужно продумать отдельно. OpenVPN остаётся гибким вариантом, а TCP-транспорт может выручить в ограниченных сетях ценой возможных задержек. IKEv2/IPsec стоит рассматривать там, где важны доступные корпоративные интеграции и поддержка перехода между сетями.

Сравнивать нужно не названия протоколов в таблице, а конкретные конфигурации на своём оборудовании. Измеряйте одинаковые маршруты, фиксируйте параметры и смотрите на задержки вместе с пропускной способностью. Тогда вопрос «как проверить сравнение скорости и шифрования» перестаёт быть спором о предпочтениях и становится инженерной задачей с воспроизводимым ответом.