Remote ID i VPN på iPhone: hvad feltet egentlig betyder

Du står i Indstillinger og tilføjer en IKEv2-konfiguration, og to felter vil have tekst, som ingen har givet dig: Remote ID og Local ID. Ingen af dem er dit brugernavn, og ingen af dem er en ekstra kopi af feltet Server. Remote ID er den identitet, gatewayen skal bevise over for din iPhone; Local ID er den identitet, din iPhone påstår over for gatewayen. Tager du fejl af en af dem, dør tunnelen, efter at serveren allerede har svaret, og derfor ligner fejlen et adgangskodeproblem uden at være det.

Hvor felterne sidder i iOS

Åbn Indstillinger > Generelt > VPN og enhedsadministration > VPN, og tilføj en IKEv2-konfiguration. Under Godkendelse vælger du Brugernavn eller Certifikat, og først derefter vises Remote ID og Local ID som fritekstfelter. De er identifikatorer, ikke adresser: iOS bærer dem i IKE_AUTH-udvekslingen, hvor IKEv2 kalder initiativtagerens identitet IDi og svarerens identitet IDr.

Når du har gemt, folder iOS konfigurationen sammen til én række og viser ikke længere værdierne. Tryk på info-knappen, eller åbn profilen igen, før du konkluderer, at felterne er tomme. En konfiguration, der er sendt fra MDM, kan gøre dem helt grå, og det ændrer, hvem der kan rette problemet.

Remote ID er gatewayens navn

Det er den værdi, din iPhone forventer, at serveren beviser. Med certifikatgodkendelse sammenlignes den med navnet i serverens certifikat, normalt subject eller en subjectAltName-post. Hvis certifikatet er udstedt til vpn.example.com, er det værtsnavn Remote ID, også når du når boksen på en bar IP-adresse.

Den uoverensstemmelse er den klassiske fejl: pakker ankommer, serveren svarer, og forbindelsen bryder alligevel sammen, fordi identiteten i certifikatet ikke matcher det, profilen krævede. Det hjælper ikke at pege feltet Server mod den rå IP, og på mange gateways holder serveren simpelthen op med at svare på en identitet, den ikke kan matche.

Gatewayen har en tilsvarende indstilling. En strongSwan-server sender sin egen identitet med leftid og kan begrænse klientens identitet med rightid; hvis de to sider er uenige om strengen, fejler IKE_AUTH i begge retninger. Spørg operatøren, hvilken identitet certifikatet er udstedt til, i stedet for at afskrive URL'en fra en browserlinje.

Apple dokumenterer payload-nøglerne som RemoteIdentifier og LocalIdentifier i sin IKEv2-indstillingsreference. Begge er almindelige strenge, så store og små bogstaver samt et mellemrum til sidst kan betyde noget.

Local ID er det, din iPhone påstår

Med brugernavnsgodkendelse kontrollerer EAP brugernavn og adgangskode, og Local ID er en separat IKE-identitet, som nogle gateways også håndhæver. En gateway kan kræve, at Local ID svarer til brugernavnet, er en e-mailadresse eller matcher en post i dens forbindelsespolitik; andre ignorerer det. At lade det stå tomt er kun sikkert, når operatøren siger det.

Med certifikatgodkendelse bør Local ID matche en identitet, som gatewayen accepterer for det klientcertifikat, ofte certifikatets common name eller en værdi knyttet til en enhedspost. At kopiere en kollegas profil kopierer også deres identitet. I bedste fald logger gatewayen den forkerte enhed, i værste fald afviser en politik for hver enhed dig.

Fælden er at antage, at tomt betyder ingen identitet. Udfyld ikke et tomt felt med din e-mailadresse, bare fordi det ser ufærdigt ud. Bekræft den tilsigtede værdi, og indtast den præcis som givet.

Et fem minutters tjek før du gemmer

Gå dem igennem i rækkefølge; det første trin, der fejler, er det, der skal rettes.

1. Hent tre strenge hos operatøren: navnet i serverens certifikat, det forventede Local ID og godkendelsesmetoden.
2. Tilpas godkendelsesmetoden. Remote ID og Local ID erstatter ikke et brugernavn og en adgangskode, og en certifikatprofil accepterer ikke en adgangskode.
3. Skriv værdierne præcist, inklusive store og små bogstaver, uden mellemrum til sidst.
4. Lad certifikatvalidering være slået til. At installere et uvedkommende rodcertifikat for at dæmpe en advarsel skjuler en navnefejl i stedet for at rette den.
5. Test på mobildata, ikke på kontorets Wi-Fi, så en captive portal eller delt DNS ikke optræder som et identitetsproblem.

Læs tabellen oppefra. En timeout i rækken Server betyder, at identitetsfelterne aldrig blev testet, så stop der. En fejl, der først vises, efter at serveren har svaret, er næsten altid en uoverensstemmelse i Remote ID eller Local ID.

Fejl der peger på det forkerte felt

En meddelelse som "User authentication failed" handler om legitimationsoplysninger eller EAP, ikke Remote ID. En certifikatadvarsel handler om navnet i certifikatet, og det er der, Remote ID og feltet Server mødes. "The VPN server did not respond" betyder normalt, at UDP 500 og 4500 aldrig blev færdige, eller at NAT-traversal fejlede, og at ingen identitet blev sammenlignet.

På gateway-siden ser identitetsfejl anderledes ud: peer afvises under IKE_AUTH, eller loggen nævner det ID, klienten sendte, og siger, at det ikke matcher nogen forbindelse. Den loglinje er den hurtigste måde at afgøre diskussionen, fordi den viser den præcise streng, telefonen sendte.

At nulstille en adgangskode retter ikke en forventet serveridentitet, og at ændre Remote ID retter ikke en forkert adgangskode. Skil fasen ad først, og rediger derefter det felt, der hører til den fase.

Når profilen er administreret

Hvis felterne er grå, kom konfigurationen fra MDM, og telefonen er ikke stedet at rette det. VPN-payloaden bærer identifikatorerne, så den rigtige ændring er i profilen på administrationsserveren, efterfulgt af geninstallation på enheden.

Tjek i Indstillinger > Generelt > VPN og enhedsadministration, om profilen er administreret, og hvem der har signeret den. Hvis du ikke kan fjerne den, kan du ikke redigere identifikatorerne lokalt, og en ekstra lokal profil skaber kun en konfliktende konfiguration.

Før du lukker Indstillinger, skriv de tre strenge ned, du indtastede, og hvor de kom fra. Næste gang tunnelen fejler, sammenlign gatewayloggens modtagne ID med den note: hvis den afviger, ser du på feltet, ikke adgangskoden.