Remote ID в VPN на iPhone: что на самом деле означает это поле
Remote ID — это идентичность, которую сервер должен доказать вашему iPhone; Local ID — идентичность, которую заявляет клиент. Вот какая строка в какое поле вводится.
Вы в Настройках добавляете конфигурацию IKEv2, и два поля требуют текст, которого вам никто не дал: Remote ID и Local ID. Ни одно из них не является вашим именем пользователя, и ни одно не является второй копией поля Server. Remote ID — это идентичность, которую шлюз должен доказать вашему iPhone; Local ID — идентичность, которую ваш iPhone заявляет шлюзу. Ошибётесь в любом из них — туннель умрёт после того, как сервер уже ответил, поэтому сбой выглядит как проблема с паролем, хотя ею не является.
Где находятся поля в iOS
Откройте Настройки > Основные > VPN и управление устройством > VPN и добавьте конфигурацию IKEv2. В разделе Аутентификация вы выбираете Имя пользователя или Сертификат, и только после этого появляются Remote ID и Local ID как поля свободного текста. Это идентификаторы, а не адреса: iOS переносит их в обмене IKE_AUTH, где IKEv2 называет идентичность инициатора IDi, а идентичность отвечающей стороны IDr.
После сохранения iOS сворачивает конфигурацию в одну строку и перестаёт показывать значения. Нажмите кнопку информации или снова откройте профиль, прежде чем решить, что поля пусты. Конфигурация, разосланная через MDM, может сделать их полностью серыми, и это меняет то, кто может исправить проблему.
Remote ID — это имя шлюза
Это значение, доказательства которого ваш iPhone ждёт от сервера. При аутентификации по сертификату оно сравнивается с именем в сертификате сервера, обычно с subject или записью subjectAltName. Если сертификат выпущен для vpn.example.com, это имя хоста и есть Remote ID, даже когда вы попадаете на машину по голому IP-адресу.
Это несовпадение — классический сбой: пакеты приходят, сервер отвечает, а соединение всё равно рушится, потому что идентичность в сертификате не совпадает с тем, что требовал профиль. Указание поля Server на сырой IP не помогает, и на многих шлюзах сервер просто перестаёт отвечать на идентичность, которую не может сопоставить.
У шлюза есть соответствующая настройка. Сервер strongSwan отправляет собственную идентичность через leftid и может ограничить идентичность клиента через rightid; если стороны не сходятся в строке, IKE_AUTH терпит неудачу в обоих направлениях. Спросите оператора, для какой идентичности выпущен сертификат, вместо того чтобы переписывать URL из адресной строки.
Apple документирует ключи полезной нагрузки как RemoteIdentifier и LocalIdentifier в справочнике по настройкам IKEv2. Оба — обычные строки, поэтому регистр и пробел в конце могут иметь значение.
Local ID — это то, что заявляет ваш iPhone
При аутентификации по имени пользователя EAP проверяет имя и пароль, а Local ID — отдельная идентичность IKE, которую некоторые шлюзы тоже требуют. Шлюз может требовать, чтобы Local ID совпадал с именем пользователя, был адресом электронной почты или соответствовал записи в его политике подключений; другие его игнорируют. Оставлять его пустым безопасно только тогда, когда оператор так говорит.
При аутентификации по сертификату Local ID должен соответствовать идентичности, которую шлюз принимает для этого клиентского сертификата, часто общему имени сертификата или значению, привязанному к записи устройства. Копирование профиля коллеги копирует и его идентичность. В лучшем случае шлюз запишет не то устройство, в худшем — политика для отдельного устройства отклонит вас.
Ловушка — считать, что пустое означает отсутствие идентичности. Не заполняйте пустое поле своим адресом почты только потому, что оно выглядит незаконченным. Подтвердите нужное значение и введите его точно так, как дали.
Пятиминутная проверка перед сохранением
Пройдите их по порядку; первый неудачный шаг и нужно исправлять.
- Получите у оператора три строки: имя в сертификате сервера, ожидаемый Local ID и метод аутентификации.
- Согласуйте метод аутентификации. Remote ID и Local ID не заменяют имя пользователя и пароль, а профиль с сертификатом не примет пароль.
- Введите значения точно, с учётом регистра, без пробела в конце.
- Оставьте проверку сертификатов включённой. Установка постороннего корневого сертификата, чтобы заглушить предупреждение, скрывает несовпадение имени вместо того, чтобы исправить его.
- Проверяйте на мобильных данных, а не на офисном Wi-Fi, чтобы captive-портал или разделённый DNS не выдавали себя за проблему идентичности.
| Field | What belongs there | What a wrong value looks like |
|---|---|---|
| Remote ID | The DNS name in the gateway certificate | Server answers, then the tunnel drops with a certificate or identity error |
| Local ID | The identity the gateway policy expects for you | IKE_AUTH or user authentication fails after the server responds |
| Server | A reachable hostname or IP | Timeout with no identity exchange at all |
Читайте таблицу сверху. Тайм-аут в строке Server означает, что поля идентичности вообще не проверялись, так что остановитесь там. Ошибка, которая появляется только после ответа сервера, почти всегда означает несовпадение Remote ID или Local ID.
Ошибки, указывающие не на то поле
Сообщение вроде "User authentication failed" относится к учётным данным или EAP, а не к Remote ID. Предупреждение о сертификате относится к имени в сертификате, и именно там встречаются Remote ID и поле Server. "The VPN server did not respond" обычно означает, что UDP 500 и 4500 так и не завершились или прохождение NAT не удалось, и ни одна идентичность не сравнивалась.
На стороне шлюза сбои идентичности выглядят иначе: партнёр отклоняется во время IKE_AUTH, или журнал называет ID, отправленный клиентом, и сообщает, что он не соответствует ни одному подключению. Эта строка журнала — самый быстрый способ разрешить спор, потому что показывает точную строку, отправленную телефоном.
Сброс пароля не исправит ожидаемую идентичность сервера, а изменение Remote ID не исправит неверный пароль. Сначала разделите этап, затем правьте поле, относящееся к этому этапу.
Когда профиль управляется
Если поля серые, конфигурация пришла из MDM, и телефон — не место это исправлять. Полезная нагрузка VPN несёт идентификаторы, поэтому правильное изменение — в профиле на сервере управления, а затем его переустановка на устройстве.
Проверьте в Настройки > Основные > VPN и управление устройством, управляется ли профиль и кто его подписал. Если удалить его нельзя, идентификаторы нельзя править локально, а второй локальный профиль создаёт только конфликтующую конфигурацию.
Прежде чем закрыть Настройки, запишите три строки, которые вы ввели, и откуда они взялись. В следующий раз, когда туннель откажет, сравните ID, полученный в журнале шлюза, с этой заметкой: если он отличается, вы смотрите на поле, а не на пароль.