iPhone IKEv2 к RouterOS: какой идентификатор куда ставится
Четыре отдельных утверждения определяют туннель IKEv2 на iOS: набираемый адрес, ожидаемая идентичность сервера, заявленная идентичность клиента и сертификатный материал.
Достижение шлюза MikroTik решает только транспортную половину развёртывания IKEv2 и ничего больше. Затем четыре отдельных утверждения определяют, сформируется ли туннель: адрес, который набирает телефон, идентичность сервера, которую он ожидает, идентичность, которую он заявляет для себя, и сертификатный материал, который это утверждение подкрепляет. Проверяйте их в этом порядке и остановитесь на первом, который не совпадает с тем, что представляет шлюз. Каждое правится в своём месте, поэтому неверная правка обычно переносит отказ, а не устраняет его.
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
Проверьте поля профиля в том порядке, в котором их использует обмен
Удалённый адрес — это назначение первого пакета IKE и ничего больше. Удалённый идентификатор — это то, чем телефон ожидает увидеть шлюз, и это имя, а не маршрут. Заполнение обоих одним и тем же именем хоста работает, когда сертификат шлюза содержит это имя, и даёт сбой так, что он выглядит как проблема маршрутизации, когда не содержит. Читайте профиль как последовательность утверждений, а не как список полей для заполнения.
Локальный идентификатор — это собственное утверждение телефона, и он должен быть именем, которое запись идентичности RouterOS принимает для клиентского сертификата, предъявляемого телефоном. Если они не совпадают, шлюз отклоняет соединение после того, как сам сертификат прошёл проверку, и журнал выглядит как проблема авторизации, а не именования.
Проверьте идентификаторы по тому, что представляет шлюз
Запись узла в RouterOS, настроенная для аутентификации по сертификату, предъявляет собственный сертификат, и её идентичность берётся из этого сертификата, если вы не настроили иначе. Если удалённый идентификатор телефона называет DNS-имя шлюза, сертификату шлюза нужно это имя в месте, которое телефон примет, обычно в альтернативном имени субъекта. Сертификат, выданный на другое общее имя, не пройдёт проверку, даже если ключ и цепочка безупречны.
Управляемые профили Apple могут также нести ограничение имени сертификата, которое оценивается дополнительно к полям идентификатора. Изучайте полезную нагрузку, а не выводите имя для проверки из того, что показывает экран настроек, потому что это не одна и та же настройка.
Проверьте, что клиентский сертификат — это ключ, а не просто якорь доверия
Импорт сертификата CA даёт телефону то, чем можно проверить шлюз. Он не даёт телефону клиентской идентичности, а аутентификация по сертификату требует клиентского конечного сертификата и его закрытого ключа, доставленных вместе по одобренному пути регистрации. PKCS#12, собранный без закрытого ключа, даёт профиль, который чисто устанавливается и ничего не аутентифицирует.
Клиентскому конечному сертификату нужна также идентичность, которую ожидает сторона RouterOS, то есть субъект или альтернативное имя субъекта должны совпадать с соответствующей конфигурацией идентичности. Выпуск клиентских и серверных сертификатов из одного CA делает цепочку удобной и не делает два конечных сертификата взаимозаменяемыми.
Проверьте, что политика RouterOS принимает это имя
На шлюзе запись узла задаёт режим обмена и метод аутентификации, а запись идентичности связывает принятую удалённую идентичность с сертификатом и с политикой, которая следует за ней. В RouterOS v7 эта пара выражается записями узла и идентичности IPsec, например узел IKEv2 с auth-method=digital-signature. Проверяйте фактическое содержимое меню в установленной версии, а не руководство, написанное для более старой.
Здесь же несовпадение дешевле всего исправить, потому что шлюз может сообщить и полученную идентичность, и желаемую. Расширение принимаемой идентичности, чтобы заглушить ошибку, убирает связь, которая придавала развёртыванию смысл.
Проверьте, на каком этапе произошёл сбой, прежде чем что-либо править
Прочитайте попытку с обеих сторон и классифицируйте её, прежде чем менять предложение. Несовпадение предложения, отсутствующий ключ подписи, недоверенный издатель, неверный идентификатор узла и отклонённая авторизация клиента выглядят с телефона как мёртвый туннель, и у каждого свой ответственный. Изменение всех пяти настроек сразу гарантирует, что вы ничего не узнаете из результата.
Запишите предъявленную идентичность, ожидаемую идентичность, издателя и серийный номер сертификата и имя соответствующей политики, держа закрытые ключи и секреты профиля вне этой записи. Когда аутентификация удастся, проверьте частную службу и её ответ, потому что назначение адресов, селекторы, DNS и политика доступа всё ещё должны работать после завершения обмена IKE.