Remote ID i VPN på iPhone: hva feltet egentlig betyr

Du står i Innstillinger og legger til en IKEv2-konfigurasjon, og to felt vil ha tekst som ingen har gitt deg: Remote ID og Local ID. Ingen av dem er brukernavnet ditt, og ingen av dem er en ekstra kopi av feltet Server. Remote ID er identiteten gatewayen må bevise overfor iPhone-en din; Local ID er identiteten iPhone-en din påstår overfor gatewayen. Tar du feil av én av dem, dør tunnelen etter at serveren allerede har svart, og derfor ser feilen ut som et passordproblem uten å være det.

Hvor feltene sitter i iOS

Åpne Innstillinger > Generelt > VPN og enhetsadministrasjon > VPN, og legg til en IKEv2-konfigurasjon. Under Autentisering velger du Brukernavn eller Sertifikat, og først da vises Remote ID og Local ID som fritekstfelt. De er identifikatorer, ikke adresser: iOS bærer dem i IKE_AUTH-utvekslingen, der IKEv2 kaller initiativtakerens identitet IDi og svarerens identitet IDr.

Når du har lagret, folder iOS konfigurasjonen sammen til én rad og viser ikke lenger verdiene. Trykk på info-knappen eller åpne profilen på nytt før du konkluderer med at feltene er tomme. En konfigurasjon som er sendt fra MDM, kan gjøre dem helt grå, og det endrer hvem som kan rette problemet.

Remote ID er navnet på gatewayen

Dette er verdien iPhone-en din forventer at serveren beviser. Med sertifikatautentisering sammenlignes den med navnet i serverens sertifikat, vanligvis subject eller en subjectAltName-post. Hvis sertifikatet er utstedt til vpn.example.com, er det vertsnavnet Remote ID, også når du når boksen på en bar IP-adresse.

Det avviket er den klassiske feilen: pakker ankommer, serveren svarer, og forbindelsen bryter likevel sammen fordi identiteten i sertifikatet ikke samsvarer med det profilen krevde. Det hjelper ikke å peke feltet Server mot rå-IP-en, og på mange gateways slutter serveren rett og slett å svare på en identitet den ikke kan matche.

Gatewayen har en tilsvarende innstilling. En strongSwan-server sender sin egen identitet med leftid og kan begrense klientens identitet med rightid; hvis partene er uenige om strengen, feiler IKE_AUTH i begge retninger. Spør operatøren hvilken identitet sertifikatet er utstedt til, i stedet for å skrive av URL-en fra nettleserlinjen.

Apple dokumenterer nyttelastnøklene som RemoteIdentifier og LocalIdentifier i sin referanse for IKEv2-innstillinger. Begge er vanlige strenger, så store og små bokstaver og et mellomrom til slutt kan ha noe å si.

Local ID er det iPhone-en din påstår

Med brukernavnautentisering kontrollerer EAP brukernavn og passord, og Local ID er en egen IKE-identitet som enkelte gateways også håndhever. En gateway kan kreve at Local ID er lik brukernavnet, er en e-postadresse eller samsvarer med en post i tilkoblingspolicyen; andre ignorerer det. Å la det stå tomt er bare trygt når operatøren sier det.

Med sertifikatautentisering bør Local ID samsvare med en identitet gatewayen godtar for det klient sertifikatet, ofte sertifikatets common name eller en verdi knyttet til en enhetspost. Å kopiere profilen til en kollega kopierer også identiteten deres. I beste fall logger gatewayen feil enhet, i verste fall avviser en policy per enhet deg.

Fellen er å anta at tomt betyr ingen identitet. Ikke fyll et tomt felt med e-postadressen din bare fordi det ser uferdig ut. Bekreft den tiltenkte verdien og skriv den inn nøyaktig som gitt.

En fem minutters sjekk før du lagrer

Gå gjennom dem i rekkefølge; det første trinnet som feiler, er det som skal rettes.

1. Skaff tre strenger fra operatøren: navnet i serverens sertifikat, forventet Local ID og autentiseringsmetoden.
2. Tilpass autentiseringsmetoden. Remote ID og Local ID erstatter ikke brukernavn og passord, og en sertifikatprofil godtar ikke passord.
3. Skriv inn verdiene nøyaktig, med store og små bokstaver, uten mellomrom til slutt.
4. La sertifikatvalideringen være på. Å installere et uvedkommende rotsertifikat for å dempe en advarsel skjuler et navneavvik i stedet for å rette det.
5. Test på mobildata, ikke på kontorets Wi-Fi, slik at en captive portal eller delt DNS ikke opptrer som et identitetsproblem.

Les tabellen ovenfra. Tidsavbrudd i raden Server betyr at identitetsfeltene aldri ble testet, så stopp der. En feil som først vises etter at serveren har svart, er nesten alltid et avvik i Remote ID eller Local ID.

Feil som peker på feil felt

En melding som "User authentication failed" handler om legitimasjon eller EAP, ikke Remote ID. En sertifikatadvarsel handler om navnet i sertifikatet, og det er der Remote ID og feltet Server møtes. "The VPN server did not respond" betyr vanligvis at UDP 500 og 4500 aldri ble fullført, eller at NAT-traversering feilet, og at ingen identitet ble sammenlignet.

På gateway-siden ser identitetsfeil annerledes ut: peer-en avvises under IKE_AUTH, eller loggen navngir ID-en klienten sendte og sier at den ikke samsvarer med noen tilkobling. Den logglinjen er den raskeste måten å avgjøre diskusjonen, fordi den viser den nøyaktige strengen telefonen sendte.

Å tilbakestille et passord retter ikke en forventet serveridentitet, og å endre Remote ID retter ikke et feil passord. Skill fasen først, og rediger deretter feltet som hører til den fasen.

Når profilen er administrert

Hvis feltene er grå, kom konfigurasjonen fra MDM, og telefonen er ikke stedet å rette det. VPN-nyttelasten bærer identifikatorene, så den riktige endringen er i profilen på administrasjonsserveren, etterfulgt av ny installasjon på enheten.

Sjekk i Innstillinger > Generelt > VPN og enhetsadministrasjon om profilen er administrert og hvem som signerte den. Hvis du ikke kan fjerne den, kan du ikke redigere identifikatorene lokalt, og en ekstra lokal profil skaper bare en motstridende konfigurasjon.

Før du lukker Innstillinger, skriv ned de tre strengene du skrev inn og hvor de kom fra. Neste gang tunnelen feiler, sammenlign ID-en gatewayloggen mottok med den notaten: hvis den avviker, ser du på feltet, ikke passordet.