Remote ID-ը iPhone-ի VPN-ում. ինչ է իրականում նշանակում այս դաշտը
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-ով, որպեսզի գրավող պորտալը կամ բաժանված 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-ն այդ գրառման հետ. եթե տարբերվում է, դուք նայում եք դաշտին, ոչ թե գաղտնաբառին։