Два приложения для iPhone могут оба добавить запись VPN в Настройках, оба называть себя VPN-клиентами и почти не иметь общей реализации. Apple называет одну из таких интеграций Личным VPN, и именно это имя порождает большую часть путаницы. Личный VPN — это API для создания и управления конфигурациями, которые используют встроенную реализацию IPsec или IKEv2. Провайдер пакетного туннеля — другая модель: приложение поставляет расширение, реализующее клиентскую сторону собственного протокола. Всё, что люди потом выводят из этого ярлыка, от шифров до владения и до того, нужно ли управлять телефоном, — это вывод, а не утверждение.

Кто реализует туннель

Это разделение решает, кто отвечает, когда что-то ломается. При встроенном IPsec или IKEv2 машиной состояний туннеля владеет iOS, а приложение владеет конфигурацией и кнопками. При провайдере приложение владеет и тем и другим, поэтому ошибка протокола становится обновлением приложения, а не обновлением операционной системы.

Сравнение короткое, если спросить, кто реализует протокол.

IntegrationApple interfaceProtocol implementation
Personal VPNNEVPNManager with a Personal VPN configurationThe system IPsec or IKEv2 client
Packet tunnelNETunnelProviderManager plus the provider extensionWhatever the extension implements

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

Два утверждения о ярлыке, от которых стоит отказаться

Первое — что Личный VPN выбирает шифр. Это не так; согласованный набор происходит из протокола и его конфигурации, и ярлык Личный ничего не говорит о том, какой вы получите. Второе — что Личный VPN подразумевает прокси или ограниченный туннель. Он подразумевает встроенный IPsec или IKEv2, а это полный туннель всякий раз, когда маршруты говорят так.

Поэтому наличие приложения не является доказательством о проводном протоколе. Сторонний клиент, говорящий на WireGuard или OpenVPN, по устройству является приложением провайдера, потому что iOS не реализует эти протоколы нативно.

Почему корпоративная формулировка вводит в заблуждение

Документация Apple классифицирует конфигурации NETunnelProviderManager как обычные корпоративные конфигурации VPN. Эта формулировка — категория API, и она толкает людей к двум противоположным ошибкам: считать, что потребительское приложение не может использовать модель провайдера, и считать, что телефон для этого должен находиться под надзором. Ни то ни другое не следует. Потребительские приложения регулярно поставляют провайдеров, а надзор — отдельный вопрос о том, кто вправе применять политику.

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

Проверяйте доказательство, а не снимок экрана

Снимки экрана — худшее доступное доказательство, потому что группировка в Настройках меняется от версии к версии. Управляемый профиль называет свой тип полезной нагрузки: встроенный профиль объявляет тип VPN, например IKEv2 или IPsec, а профиль провайдера несёт подтип с идентификатором пакета провайдера. Это проверяемо на устройстве перед вами, и это переживёт следующий редизайн.

Что касается самого приложения, используемый класс отвечает на тот же вопрос с другой стороны: объекты конфигурации из API Личного VPN либо менеджер провайдера и его расширение.

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

Храните запись вместе с подключением

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

Вопрос, который стоит задать в конце, не в том, какая модель лучше. А в том, какую модель поддерживает ваш оператор и какую вы сможете отлаживать в два часа ночи теми инструментами, которые у вас действительно есть.

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