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, каб каптыўны партал або раздзелены 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 з журнала шлюза з гэтай нататкай: калі яны розныя, вы глядзіце на поле, а не на пароль.