Выбор между OpenVPN и WireGuard для админов, DevOps и владельцев инфраструктуры на VDS — частая задача там, где важны стабильный доступ, изоляция служебного трафика, S2S-тоннели и удалённая разработка. Ниже — без религиозных войн: что быстрее на виртуалке, где проще сопровождение, как не потерять в безопасности и как мигрировать с OpenVPN на WireGuard без простоя.
Зачем вообще сравнивать OpenVPN и WireGuard на VDS
Оба решения закрывают похожие задачи: защищённый доступ к внутренним сервисам, сегментация сред (prod/stage/dev), S2S-маршрутизация между площадками и резервными узлами, шифрование трафика админских инструментов. На VDS добавляется специфика: ограниченные vCPU, NUMA и шум соседей, виртуальные сетевые стеки и драйверы, ограничение на PPS и буферы, влияние гипервизора. Поэтому «теоретические» выводы без практики на виртуалке часто не срабатывают.
Рассматриваются легитимные кейсы корпоративного и админского VPN. Мы не обсуждаем обход ограничений и иные сценарии, не соответствующие законодательству.
Архитектура и криптография
OpenVPN: гибкость за счёт сложности
OpenVPN работает в пространстве пользователя, опирается на TUN/TAP, использует TLS (1.2/1.3) для рукопожатия, позволяет выбирать наборы шифров и аутентификацию на базе сертификатов, статических ключей, плагинов и внешних бэкендов. Сильные стороны — гибкость, зрелая экосистема, поддержка TCP и UDP, возможность проходить через прокси и «говорить» на 443/TCP, что важно для корпоративных сетей с жёсткой фильтрацией.
С другой стороны, гибкость приводит к сложным конфигурациям, большему количеству кода и контекстных переключений между ядром и user space, что съедает CPU и PPS на VDS с одним–двумя vCPU.
WireGuard: простота и современный криптокод
WireGuard — компактный VPN с минималистичной моделью: статические ключи на Curve25519, обмен на основе NoiseIK, шифрование ChaCha20-Poly1305, хэши BLAKE2, встроенная защита от повторов и явная модель маршрутизации через параметр AllowedIPs. В Linux модуль интегрирован в ядро, что уменьшает накладные расходы и повышает пропускную способность и PPS. Конфигурации предсказуемы и коротки, их удобно ревьюить.
Ограничение — UDP only (дизайном исключён TCP-over-TCP, чтобы избежать деградации), нет «маскарадов» под HTTP/HTTPS без дополнительных прослоек. Зато это честная и быстрая доставка поверх UDP.
Если нужна гибкость транспорта и совместимость с прокси/443-TCP, OpenVPN часто удобнее. Если критичны скорость, простота и надёжный UDP — WireGuard даёт ощутимый выигрыш.
Производительность на VDS: где узкие места
На виртуалке всё упирается в одиночный поток шифрования, системные вызовы, эффективность работы с пакетами/буферами и виртуальные драйверы (virtio, e1000 и т. п.). В реальных сценариях на 1–2 vCPU WireGuard почти всегда быстрее за счёт работы в ядре и криптографии ChaCha20, которая оптимальна на CPU без AES-NI или при переменной частоте ядра. На 4+ vCPU преимущество WireGuard остаётся по PPS и задержкам, хотя абсолютные скорости начинают упираться в сетевые лимиты гипервизора и внешние каналы. Для подбора мощности хоста посмотрите материал про как выбрать план VDS: CPU и RAM.
Практически важны не только мегабиты, но и латентность под нагрузкой: поведение при 8–32 параллельных потоках, стабильность RTT при заполненных буферах, реакция на потерю пакетов. WireGuard обычно держит ниже джиттер, OpenVPN — более чувствителен к перегрузке очередей при TCP-режиме.
UDP vs TCP
OpenVPN может работать по TCP. Это спасает за NAT и в сетях с запретом UDP, но вносит двойную надёжность и Nagle/ACK-поведение внутрь туннеля. На высоких задержках TCP-over-TCP даёт эффект «фаршмак»: падение пропускной способности при потере пакетов. В UDP-режиме OpenVPN улучшает картину, но всё ещё тратит больше CPU.
MTU, MSS и фрагментация
Неправильная MTU — источник «мистических» подвисаний. Для WireGuard практичной отправной точкой считается MTU 1280–1420 в зависимости от провайдера и наличия дополнительных оверхедов (например, внутри облачных балансировщиков). Для OpenVPN с TUN + UDP типично 1400–1500, с TCP — ниже. Проверяйте PMTUD и при необходимости используйте принудительное занижение MTU и MSS-clamp на граничных правилах.
Системный тюнинг под VPN
На VDS полезны:
- Увеличенные UDP-буферы (
net.core.rmem_max,net.core.wmem_max). - Тонкая настройка
txqueuelenинтерфейсов и qdisc (например, fq_codel) для сглаживания задержек. - Отключение лишних offload-фич, если наблюдается аномальный джиттер.
- Фиксация частоты CPU и планировщика при нагрузочных тестах, чтобы убрать «дрожание» частоты.
Безопасность и эксплуатация
Модель доверия и управление ключами
OpenVPN использует инфраструктуру сертификатов: удобно для централизованной выдачи/отзыва, CRL/OCSP, сроков действия и атрибутов. Это отлично ложится на корпоративные процессы, но усложняет развёртывание и требует ведения PKI.
WireGuard опирается на статические пары ключей. Это проще и быстрее, но отзыв ключа — это изменение конфигурации на сервере/пирах (удаление публичного ключа и связанного AllowedIPs) и распространение новых настроек. Для небольших инсталляций это плюс. В крупных инфраструктурах потребуется обвязка для ротации и инвентаризации.
Криптоустойчивость и шифры
WireGuard поставляется с современным набором (Curve25519, ChaCha20-Poly1305, BLAKE2s) без «зоопарка» и уязвимых опций. OpenVPN поддерживает TLS 1.3 и AEAD-шифры (AES-GCM, ChaCha20-Poly1305), но сохраняет обратную совместимость, которую важно ограничить жёсткими профилями. Простота WireGuard снижает риск неправильной конфигурации.
Поверхность атаки и обновления
WireGuard как модуль ядра имеет меньше контекстных переключений и сравнительно небольшой код. Но любые уязвимости ядра — критичны и требуют своевременных обновлений. OpenVPN в user space легче изолировать окружением и ограничениями, но сам бинарь объёмнее и зависит от OpenSSL/mbedTLS.
DOS и ограничение рукопожатий
Оба протокола имеют механизмы ограничений. WireGuard использует дизайн рукопожатия Noise и ограничивает попытки анонимных хэндшейков. OpenVPN можно прикрыть rate-limit на брандмауэре, а также вынести на фронт балансировщик с UDP-фильтрацией (см. стрим-балансировщик Nginx для TCP/UDP). На VDS важно не позволять рукопожатиям «съедать» одиночный vCPU.
Логирование, приватность и соответствие требованиям
Для аудита OpenVPN предлагает привычные журналы, события TLS и детали клиентов. WireGuard журналирует минимально, акцент на текущее состояние пиров и счётчики. Если нужен детальный аудит с привязкой к сертификатам и срокам, OpenVPN иногда удобнее. Если требования — минимизация логов и простота, WireGuard выигрывает.
Функциональные различия, влияющие на выбор
- Роуминг и смена IP: WireGuard быстро «подхватывает» новые IP клиента без перераздачи адресов; удобно для ноутбуков и мобильных.
- Работа за строгими прокси: OpenVPN по TCP/443 часто проходит, где UDP запрещён. WireGuard — UDP only; потребуется сетевой обходной путь на уровне инфраструктуры.
- Site-to-Site: Оба справляются. WireGuard проще в статической маршрутизации через
AllowedIPs. OpenVPN гнётся под BGP/OSPF через доп. софт. - IPv6: Оба поддерживают; в WireGuard добавление v6-подсетей проще декларативно.
- Split/full tunnel: Оба поддерживают; в OpenVPN — через push-опции сервера, в WireGuard — на стороне клиента через списки префиксов.
Что выбрать: краткие практические критерии
- Нужна максимальная скорость на 1–2 vCPU, минимум сложности, чистый UDP — берите WireGuard.
- Нужен проход через корпоративные прокси/443-TCP, строгая PKI и привычные журналы — оставайтесь на OpenVPN.
- Гибрид: для админского доступа и S2S — WireGuard; для внешних подрядчиков за прокси — OpenVPN.
Миграция с OpenVPN на WireGuard без простоя
Рабочая стратегия — параллельный запуск. Сначала поднимаем WireGuard на новых портах и другой подсети, переводим пилотную группу, убеждаемся, что маршрутизация и ACL соответствуют ожиданиям, затем волнами переносим остальных и выключаем OpenVPN.
Шаги миграции
- Аудит адресного плана и правил фаервола. Определяем подсети для туннелей WireGuard (например, 10.20.0.0/24) и сопоставление с текущими маршрутами OpenVPN.
- Поднимаем сервер WireGuard параллельно с OpenVPN на другом UDP-порту. Настраиваем отдельный интерфейс (например,
wg0). - Прописываем правила брандмауэра: разрешаем новый порт/протокол UDP, настраиваем межсегментные ACL аналогично текущим.
- Готовим клиентские конфиги для пилотной группы. Проверяем split/full tunnel, DNS, доступ к сервисам, производительность.
- Настраиваем мониторинг: метрики интерфейсов, RTT по ICMP, ошибки и дропы, системные логи.
- Постепенно переводим оставшихся клиентов. На время миграции поддерживаем маршруты в обе стороны, чтобы исключить «чёрные дыры».
- После перевода — выключаем OpenVPN, чистим правила и артефакты, фиксируем документацию.
Скелет конфигурации WireGuard (сервер)
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.20.0.1/24
ListenPort = 51820
PrivateKey = <server_private_key>
# Опционально: снижаем MTU при необходимости
MTU = 1420
# Пример пира (клиента)
[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.20.0.10/32
PersistentKeepalive = 25
Скелет конфигурации WireGuard (клиент)
# wg0.conf на клиенте
[Interface]
Address = 10.20.0.10/32
PrivateKey = <client_private_key>
DNS = 10.20.0.1
[Peer]
PublicKey = <server_public_key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.20.0.0/24, 192.168.10.0/24
PersistentKeepalive = 25
Сетевые префиксы в AllowedIPs на стороне клиента определяют, какой трафик пойдёт в туннель: это и есть split/full tunnel в терминах WireGuard.
Сервисные команды (Debian/Ubuntu)
apt update
apt install wireguard
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub
chmod 600 /etc/wireguard/server.key
systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0
wg show
Миграция маршрутов и политик
Чтобы исключить прерывание связности S2S, временно анонсируйте одни и те же подсети через оба туннеля, но с приоритетом WireGuard. Если динамической маршрутизации нет, приоритизируйте статические маршруты по метрике (в Linux — через таблицы маршрутизации и policy routing). После переключения клиентов — удалите дублирующие маршруты из OpenVPN, закрыв «дырки» в ACL.
Измерения и проверка качества
Не верьте абстрактным «в 3 раза быстрее» без собственных тестов. Минимальный набор измерений:
- Скорость TCP/UDP с многопоточностью —
iperf3в обе стороны, 1, 4, 16 потоков. - RTT и джиттер под нагрузкой —
pingиmtrпри запущенном iperf. - PPS и дропы — счётчики интерфейсов,
ethtool -Sпри наличии, системные логи. - Стабильность MTU — проверка «самого большого не фрагментируемого» пакета.
# Примеры
iperf3 -s
iperf3 -c 10.20.0.1 -P 4 -t 60
ping -c 100 10.20.0.1
mtr -rw 10.20.0.1
Частые ошибки и как их избегать
- Неправильный MTU: если подвисают крупные файлы — начните с MTU 1420 и протестируйте, затем увеличивайте.
- Неполные
AllowedIPs: в WireGuard это и фильтр, и источники маршрутов. Префиксы должны покрывать всё, что хотите видеть в туннеле. - Дублирующиеся маршруты при параллельной работе OpenVPN и WireGuard: используйте метрики и policy routing.
- UDP заблокирован на периметре: для WireGuard потребуется сетевое решение на инфраструктурном уровне; «заворачивать» в TCP не рекомендуется.
- Недостаточные буферы: увеличьте
rmem/wmemи проверьте qdisc. Следите за нагрузкой на одиночный vCPU. - Слабая ротация ключей: заведите регулярную процедуру перевыпуска и инвентаризации пиров.
Краткая памятка по соответствию и правовым аспектам
Используйте VPN для легитимных задач: админский доступ, сегментация, защита служебного трафика, межсайтовые связи. Учитывайте внутренние политики безопасности, требования к журналированию и хранению данных. Для внешних пользователей с жёсткими прокси-сетями может потребоваться OpenVPN по TCP; для внутренних S2S и админов — WireGuard чаще предпочтительнее по скорости и простоте.
Итоги
На VDS WireGuard в большинстве сценариев обеспечивает лучшую производительность и предсказуемую задержку при меньшей сложности конфигурации и сопровождения. OpenVPN остаётся сильным выбором, когда требуется транспорт по TCP/443, строгая PKI и совместимость с корпоративной инфраструктурой. Оптимальная стратегия — параллельный запуск, пилотная миграция, измерения под реальной нагрузкой и постепенное отключение старого стека — так вы получите прирост скорости и уменьшение операционных рисков без простоя.
