Remote ID във VPN за iPhone: какво всъщност означава това поле
Remote ID е самоличността на сървъра, която iPhone VPN трябва да докаже; 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, за да не се представят портал за удостоверяване или разделен 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 traversal се е провалил, и никаква самоличност не е сравнявана.
От страна на шлюза отказите на самоличност изглеждат различно: партньорът се отхвърля по време на IKE_AUTH или журналът посочва ID, изпратен от клиента, и казва, че не съвпада с нито една връзка. Този ред в журнала е най-бързият начин да решите спора, защото показва точния низ, изпратен от телефона.
Нулирането на парола няма да поправи очаквана самоличност на сървъра, а промяната на Remote ID няма да поправи грешна парола. Първо отделете етапа, после редактирайте полето, което му принадлежи.
Когато профилът се управлява
Ако полетата са сиви, конфигурацията е дошла от MDM и телефонът не е мястото, където да се поправи. Полезният товар на VPN носи идентификаторите, така че правилната промяна е в профила на сървъра за управление, последвана от преинсталирането му на устройството.
Проверете в Настройки > Основни > VPN и управление на устройства дали профилът се управлява и кой го е подписал. Ако не можете да го премахнете, не можете да редактирате идентификаторите локално, а втори локален профил само създава конфликтна конфигурация.
Преди да затворите Настройки, запишете трите низа, които въведохте, и откъде идват. Следващия път, когато тунелът се провали, сравнете получения ID от журнала на шлюза с тази бележка: ако се различават, гледате полето, не паролата.