OpenVPN или IKEv2: четыре проверки перед выбором протокола

Выбор между OpenVPN и IKEv2 обычно обсуждают как вопрос протокола, и такая постановка тратит решение впустую. Решает то, поддерживают ли сервер и устройства один и тот же полный профиль и переживает ли этот профиль то, как вы перемещаетесь между сетями. Два стека не переводятся друг в друга: файл OVPN не является профилем IKEv2 с другим синтаксисом. Четыре проверки, выполненные по порядку, отвечают на вопрос быстрее любой таблицы возможностей.

Отсутствующий клиент заканчивает спор

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

В Windows одна команда перечисляет уже существующие профили и показывает, какого типа каждый из них. Имя, которое она выводит, — это имя, которое используют последующие проверки.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

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

Мобильность — это совместная настройка, а не обещание протокола

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

Проверьте тот переход, который вам действительно важен, при чём-то работающем, за чем можно наблюдать. Оставьте ping -t <internal-host> работающим в Windows или простой ping в другом месте, затем переключитесь с Wi-Fi на мобильную сеть и следите за разрывами. Сбой MOBIKE в журнале клиента выглядит как полная повторная аутентификация, а не как тихое обновление адреса. Вы измеряете, переживает ли туннель изменение, а не рекламирует ли протокол поддержку.

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

Учётные данные принадлежат сервису, а не стеку

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

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

openssl x509 -in client.crt -noout -subject -issuer -dates

Для корпоративного подключения используйте метод, который публикует компания, и перестаньте относиться к сравнению как к эксперименту. Если вы сравниваете оба варианта сами, сначала проверьте, заканчиваются ли они на одном шлюзе, потому что эта единственная деталь решает, насколько ваш результат о протоколе. Отказ, в котором названы учётные данные, — это проблема учётных данных, и никакая смена протокола её не исправит.

Проверьте, что туннель на самом деле маршрутизирует

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

В Windows две команды охватывают маршрут и поиск имён. Эквиваленты в Linux — ip route show default и resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

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

После проверок взвесьте обслуживание

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

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