IKEv2 или L2TP: что выбрать для VPN

MAATRIX

Оба протокола опираются на IPsec и на первый взгляд похожи: тот же набор алгоритмов шифрования, та же логика туннеля, похожие требования к серверу. Но на практике они ведут себя по-разному в трёх ситуациях, которые определяют комфорт использования VPN каждый день — при переключении между Wi-Fi и мобильной сетью, при подключении из-за NAT провайдера и при выборе клиента на телефоне. Разберём, чем они отличаются технически и когда какой протокол разумнее развернуть на сервере.

Что технически отличает IKEv2 от L2TP/IPsec

L2TP (Layer 2 Tunneling Protocol) сам по себе не шифрует трафик — он только инкапсулирует кадры второго уровня. Шифрование добавляет IPsec поверх, поэтому связка всегда называется L2TP/IPsec: сначала поднимается IPsec SA (обычно в режиме IKEv1 с pre-shared key или сертификатами), а внутри него уже работает L2TP-туннель со своим согласованием (UDP 1701). Получается двойная инкапсуляция — L2TP-заголовок внутри IPsec ESP-пакета, что даёт заметный оверхед по сравнению с чистым IPsec-решением.

IKEv2 (Internet Key Exchange v2) — это протокол согласования ключей нового поколения, который работает напрямую с IPsec без промежуточного L2TP-слоя. Туннель строится за один обмен сообщениями (в IKEv1 их было больше), а главное отличие — встроенная поддержка MOBIKE (RFC 4555), которая позволяет клиенту менять IP-адрес без разрыва туннеля.

L2TP/IPsec:  Клиент → UDP 500 (IKE) → UDP 4500 (NAT-T) → UDP 1701 (L2TP) → PPP
IKEv2:       Клиент → UDP 500 (IKE) → UDP 4500 (NAT-T/данные) → ESP

На сервере это выражается в разном наборе демонов: для IKEv2 достаточно strongSwan (или libreswan) без дополнительных пакетов, для L2TP/IPsec нужен ещё xl2tpd или аналог плюс pppd для аутентификации на уровне PPP.

Скорость переподключения при смене сети

Это ключевое отличие для мобильного использования. Когда вы выходите из дома с Wi-Fi на LTE, у устройства меняется IP-адрес — и туннель должен либо адаптироваться, либо пересобраться с нуля.

IKEv2 с MOBIKE отслеживает смену адреса на уровне IKE_SA: клиент отправляет INFORMATIONAL-сообщение с новым адресом, сервер обновляет привязку — и туннель продолжает работать без пересогласования ключей. На практике это ощущается как переход без разрыва соединений: активная SSH-сессия или загрузка файла не рвётся.

В strongSwan MOBIKE включён по умолчанию для IKEv2, но стоит явно проверить в конфиге:

# /etc/ipsec.conf
conn ikev2-vpn
    keyexchange=ikev2
    mobike=yes
    rekey=yes
    dpdaction=restart
    dpddelay=30s

L2TP/IPsec такого механизма не имеет. Смена IP-адреса клиента ломает существующую IPsec SA — приложению приходится заново проходить IKE-обмен, поднимать L2TP-туннель и PPP-сессию поверх него. На мобильных сетях с частыми переключениями между вышками это выливается в разрывы на 3-8 секунд при каждой смене сети, а не только при переходе Wi-Fi ↔ LTE.

Если VPN нужен в основном на телефоне, который двигается между сетями, MOBIKE в IKEv2 — не второстепенная деталь, а определяющий фактор.

Поддержка в мобильных и десктопных ОС «из коробки»

Оба протокола давно встроены в основные ОС без сторонних приложений, но реализации отличаются зрелостью.

Нюанс с Android важен: голый IKEv2 без стороннего клиента система поддерживает не всегда одинаково в разных прошивках производителей, и надёжнее ставить отдельное приложение — этот вариант разобран в статье про встроенный IKEv2-клиент Android. L2TP/IPsec, наоборот, на Android обычно заводится через штатные настройки без установки чего-либо — это его сильная сторона там, где нельзя ставить приложения (корпоративные MDM-политики, ограниченные учётки).

На Windows оба варианта нативные, но именно L2TP/IPsec на Windows чаще требует правки реестра из-за NAT — об этом отдельно ниже.

Устойчивость к NAT и мобильным сетям операторов

NAT — это, пожалуй, вторая по значимости причина выбирать между протоколами, особенно если сервер или клиент сидят за симметричным NAT оператора мобильной связи.

IKEv2 изначально проектировался с учётом того, что клиент почти всегда находится за NAT. NAT-T (NAT Traversal, RFC 3947) встроен в протокол с момента его появления, включается автоматически при обнаружении трансляции адресов и переключает весь трафик, включая IKE, на UDP 4500. В сочетании с MOBIKE это даёт устойчивое соединение даже при двойном NAT (оператор + домашний роутер).

L2TP/IPsec с NAT-T тоже работает, но исторически это была надстройка над протоколом, изначально не рассчитанным на трансляцию адресов, и именно тут чаще всего возникают практические проблемы:

• Windows по умолчанию блокирует L2TP/IPsec-подключения через NAT, если клиент тоже находится за NAT (не сервер, а именно клиент) — нужно явно править реестр:

# Windows: разрешить L2TP/IPsec клиенту за NAT
# Путь в реестре:
# HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
# Параметр DWORD: AssumeUDPEncapsulationContextOnSendRule
# Значение: 2
# После правки — обязательна перезагрузка

• Часть мобильных операторов блокирует или режет UDP 500/1701, оставляя только 4500 — L2TP/IPsec в таком случае может не подняться вовсе, тогда как IKEv2 после первого NAT-T перехода использует только 4500 и продолжает работать.
• Двойной NAT (оператор ставит CGNAT, а телефон ещё и в роуминге) чаще ломает L2TP-сессию, потому что PPP-уровень внутри туннеля чувствителен к задержкам пересборки соединения.

Если у вас сервер в аренде и вы настраиваете именно IKEv2, пошаговая установка strongSwan на Ubuntu 24.04 разобрана в статье IKEv2 на strongSwan: пошаговая установка, а для L2TP/IPsec — аналогичная инструкция L2TP/IPsec на Ubuntu 24.04: пошаговая установка.

Безопасность шифрования

Криптографически оба протокола используют один и тот же стек IPsec (ESP, IKE), поэтому набор доступных алгоритмов шифрования у них общий: AES-128/256-GCM, AES-CBC, ChaCha20-Poly1305 в современных реализациях strongSwan, Diffie-Hellman группы вплоть до Curve25519. Разница не в «силе» шифра, а в том, как согласуются ключи и какие режимы аутентификации приняты по умолчанию.

IKEv2 обычно настраивают с сертификатной аутентификацией (X.509), что снимает целый класс атак, связанных с общим PSK. Пример современного набора шифров в ipsec.conf:

conn ikev2-vpn
    keyexchange=ikev2
    ike=aes256gcm16-prfsha384-ecp384!
    esp=aes256gcm16-ecp384!
    leftauth=pubkey
    rightauth=pubkey

L2TP/IPsec в подавляющем большинстве развёртываний использует pre-shared key (PSK) для фазы IPsec — это исторически самое узкое место протокола. Общий ключ, известный всем клиентам, теоретически позволяет провести атаку "человек посередине" при компрометации ключа, а PPP-аутентификация поверх (MSCHAPv2) добавляет ещё один слой, который в прошлом был объектом критики со стороны исследователей безопасности за слабую защиту от офлайн-перебора хэшей при перехваченном трафике. На практике при использовании длинного случайного PSK и современных ограничений (fail2ban, ограничение количества попыток) риск невысок, но сама архитектура менее строгая, чем сертификатная схема IKEv2.

Если сервер поднимается для нескольких пользователей с разными сертификатами (а не общим ключом), стоит посмотреть настройку IKEv2 с несколькими пользователями через сертификаты strongSwan — это закрывает основной риск L2TP/IPsec архитектурно, а не только на уровне «сложного пароля».

Как выбрать: сравнение и сценарии

Сведём практические критерии в одну таблицу — она пригодится, если нужно быстро аргументировать выбор коллегам или себе через полгода.

Из этого вытекают практические рекомендации:

• Ноутбук или телефон, который часто меняет сети (общественный транспорт, переезды между офисом и домом) — берите IKEv2 ради MOBIKE, разница в стабильности ощущается ежедневно.
• Корпоративная среда с MDM, где нельзя ставить сторонние VPN-приложения на Android — L2TP/IPsec может оказаться практичнее из-за встроенной поддержки без установки клиента.
• Максимальная защита ключей и много пользователей — IKEv2 с сертификатной аутентификацией: компрометация одного клиента не даёт доступа ко всем остальным, в отличие от общего PSK.
• Простое разовое подключение с редких мест без роуминга (например, статичный домашний офис) — разница между протоколами в этом сценарии минимальна, можно выбирать по тому, какой клиент уже настроен.
• Если вы ещё не определились с самим протоколом верхнего уровня, а не только с парой IKEv2/L2TP, полезно заглянуть в сравнение WireGuard и OpenVPN — оба варианта проще в развёртывании и не тянут за собой легаси L2TP-слоя, но требуют установки клиентского приложения на большинстве платформ, чего не требуют IKEv2 и L2TP/IPsec.

Частые вопросы