Android VPN к Cisco IOS: договор, который нужно получить первым

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

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

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

Соберите сведения до того, как что-то устанавливать

Отправьте владельцу шлюза список и просите ответы, а не название продукта. Девять пунктов полностью покрывают профиль удалённого доступа:

1. Имя хоста или адрес шлюза, к которому клиент должен подключаться, и доступен ли он снаружи.
2. Протокол и версия: IKEv2, другое поколение IPsec или служба на основе TLS.
3. Идентичность партнёра, которую ожидает шлюз, и то, что он сам предъявляет в ответ.
4. Доверенный материал: какой CA подписывает сертификат шлюза или используется ли заранее разделённый ключ.
5. Аутентификация пользователя: сертификат, имя пользователя и пароль EAP или заранее разделённый ключ.
6. Пул адресов, в который попадает клиент, с маской и шлюзом.
7. DNS-серверы для использования внутри туннеля и должен ли клиент их принимать.
8. Разрешённые префиксы назначения и нужно ли блокировать трафик за их пределами.
9. Поддерживаемые версии клиента и версии операционной системы телефона, а также любые требования регистрации.

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

Имя поставщика — не протокол

Cisco IOS и IOS XE предлагают несколько схем удалённого доступа, и они не разделяют один формат передачи. IKEv2 с профилем в стиле FlexVPN — не та же служба, что старая конфигурация IKEv1, а клиентская служба на основе TLS — снова другой продукт, часто на другой платформе в той же среде.

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

Собственная документация Cisco по IKEv2 разделяет предложение, политику, профиль и связку ключей как отдельные объекты. Эта структура полезна, когда вы читаете конфигурацию, которую кто-то вставил вам: она говорит, какой объект хранит настройки, важные для удалённого телефона, вместо того чтобы рассматривать весь файл как единое целое.

Что покрывает встроенный стек Android

Android предоставляет платформенный профиль IKEv2/IPsec через Ikev2VpnProfile, с отдельными типами аутентификации для заранее разделённого ключа, сертификата RSA и имени пользователя с паролем EAP. Справочник Ikev2VpnProfile — авторитетный источник о том, что принимает конструктор, включая имя хоста шлюза и корневой CA сервера, используемый для его проверки.

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

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

Проверяйте в том порядке, в каком написан договор

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

Доверие. Если клиент отвергает сертификат шлюза, всё остальное не важно. Убедитесь, что выданный вам CA подписывает сертификат, который предъявляет шлюз, и что имя хоста, к которому вы подключались, присутствует в нём. Оставьте проверку включённой; её отключение превращает проблему идентичности в риск перехвата.

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

Адрес и DNS. Убедитесь, что телефон получил адрес из документированного пула, затем разрешите одно внутреннее имя. Туннель, который поднимается с адресом и без резолвера, выглядит подключённым и ведёт себя так, будто ничего не работает.

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

Режимы отказа и откат

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

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