Remote ID у VPN на iPhone: що насправді означає це поле

Ви в Параметрах додаєте конфігурацію 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 має відповідати ідентичності, яку шлюз приймає для цього клієнтського сертифіката, часто загальному імені сертифіката або значенню, прив'язаному до запису пристрою. Копіювання профілю колеги копіює і його ідентичність. У найкращому разі шлюз запише не той пристрій, у найгіршому — політика для окремого пристрою відхилить вас.

Пастка — вважати, що порожнє означає відсутність ідентичності. Не заповнюйте порожнє поле своєю електронною адресою лише тому, що воно виглядає незакінченим. Підтвердьте потрібне значення і введіть його точно так, як дали.

П'ятихвилинна перевірка перед збереженням

Пройдіть їх по порядку; перший невдалий крок і треба виправляти.

1. Отримайте в оператора три рядки: ім'я в сертифікаті сервера, очікуваний Local ID і метод автентифікації.
2. Узгодьте метод автентифікації. Remote ID і Local ID не замінюють ім'я користувача та пароль, а профіль із сертифікатом не прийме пароль.
3. Введіть значення точно, з урахуванням регістру, без пробілу в кінці.
4. Залиште перевірку сертифікатів увімкненою. Встановлення стороннього кореневого сертифіката, щоб заглушити попередження, приховує розбіжність імені замість того, щоб виправити її.
5. Перевіряйте на мобільних даних, а не на офісному Wi-Fi, щоб captive-портал або розділений DNS не видавали себе за проблему ідентичності.

Читайте таблицю згори. Тайм-аут у рядку 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, отриманий у журналі шлюзу, із цією нотаткою: якщо він відрізняється, ви дивитеся на поле, а не на пароль.