Remote ID en VPN sur iPhone: kion ĉi tiu kampo vere signifas

Vi estas en Agordoj kaj aldonas IKEv2-agordon, kaj du kampoj postulas tekston, kiun neniu donis al vi: Remote ID kaj Local ID. Neniu el ili estas via uzantnomo, kaj neniu estas dua kopio de la kampo Server. Remote ID estas la identeco, kiun la pordego devas pruvi al via iPhone; Local ID estas la identeco, kiun via iPhone asertas al la pordego. Se vi maltrafas iun el ili, la tunelo mortas post kiam la servilo jam respondis — tial la fiasko aspektas kiel pasvorta problemo sed ne estas.

Kie la kampoj troviĝas en iOS

Malfermu Agordoj > Ĝenerala > VPN kaj aparatadministrado > VPN kaj aldonu IKEv2-agordon. Sub Aŭtentigo vi elektas Uzantnomon aŭ Atestilon, kaj nur tiam Remote ID kaj Local ID aperas kiel liberaj tekstkampoj. Ili estas identigiloj, ne adresoj: iOS portas ilin en la interŝanĝo IKE_AUTH, kie IKEv2 nomas la identecon de la iniciatinto IDi kaj tiun de la respondanto IDr.

Post kiam vi konservas, iOS faldas la agordon en unu vicon kaj ĉesas montri la valorojn. Tuŝu la informbutonon aŭ remalfermu la profilon antaŭ ol konkludi, ke la kampoj estas malplenaj. Agordo puŝita de MDM povas tute grizi ilin, kio ŝanĝas kiu povas ripari la problemon.

Remote ID estas la nomo de la pordego

Tio estas la valoro, kiun via iPhone atendas, ke la servilo pruvu. Ĉe atestila aŭtentigo ĝi estas komparata kun la nomo en la servila atestilo, kutime la subject aŭ rikordo subjectAltName. Se la atestilo estas eldonita por vpn.example.com, tiu gastignomo estas la Remote ID, eĉ kiam vi atingas la maŝinon per nuda IP-adreso.

Tiu malkongruo estas la klasika fiasko: pakaĵoj alvenas, la servilo respondas, kaj la konekto tamen kolapsas ĉar la identeco en la atestilo ne kongruas kun tio, kion la profilo postulis. Montri la kampon Server al la kruda IP ne helpas, kaj ĉe multaj pordegoj la servilo simple ĉesas respondi al identeco, kiun ĝi ne povas kunordigi.

La pordego havas respondan agordon. strongSwan-servilo sendas sian propran identecon per leftid kaj povas limigi la klientan identecon per rightid; se la du flankoj malkonsentas pri la ĉeno, IKE_AUTH fiaskas en ambaŭ direktoj. Demandu la operatoron, por kiu identeco la atestilo estis eldonita, anstataŭ kopii la URL-on el la retumila adresobreto.

Apple dokumentas la ŝlosilojn de la utileco kiel RemoteIdentifier kaj LocalIdentifier en sia referenco pri agordoj IKEv2. Ambaŭ estas simplaj ĉenoj, do uskleco kaj fina spaco povas gravi.

Local ID estas tio, kion via iPhone asertas

Ĉe uzantnoma aŭtentigo EAP kontrolas la uzantnomon kaj pasvorton, kaj Local ID estas aparta IKE-identeco, kiun iuj pordegoj ankaŭ devigas. Pordego povas postuli, ke Local ID egalas la uzantnomon, estu retadreso aŭ kongruu kun rikordo en ĝia konekta politiko; aliaj ignoras ĝin. Lasi ĝin malplena estas sekure nur kiam la operatoro tion diras.

Ĉe atestila aŭtentigo Local ID devus kongrui kun identeco, kiun la pordego akceptas por tiu klienta atestilo, ofte la komuna nomo de la atestilo aŭ valoro ligita al aparata rikordo. Kopii la profilon de kolego kopias ankaŭ ties identecon. Plej bone la pordego registras la malĝustan aparaton; plej malbone politiko por unuopa aparato vin malakceptas.

La kaptilo estas supozi, ke malplena signifas neniun identecon. Ne plenigu malplenan kampon per via retadreso nur ĉar ĝi aspektas nefinita. Konfirmu la celatan valoron kaj entajpu ĝin precize kiel donite.

Kvinminuta kontrolo antaŭ ol konservi

Trairu ilin laŭ ordo; la unua paŝo, kiu fiaskas, estas la riparinda.

1. Akiru tri ĉenojn de la operatoro: la nomon en la servila atestilo, la atendatan Local ID kaj la aŭtentigan metodon.
2. Kongruigu la aŭtentigan metodon. Remote ID kaj Local ID ne anstataŭas uzantnomon kaj pasvorton, kaj atestila profilo ne akceptos pasvorton.
3. Entajpu la valorojn precize, kun uskleco, sen fina spaco.
4. Lasu atestilan validigon ŝaltita. Instali nerilatan radikan atestilon por silentigi averton kaŝas nommalkongruon anstataŭ ripari ĝin.
5. Testu per poŝtelefona datumo, ne per la oficeja Wi-Fi, por ke kaptita portalo aŭ dividita DNS ne sin prezentu kiel identeca problemo.

Legu la tabelon de supre. Tempolimo en la vico Server signifas, ke la identecaj kampoj neniam estis testitaj, do haltu tie. Eraro, kiu aperas nur post kiam la servilo respondis, estas preskaŭ ĉiam malkongruo de Remote ID aŭ Local ID.

Eraroj kiuj montras al la malĝusta kampo

Mesaĝo kiel "User authentication failed" temas pri legitimiloj aŭ EAP, ne pri Remote ID. Atestila averto temas pri la nomo en la atestilo, kaj tie renkontiĝas Remote ID kaj la kampo Server. "The VPN server did not respond" kutime signifas, ke UDP 500 kaj 4500 neniam kompletiĝis, aŭ ke NAT-trairado fiaskis, kaj neniu identeco estis komparita.

Ĉe la pordega flanko identecaj fiaskoj aspektas alie: la peer estas malakceptata dum IKE_AUTH, aŭ la protokolo nomas la ID, kiun la kliento sendis, kaj diras, ke ĝi kongruas kun neniu konekto. Tiu protokola linio estas la plej rapida maniero solvi la disputon, ĉar ĝi montras la precizan ĉenon, kiun la telefono sendis.

Restarigi pasvorton ne riparos atendatan servilan identecon, kaj ŝanĝi Remote ID ne riparos malĝustan pasvorton. Apartigu unue la etapon, poste redaktu la kampon, kiu apartenas al tiu etapo.

Kiam la profilo estas administrata

Se la kampoj estas grizaj, la agordo venis de MDM kaj la telefono ne estas la loko por ripari ĝin. La VPN-utilaĵo portas la identigilojn, do la ĝusta ŝanĝo estas en la profilo sur la administra servilo, sekvata de reinstallado sur la aparato.

Kontrolu en Agordoj > Ĝenerala > VPN kaj aparatadministrado, ĉu la profilo estas administrata kaj kiu subskribis ĝin. Se vi ne povas forigi ĝin, vi ne povas redakti la identigilojn loke, kaj dua loka profilo nur kreas konfliktantan agordon.

Antaŭ ol fermi Agordojn, notu la tri ĉenojn, kiujn vi entajpis, kaj de kie ili venis. Venontan fojon, kiam la tunelo fiaskos, komparu la ricevitan ID el la pordega protokolo kun tiu noto: se ĝi diferencas, vi rigardas la kampon, ne la pasvorton.