
Выбор VPN часто начинают с вопроса, какой протокол быстрее. Для корпоративной сети этого недостаточно. Сотруднику нужен удобный вход с управляемого ноутбука и второй фактор, филиалу — стабильная маршрутизация между площадками, администратору — индивидуальный доступ к определённым серверам. У одного и того же протокола эти задачи решаются разными продуктами и политиками.
Сначала определяют архитектуру доступа, затем протокол и реализацию. Нельзя сравнивать только названия: WireGuard — протокол и инструменты туннеля, OpenVPN Community и OpenVPN Access Server — разные варианты эксплуатации, IPsec входит в множество шлюзов, а «SSL VPN» может обозначать и сетевой клиент, и портал отдельных приложений. Разберём различия, ограничения и испытания, которые стоит провести до внедрения.
Виды VPN: кто с кем соединяется
В remote access отдельный компьютер подключается к корпоративному шлюзу. Участником может быть пользователь, устройство или их сочетание. Обычно нужны выдача адреса, маршрутов и DNS, а также политика того, какие приложения разрешены. Доступ администратора полезно отделить от доступа обычного сотрудника: они различаются назначениями, временем работы и требованиями к журналам.
В site-to-site соединяются сети двух площадок. Клиенты внутри филиала могут вообще не знать о туннеле: маршрут на другой офис выбирает их шлюз. Тут важно заранее согласовать адресные пространства, отказоустойчивость, время восстановления и маршрутизацию. Совпадение подсетей двух площадок нельзя исправить сменой алгоритма шифрования.
| Архитектура | Участники | Главные требования |
|---|---|---|
| Remote access | Рабочее устройство и шлюз | Индивидуальный вход, роли, MFA, DNS, отзыв |
| Site-to-site | Шлюзы площадок | Маршруты, согласованные префиксы, отказоустойчивость |
| Host-to-host | Два определённых узла | Минимальная область доступа и управление ключами |
| Hub-and-spoke | Центральный узел и филиалы | Производительность центра и межфилиальные политики |
| Mesh | Много взаимосвязанных узлов | Контроль участников, маршрутов и масштаба |
| Портал приложений | Пользователь и опубликованные сервисы | Разрешения конкретных приложений и сессий |
Последний вариант не обязательно даёт полноценный IP-доступ. Если подрядчику нужен только один веб-сервис, портал или ресурсный доступ может быть удобнее выдачи маршрутов к внутренней сети. Продукты ZTNA тоже нужно оценивать по реальной политике ресурса и состоянию устройства: новое название само по себе не отменяет необходимость доверенного клиента и защищённого приложения.
Сравнение транспорта, идентичности и эксплуатации
| Решение | Передача данных | Идентичность | Где обычно применяют | Что проверить заранее |
|---|---|---|---|---|
| WireGuard | UDP, порт настраиваемый | Публичный ключ peer | Узлы, филиалы, управляемые клиенты | Выдача и отзыв ключей, роли, MFA внешним механизмом |
| OpenVPN | UDP или TCP | Обычно сертификаты, дополнительные методы реализации | Удалённые сотрудники, разнородные ОС | Клиенты, PKI, плагины или сервер управления |
| IPsec с IKEv2 | ESP; обычно UDP 500/4500 для IKE и NAT-T | Сертификат, PSK, EAP по реализации | Шлюзы площадок, нативные клиенты | Совместимость предложений, идентификаторов и политик |
| SSTP | TLS поверх TCP, обычно 443 | Сертификат сервера и аутентификация PPP | Определённые Windows-сценарии | Поддержка платформы и ограничения TCP |
| L2TP/IPsec | L2TP защищён IPsec | PPP и параметры IPsec | Существующая совместимость | Срок поддержки, общий PSK, NAT |
| PPTP | TCP 1723 и GRE | Устаревшие схемы PPP | Исторические установки | План замены; для нового защищённого доступа не выбирать |
| GRE, IP-in-IP, VXLAN | Инкапсуляция без обязательной защиты | Зависит от окружения | Сетевой overlay | Не считать шифрованием; отдельная защита пути |
Порт 443 не делает любой туннель неотличимым от обычного HTTPS и не гарантирует прохождение через прокси или DPI. UDP 51820 — распространённый пример WireGuard, а не обязательный порт протокола. ESP — IP-протокол 50, а GRE — IP-протокол 47; это не TCP-порты. Если устройство или провайдер фильтрует IP-протоколы, открытие одноимённых TCP-портов ничего не исправит.
Ни один протокол не гарантирует максимальную скорость на любом устройстве. Одинаковая конфигурация на x86 и небольшом маршрутизаторе может дать разные результаты из-за процессора, драйвера, ускорения и реализации. «Поддерживает IPsec» в спецификации оборудования также не означает, что он совместим со всеми профилями конкретного партнёра.
WireGuard: простой туннель, но не готовая система управления сотрудниками
WireGuard связывает публичный ключ участника с разрешёнными внутренними адресами. При отправке эта связь помогает выбрать peer для назначения; при получении проверяется, что внутренний источник соответствует авторизованному участнику. Это не заменяет межсетевые правила портов: право использовать адрес не равно праву подключаться к любой базе данных. Модель описана в документации WireGuard.
В Linux состояние конкретного интерфейса можно посмотреть без вывода приватного ключа:
sudo wg show wg0
ip -br address show dev wg0
ip route get 10.20.0.15
Ожидают нужный peer, актуальный handshake при наличии обмена и рост счётчиков передачи. WireGuard не поддерживает постоянную «сессию подключения» в том же смысле, что многие пользовательские клиенты: отсутствие недавнего handshake у неактивного участника не всегда означает неисправность. Проверку выполняют вместе с реальным трафиком. Не публикуйте wg showconf в заявке: конфигурация может содержать приватные ключи.
У peer на стороне корпоративного шлюза обычно задают адрес конкретного клиента /32 и, если необходимо, согласованные сети за ним. На клиенте AllowedIPs может включать корпоративный префикс, например 10.20.0.0/16. Это фрагмент настройки peer, а не полная готовая конфигурация:
[Peer]
PublicKey = REPLACE_WITH_GATEWAY_PUBLIC_KEY
Endpoint = vpn.example:51820
AllowedIPs = 10.20.0.0/16
PersistentKeepalive = 25
Публичный ключ нужно заменить фактическим. PersistentKeepalive помогает сохранять NAT-сопоставление для участника, которому нужен приём после простоя; 25 секунд — распространённый пример, не обязательное значение для всех. Назначение параметра показано в Quick Start WireGuard.
Для компании отдельно нужны инвентаризация владельцев ключей, доставка конфигураций, отзыв потерянного устройства и ограничение доступа. Управляющая платформа может добавить SSO и проверку устройства, но это возможности платформы, а не встроенная форма MFA в протоколе WireGuard. Если процесс выдачи и отзыва отсутствует, небольшой конфиг становится неудобным при сотнях сотрудников.
OpenVPN: гибкость клиента и стоимость сопровождения PKI
OpenVPN может передавать данные через UDP или TCP. Для обычного IP-трафика сначала оценивают UDP: вложение TCP-соединения в TCP-туннель создаёт два механизма повторов и контроля потока. При потерях это способно ухудшить задержку и скорость. TCP остаётся вариантом для среды, где UDP недоступен, но его не стоит объявлять универсально более надёжным для всех приложений.
Ниже параметры клиента, показывающие транспорт и проверку роли сервера. Они не являются полным профилем: доверенный CA, сертификат, приватный ключ, имя сервера и политика выдаются администратором.
client
dev tun
proto udp
remote vpn.example 1194
remote-cert-tls server
verify-x509-name vpn.example name
verify-x509-name должен соответствовать фактической идентичности сертификата вашего сервера, а не произвольному DNS из примера. У клиента должна быть доверенная цепочка; не устраняйте ошибку сертификата отключением проверки. Различия транспорта и параметров TLS разобраны в руководстве OpenVPN 2.6.
Интеграция с каталогом, MFA и выдачей ролей зависит от серверного продукта, плагинов и настройки. При выборе задайте конкретные вопросы: как отзывается пользовательский сертификат, где хранится CRL, как заблокировать потерянное устройство, остаётся ли действующим активный сеанс после блокировки и кто обновляет клиент. Общий сертификат на всех лишает систему индивидуальной идентификации.
Ускорение передачи, включая DCO, проверяют на сочетании сервера, клиента, ОС и выбранной конфигурации. Наличие пункта в рекламе не гарантирует, что он активен с вашими параметрами. Для старых клиентов отдельно проверяют совместимость шифров и миграцию: ослабление общего сервера ради одного устаревшего устройства обычно создаёт долгосрочный долг сопровождения.
IPsec и IKEv2: договориться должны обе стороны
IPsec защищает IP-трафик, а IKEv2 аутентифицирует стороны и создаёт согласованные параметры защиты. Различают IKE SA для управляющего обмена и CHILD SA для защищаемых данных. Поэтому «IKE established» ещё не означает, что нужный прикладной трафик проходит. Назначение IKEv2 и согласование описаны в RFC 7296.
При соединении устройств разных производителей согласуйте идентификаторы сторон, методы аутентификации, алгоритмы, группы обмена, времена обновления и защищаемые сети. При NAT обычно применяется UDP-инкапсуляция ESP на 4500; на внешнем пути должны проходить нужные протоколы. Общий PSK для многочисленных сотрудников усложняет индивидуальный отзыв: замена секрета затронет всех его владельцев.
В policy-based VPN трафик выбирают селекторы. В route-based VPN маршрутизация направляет пакет в соответствующий интерфейс, но политика IPsec и параметры SA всё равно должны совпадать. У strongSwan для Linux доступны XFRM-интерфейсы; их назначение и ограничения описаны в руководстве route-based VPN.
На Linux-шлюзе с strongSwan и swanctl:
sudo swanctl --list-sas
sudo ip -s xfrm state
sudo ip xfrm policy
ip route get 10.30.0.15
Первый вывод показывает установленные связи и CHILD SA. Счётчики XFRM помогают понять, есть ли защищаемый обмен; политики — какие адреса он охватывает. Не публикуйте полный ip xfrm state без обработки: он может содержать ключевой материал. Проверяйте в закрытом сеансе и передавайте только необходимые обезличенные сведения. Команда swanctl не подходит к любой установке IPsec: другой продукт имеет свой интерфейс состояния.
Устаревшие варианты и ограничения платформ
PPTP не следует выбирать для нового защищённого корпоративного доступа. L2TP сам по себе не шифрует данные; в распространённой комбинации шифрование обеспечивает IPsec. SSTP использует TLS поверх TCP и может быть полезен для определённых Windows-сценариев, но поддержка конкретного продукта важнее наличия протокола в старой таблице.
Microsoft изменила поведение новых конфигураций RRAS в Windows Server 2025 для PPTP и L2TP; существующие сценарии и миграция описаны в документации настройки протоколов RRAS. Не переносите список включённых по умолчанию протоколов из Windows Server предыдущего поколения.
Есть и отдельное облачное ограничение: в Azure VPN Gateway новые включения SSTP больше не поддерживаются с 31 августа 2026 года, а прекращение существующих подключений запланировано на 31 марта 2027 года. Это относится к данному сервису, а не означает исчезновение SSTP из всех маршрутизаторов. Официальный план миграции Azure предлагает переход на IKEv2 или OpenVPN.
GRE и VXLAN нужны для других задач инкапсуляции. Передача Ethernet в UDP полезна для overlay-сети, но не является обещанием конфиденциальности в Интернете. RFC 7348 описывает VXLAN как механизм виртуального L2 поверх L3. Если проект требует защищённого канала, выбирайте отдельный механизм защиты, а не считайте любые вложенные пакеты зашифрованными.

Как выбрать решение для сотрудников и филиалов
| Задача | Кандидаты для проверки | Решающий критерий |
|---|---|---|
| Филиалы с разными шлюзами | IPsec/IKEv2, поддерживаемый WireGuard | Межвендорная совместимость и восстановление маршрутов |
| Ноутбуки с MFA и каталогом | Управляемый OpenVPN или IKEv2-продукт | Жизненный цикл пользователей и клиентских профилей |
| Несколько администраторских узлов | WireGuard, сертификатный IPsec/OpenVPN | Узкие роли и индивидуальный отзыв |
| Ограниченный внешний транспорт | Поддерживаемый TLS/TCP-вариант | Реальное прохождение через прокси и допустимая задержка |
| Один сервис для подрядчика | Ресурсный шлюз или портал | Отсутствие лишнего сетевого доступа |
| Регламентированная защита | Решение с требуемыми подтверждениями | Проверенные требования проекта и возможности поставки |
Конкретные реализации тоже различаются. MikroTik RouterOS реализует несколько VPN-механизмов, но возможности конкретной версии и аппаратной модели проверяют отдельно. strongSwan — реализация IPsec для Linux, а WireGuard tools не предоставляет полный корпоративный портал управления. OpenVPN Access Server и Community отличаются системой управления. На коммерческих NGFW интеграция с каталогом, MFA, HA и лицензирование могут быть частью продукта или отдельной опцией. Список названий вендоров не заменяет проверку выбранной поставки.
Сначала запишите число пользователей, ОС устройств, количество площадок, необходимые сети, требуемый второй фактор, пропускную способность и допустимое время восстановления. Например: 80 управляемых ноутбуков Windows, 10 macOS, доступ к двум подсетям, индивидуальный отзыв за согласованное время, резервный шлюз и сохранение доступа после смены Wi-Fi. Это уже измеримое задание для пилота; фраза «быстрый и безопасный VPN» — ещё нет.
Провести пилот, который покажет реальные различия
Установите кандидатов в одинаковых условиях: те же шлюзы или сопоставимые ресурсы, канал, клиент, алгоритмы и измеряемое приложение. Отдельно фиксируйте ускорение обработки и нагрузку CPU. Для контролируемого теста скорости на внутреннем тестовом сервере можно использовать iperf3; ограничьте доступ к его порту тестовой сетью.
iperf3 -s -B 10.20.0.50
С тестового клиента выполните последовательные измерения:
iperf3 -c 10.20.0.50 -t 30
iperf3 -c 10.20.0.50 -t 30 -R
iperf3 -c 10.20.0.50 -t 30 -P 4
-R проверяет обратное направление, -P 4 — четыре потока. Многопоточный тест не заменяет однопоточный: реальное приложение может передавать данные по одному соединению. Повторяйте измерения и фиксируйте RTT, потери и загрузку, а не выбирайте лучший случайный результат. Учтите влияние дисков и сервера приложения при тестировании реального файла.
Затем проверьте смену сети, простой за NAT, разрыв транспорта, отключение пользователя, отзыв сертификата или ключа и отказ основного шлюза. В full tunnel отдельно проверяют DNS, IPv6 и поведение после обрыва. В site-to-site — оба направления маршрута и доступ только к разрешённым префиксам. При смене протокола клиентам может потребоваться новый профиль: такой переход нельзя считать прозрачным заранее.
Сравнивайте не только мегабиты, но и время выдачи доступа, количество ручных операций, качество журналов, управляемость клиента и план обновлений. Матрица пилота VPN позволяет записать одинаковые испытания для кандидатов. Подходящий протокол — тот, который вместе с выбранной реализацией выполняет ваши требования и остаётся понятным при обслуживании, отзыве доступа и аварии.
