Remote ID i VPN på iPhone: kva feltet eigentleg tyder

Du står i Innstillingar og legg til ein IKEv2-konfigurasjon, og to felt vil ha tekst som ingen har gitt deg: Remote ID og Local ID. Ingen av dei er brukarnamnet ditt, og ingen av dei er ein 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. Tek du feil av ein av dei, døyr tunnelen etter at serveren alt har svart, og difor ser feilen ut som eit passordproblem utan å vere det.

Kvar felta er i iOS

Opne Innstillingar > Generelt > VPN og einingadminstrasjon > VPN, og legg til ein IKEv2-konfigurasjon. Under Autentisering vel du Brukarnamn eller Sertifikat, og først då kjem Remote ID og Local ID til syne som fritekstfelt. Dei er identifikatorar, ikkje adresser: iOS ber dei i IKE_AUTH-utvekslinga, der IKEv2 kallar identiteten til initiativtakaren IDi og identiteten til svararen IDr.

Når du har lagra, foldar iOS konfigurasjonen saman til éi rad og viser ikkje lenger verdiane. Trykk på info-knappen eller opne profilen på nytt før du konkluderer med at felta er tomme. Ein konfigurasjon som er sendt frå MDM, kan gjere dei heilt grå, og det endrar kven som kan rette problemet.

Remote ID er namnet på gatewayen

Dette er verdien iPhone-en din ventar at serveren skal bevise. Med sertifikatautentisering blir han samanlikna med namnet i sertifikatet til serveren, vanlegvis subject eller ein subjectAltName-post. Er sertifikatet utstedt til vpn.example.com, er det vertsnamnet Remote ID, også når du når boksen på ei bar IP-adresse.

Det avviket er den klassiske feilen: pakkar kjem inn, serveren svarar, og sambandet bryt likevel saman fordi identiteten i sertifikatet ikkje samsvarar med det profilen kravde. Det hjelper ikkje å peike feltet Server mot rå-IP-en, og på mange gatewayar sluttar serveren rett og slett å svare på ein identitet han ikkje kan matche.

Gatewayen har ei tilsvarande innstilling. Ein strongSwan-server sender sin eigen identitet med leftid og kan avgrense klientidentiteten med rightid; er partane usamde om strengen, feilar IKE_AUTH i begge retningar. Spør operatøren kva identitet sertifikatet er utstedt til, i staden for å skrive av URL-en frå nettlesarlinja.

Apple dokumenterer nyttelastnøklane som RemoteIdentifier og LocalIdentifier i referansen for IKEv2-innstillingar. Begge er vanlege strengar, så store og små bokstavar og eit mellomrom til slutt kan ha noko å seie.

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

Med brukarnamnautentisering kontrollerer EAP namn og passord, og Local ID er ein eigen IKE-identitet som enkelte gatewayar også handhevar. Ein gateway kan krevje at Local ID er lik brukarnamnet, er ei e-postadresse eller samsvarar med ein post i tilkoplingspolicyen; andre ignorerer det. Å la det stå tomt er berre trygt når operatøren seier det.

Med sertifikatautentisering bør Local ID samsvare med ein identitet gatewayen godtek for det klient sertifikatet, ofte common name til sertifikatet eller ein verdi knytt til ein einingsoppføring. Å kopiere profilen til ein kollega kopierer også identiteten deira. I beste fall loggar gatewayen feil eining, i verste fall avviser ein policy per eining deg.

Fella er å tru at tomt tyder ingen identitet. Ikkje fyll eit tomt felt med e-postadressa di berre fordi det ser uferdig ut. Stadfest den tiltenkte verdien og skriv han inn nøyaktig som gitt.

Ein fem minutts sjekk før du lagrar

Gå gjennom dei i rekkjefølgje; det første trinnet som feilar, er det som skal rettast.

1. Skaff tre strengar frå operatøren: namnet i sertifikatet til serveren, forventa Local ID og autentiseringsmetoden.
2. Tilpass autentiseringsmetoden. Remote ID og Local ID erstattar ikkje brukarnamn og passord, og ein sertifikatprofil godtek ikkje passord.
3. Skriv inn verdiane nøyaktig, med store og små bokstavar, utan mellomrom til slutt.
4. La sertifikatvalideringa stå på. Å installere eit uvedkomande rotsertifikat for å dempe ei åtvaring gøymer eit namneavvik i staden for å rette det.
5. Test på mobildata, ikkje på Wi-Fi-en på kontoret, slik at ein captive portal eller delt DNS ikkje framstår som eit identitetsproblem.

Les tabellen ovanfrå. Tidsavbrot i rada Server tyder at identitetsfelta aldri vart testa, så stopp der. Ein feil som først viser seg etter at serveren har svart, er nesten alltid eit avvik i Remote ID eller Local ID.

Feil som peikar på feil felt

Ei melding som "User authentication failed" handlar om legitimasjon eller EAP, ikkje Remote ID. Ei sertifikatåtvaring handlar om namnet i sertifikatet, og det er der Remote ID og feltet Server møtest. "The VPN server did not respond" tyder vanlegvis at UDP 500 og 4500 aldri vart fullførte, eller at NAT-traversering feila, og at ingen identitet vart samanlikna.

På gateway-sida ser identitetsfeil annleis ut: peer-en blir avvist under IKE_AUTH, eller loggen namngjev ID-en klienten sende og seier at han ikkje samsvarar med noka tilkopling. Den logglinja er den snøggaste måten å avgjere diskusjonen, fordi ho viser den nøyaktige strengen telefonen sende.

Å nullstille eit passord rettar ikkje ein forventa serveridentitet, og å endre Remote ID rettar ikkje eit feil passord. Skil fasen først, og rediger deretter feltet som høyrer til den fasen.

Når profilen er administrert

Er felta grå, kom konfigurasjonen frå MDM, og telefonen er ikkje staden å rette det. VPN-nyttelasta ber identifikatorane, så den rette endringa er i profilen på administrasjonsserveren, etterfølgt av ny installasjon på eininga.

Sjekk i Innstillingar > Generelt > VPN og einingadminstrasjon om profilen er administrert og kven som signerte han. Kan du ikkje fjerne han, kan du ikkje redigere identifikatorane lokalt, og ein ekstra lokal profil skaper berre ein motstridande konfigurasjon.

Før du lukkar Innstillingar, skriv ned dei tre strengane du skreiv inn og kvar dei kom frå. Neste gong tunnelen feilar, samanlikn ID-en gatewayloggen fekk med den notata: om han avvik, ser du på feltet, ikkje passordet.