Эти два названия стоят рядом в одном выпадающем списке, что подталкивает к выбору между равными. Они не равны. L2TP — это протокол туннелирования без собственной конфиденциальности, а защита в сервисе L2TP/IPsec приходит от слоя IPsec, который его оборачивает. IKEv2 напрямую согласует IPsec-ассоциацию и не имеет шага «туннель внутри туннеля». Знание того, какой стек предлагает ваш сервер, определяет профиль, запросы и то, что произойдёт, когда ноутбук сменит сеть.

Два стека, одна метка в клиенте

L2TP переносит сеанс «точка-точка» по UDP на порт 1701 и оставляет шифрование тому, кто его оборачивает. Соедините его с IPsec, и вы получите два слоя: IPsec-ассоциацию, защищающую путь, и внутри неё сеанс L2TP, переносящий кадры канального уровня пользователя и аутентификацию PPP.

IKEv2 создаёт управляющую ассоциацию, а затем одну или несколько дочерних ассоциаций, защищающих трафик, — всё в одном семействе обменов на UDP 500 и 4500. Внутреннего протокола туннелирования и переговоров PPP нет.

Учётные данные: три секрета на трёх слоях

Именно здесь исчезает большая часть времени поддержки. Профиль L2TP/IPsec может запросить предварительно разделённый ключ для слоя IPsec и имя пользователя с паролем для внутреннего сеанса PPP, и то и другое проверяют разные компоненты. Общий ключ принадлежит шлюзу целиком, поэтому он никого не идентифицирует; он лишь доказывает, что вторая сторона знает секрет.

IKEv2 обычно использует сертификаты или EAP с именем пользователя и паролем, а также может использовать предварительно разделённый ключ. Эти варианты не взаимозаменяемы с парой L2TP. Сброс пароля, который исправляет отклонённый вход по EAP, ничего не делает для истёкшего клиентского сертификата, и сколько бы раз вы ни вводили пароль учётной записи заново, неверный ключ шлюза он не удовлетворит. Когда появляется запрос, которого вы не ждали, спросите оператора, какому слою он принадлежит, прежде чем гадать.

QuestionL2TP/IPsecIKEv2
What encrypts the trafficA wrapping IPsec associationThe child association
Ports you must permitUDP 500/4500 and UDP 1701 insideUDP 500 and 4500
Typical secretsGateway PSK plus PPP credentialsCertificate, EAP, or PSK
Address changeTunnel breaks, reconnect neededCan migrate with MOBIKE

Что меняет MOBIKE, а что нет

IKEv2 может перенести ассоциацию на новый адрес, если оба конца поддерживают MOBIKE, что покрывает случай, когда ноутбук уходит с Wi-Fi в точку доступа телефона, не разрывая ассоциацию безопасности.

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

Формы отказа, которые их разделяют

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

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

Где каждый ещё уместен

L2TP/IPsec держится, потому что он есть почти на каждом клиенте и не требует дополнительного ПО, что важно для подрядчика на устройстве, которым вы не управляете. Цена — лишний слой, модель общего секрета и переподключение после каждой смены адреса.

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

Проверка выданного вам профиля

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

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

Похожие статьи