WireGuard или IPsec: как выбрать VPN без догадок

Сначала сформулировать сценарий и ограничения

Вопрос «какой протокол безопаснее» редко помогает выбрать VPN. И WireGuard, и современно настроенный IPsec используют сильную криптографию; реальные различия проявляются в совместимости, управлении идентификацией, прохождении NAT, поддержке оборудования и операционной сложности. Выбор начинают с конкретного трафика и жизненного цикла доступа.

Для site-to-site фиксируют число площадок, адресные пространства, динамические внешние адреса, требования к маршрутизации и резервированию. Для удалённых сотрудников важны поддерживаемые ОС, способ выдачи и отзыва доступа, MFA, split tunneling, корпоративный DNS и управление устройствами. Наличие встроенного клиента в ОС иногда важнее удобства серверной настройки.

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

• Site-to-site, remote access или доступ отдельных сервисов.
• Чьи устройства подключаются и управляются ли они централизованно.
• Есть ли пересекающиеся подсети и NAT между сторонами.
• Нужны ли MFA, сертификаты пользователей и автоматическое истечение доступа.
• Какой простой допустим при смене ключа или внешнего адреса.

Модель WireGuard: небольшой протокол и статические peers

WireGuard связывает peer с публичным ключом и набором AllowedIPs. Один и тот же параметр участвует в выборе маршрута для исходящего трафика и проверке допустимого адреса источника для входящего. Это делает конфигурацию компактной, но требует уникальных, непротиворечивых префиксов и понимания cryptokey routing.

Протокол работает поверх UDP и использует фиксированный набор современных криптографических примитивов. Администратор не согласует наборы шифров между сторонами, поэтому исчезает целый класс ошибок negotiation. Обратная сторона — нет встроенного механизма выбора алгоритмов под старое оборудование или специальные нормативные требования.

WireGuard не является полной системой управления удалённым доступом. Он не выдаёт пользователям учётные записи, не реализует MFA, каталог устройств или автоматический отзыв ключа. Эти функции добавляет внешняя платформа, MDM, конфигурационный портал либо эксплуатационный процесс. Приватный ключ на потерянном ноутбуке остаётся действующим, пока peer не удалён на всех нужных шлюзах.

wg show
ip route show
ip -s link show dev wg0
ss -lunp | grep 51820

Модель IPsec/IKEv2: стандартный набор для разных вендоров

IPsec защищает IP-пакеты через Security Associations, а IKEv2 согласует параметры, аутентифицирует стороны и обновляет ключевой материал. Вариантов больше: сертификаты, pre-shared keys, EAP для удалённых пользователей, policy-based или route-based схемы в зависимости от реализации. Эта гибкость обеспечивает широкую совместимость, но увеличивает пространство ошибок.

Настройки обеих сторон должны совпасть по версии IKE, алгоритмам, группам Диффи — Хеллмана, lifetime, идентификаторам и traffic selectors. Формулировка «AES-256» недостаточна: режим, integrity, PRF и параметры phase 1/phase 2 тоже имеют значение. Старые примеры с IKEv1, aggressive mode, слабым DH или устаревшими хешами нельзя переносить в новую систему без оценки.

Сильная сторона IKEv2 для remote access — интеграция со встроенными клиентами ОС, сертификатами и корпоративной аутентификацией. Но конкретные возможности зависят от клиента и шлюза. Поддержка протокола на двух устройствах не гарантирует совпадение EAP-методов, split routes или способов доставки DNS.

• Использовать IKEv2, если нет обязательной совместимости с legacy IKEv1.
• Предпочитать сертификаты или уникальные длинные PSK; общий PSK усложняет отзыв одного участника.
• Сверять полный proposal и traffic selectors на обеих сторонах.
• Проверять поддержку route-based VPN конкретными платформами.

Сравнить эксплуатацию, а не длину конфигурации

У WireGuard меньше состояний и обычно проще диагностика: видны latest handshake, endpoint и переданные байты. Однако успешный handshake доказывает только криптографический обмен. Ошибка маршрута, AllowedIPs, firewall, DNS или MTU всё равно оставит приложение недоступным.

IPsec даёт больше диагностических уровней: IKE SA, Child SA, proposals, selectors и NAT traversal. Это полезно при сложной политике, но сообщения разных вендоров называют одни и те же сущности по-разному. Поддержка требует специалистов, умеющих сопоставить логи обеих сторон и пакетный захват.

Ротация ключей различается. IKE автоматически обновляет сеансовые ключи, а долгоживущая идентичность может опираться на PKI. В WireGuard протокол также обновляет сеансовый ключ, но публичный ключ peer нужно заменить административно. Массовая ручная замена конфигураций без системы распространения быстро становится операционным долгом.

Разобрать NAT, мобильность и блокировки UDP

Оба решения способны работать за NAT. WireGuard отправляет UDP на известный endpoint; peer за NAT при необходимости использует PersistentKeepalive, чтобы поддерживать отображение. Значение не следует включать бездумно на серверной стороне для всех peers: оно создаёт постоянный фоновый трафик и обычно нужно стороне за NAT, которая должна оставаться достижимой.

IKEv2 использует NAT Traversal и инкапсулирует ESP в UDP/4500, если обнаружен NAT. Межсетевые экраны должны пропускать UDP/500 и UDP/4500; прямой ESP нужен не во всех сценариях. Старые устройства и сложный carrier-grade NAT могут вести себя непредсказуемо, поэтому тест из реальной мобильной и домашней сети обязателен.

Строгая гостиничная или гостевая сеть может блокировать произвольный UDP, и тогда ни WireGuard, ни IPsec поверх UDP не дадут гарантированного подключения. Маскировка VPN под HTTPS — отдельный класс решений и компромиссов, а не переключатель этих протоколов. Нельзя обещать прохождение через любую сеть.

• Проверить туннель из мобильной сети, домашнего NAT и корпоративной гостевой сети.
• Проверить смену Wi-Fi на LTE во время активного соединения.
• Настроить keepalive только там, где истекающий NAT mapping мешает входящим пакетам.
• Не путать открытый UDP-порт с доступом к внутренним подсетям: firewall проверяется отдельно.

Маршрутизация, DNS и MTU решают больше, чем протокол

Большая часть «нестабильного VPN» связана не с криптографией. Пересекающиеся адресные пространства двух площадок делают маршрут неоднозначным; split tunnel может отправить корпоративный адрес в локальную сеть пользователя; DNS возвращает недостижимый адрес; крупные пакеты теряются из-за неверного MTU и заблокированного ICMP.

Перед внедрением составляют таблицу префиксов. В WireGuard проверяют AllowedIPs каждого peer и системные маршруты. В IPsec проверяют traffic selectors либо маршруты через VTI/XFRM-интерфейс. Full tunnel 0.0.0.0/0 и ::/0 требует отдельной настройки DNS, NAT и политики выхода в интернет; иначе пользователь потеряет связь или обойдёт корпоративный контроль.

MTU подбирают по реальному underlay и накладным расходам выбранного режима. Симптомом служит ситуация, когда ping проходит, а загрузка страницы зависает. Универсального значения для всех провайдеров нет. Сначала разрешают корректный ICMP Packet Too Big/Fragmentation Needed, затем измеряют путь и только после этого уменьшают MTU или MSS.

ping -M do -s 1380 <удалённый_IP>
tracepath <удалённый_IP>
ip route get <удалённый_IP>
resolvectl query <внутреннее_имя>
tcpdump -ni any 'udp port 51820 or udp port 500 or udp port 4500'

Команды приведены для Linux; на маршрутизаторах и Windows используйте эквивалентные средства. Размер тестового пакета зависит от семейства IP и реализации ping.

Принять решение по проверяемой матрице

WireGuard обычно рационален для управляемых Linux-серверов, небольших site-to-site соединений, лабораторий и команд, готовых автоматизировать выдачу ключей. Небольшая кодовая и конфигурационная поверхность облегчает поддержку. Это не отменяет firewall, мониторинг, инвентаризацию peers и процедуру отзыва.

IPsec/IKEv2 обычно выбирают для связи с провайдерами и аппаратными шлюзами, для встроенных корпоративных клиентов, интеграции с PKI/EAP и сред, где уже есть компетенция и стандартизированный профиль. Сложность можно ограничить утверждёнными proposals и шаблонами, не разрешая произвольный negotiation.

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

1. Отсеять варианты, которые не поддерживает обязательная сторона.
2. Проверить требования к IAM, MFA, сертификатам и отзыву.
3. Сравнить маршрутизацию, резервирование и пересекающиеся сети.
4. Собрать пилот на реальных каналах и клиентских ОС.
5. Измерить восстановление после смены адреса и обрыва связи.
6. Документировать эксплуатацию до массового развёртывания.

Проверить пилот и подготовить сопровождение

Пилот должен проверять не только скорость. Измеряют установление соединения, доступ к каждому разрешённому сегменту, запрет лишних сегментов, DNS, MTU, длительную передачу, повторное подключение и отзыв одного участника. Нагрузочный тест проводят с учётом CPU шлюза и аппаратного ускорения, не экстраполируя один поток на сотни пользователей.

Мониторинг не должен собирать приватные ключи или содержимое трафика. Достаточно состояния туннеля, времени последнего обмена, объёма, ошибок интерфейса и доступности контрольного адреса. Для IPsec наблюдают IKE/Child SA и причины negotiation failure; для WireGuard — handshake и передачу в обе стороны.

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

• Положительные и отрицательные тесты сетевого доступа.
• Отзыв одного peer или сертификата без остановки остальных.
• Восстановление после перезагрузки обоих шлюзов.
• Проверка журналов без избыточного персонального трафика.
• Актуальный владелец и срок пересмотра каждого туннеля.