Remote ID i VPN på iPhone: vad fältet egentligen betyder

Du är i Inställningar och lägger till en IKEv2-konfiguration, och två fält vill ha text som ingen har gett dig: Remote ID och Local ID. Ingen av dem är ditt användarnamn, och ingen av dem är en extra kopia av fältet Server. Remote ID är identiteten som gatewayen måste bevisa för din iPhone; Local ID är identiteten som din iPhone hävdar inför gatewayen. Tar du fel på någon av dem dör tunneln efter att servern redan har svarat, och därför ser felet ut som ett lösenordsproblem utan att vara det.

Var fälten sitter i iOS

Öppna Inställningar > Allmänt > VPN och enhetshantering > VPN och lägg till en IKEv2-konfiguration. Under Autentisering väljer du Användarnamn eller Certifikat, och först då visas Remote ID och Local ID som fritextfält. De är identifierare, inte adresser: iOS bär dem i IKE_AUTH-utbytet, där IKEv2 kallar initiativtagarens identitet IDi och svararens identitet IDr.

När du har sparat viker iOS ihop konfigurationen till en enda rad och slutar visa värdena. Tryck på info-knappen eller öppna profilen igen innan du drar slutsatsen att fälten är tomma. En konfiguration som skickats från MDM kan göra dem helt gråa, och det ändrar vem som kan åtgärda problemet.

Remote ID är gatewayens namn

Det här är värdet som din iPhone förväntar sig att servern bevisar. Med certifikatautentisering jämförs det med namnet i serverns certifikat, vanligtvis subject eller en subjectAltName-post. Om certifikatet är utfärdat för vpn.example.com är det värdnamnet Remote ID, även när du når maskinen på en bar IP-adress.

Den avvikelsen är det klassiska felet: paket anländer, servern svarar, och anslutningen faller ändå eftersom identiteten i certifikatet inte matchar det profilen krävde. Det hjälper inte att peka fältet Server mot rå-IP:n, och på många gatewayer slutar servern helt enkelt svara på en identitet som den inte kan matcha.

Gatewayen har en motsvarande inställning. En strongSwan-server skickar sin egen identitet med leftid och kan begränsa klientens identitet med rightid; om parterna inte är överens om strängen misslyckas IKE_AUTH i båda riktningarna. Fråga operatören vilken identitet certifikatet utfärdades för i stället för att skriva av URL:en från adressfältet.

Apple dokumenterar nyttolastnycklarna som RemoteIdentifier och LocalIdentifier i sin referens för IKEv2-inställningar. Båda är vanliga strängar, så versaler och ett mellanslag i slutet kan spela roll.

Local ID är det din iPhone hävdar

Med autentisering via användarnamn kontrollerar EAP namn och lösenord, och Local ID är en separat IKE-identitet som en del gatewayer också kräver. En gateway kan kräva att Local ID är lika med användarnamnet, är en e-postadress eller matchar en post i dess anslutningspolicy; andra ignorerar det. Att lämna det tomt är bara säkert när operatören säger det.

Med certifikatautentisering bör Local ID matcha en identitet som gatewayen accepterar för det klientcertifikatet, ofta certifikatets common name eller ett värde kopplat till en enhetspost. Att kopiera en kollegas profil kopierar också deras identitet. I bästa fall loggar gatewayen fel enhet, i värsta fall avvisar en policy per enhet dig.

Fällan är att anta att tomt betyder ingen identitet. Fyll inte ett tomt fält med din e-postadress bara för att det ser ofärdigt ut. Bekräfta det avsedda värdet och ange det exakt som det gavs.

En femminuterskontroll innan du sparar

Gå igenom dem i ordning; det första steget som misslyckas är det som ska åtgärdas.

1. Skaffa tre strängar från operatören: namnet i serverns certifikat, förväntat Local ID och autentiseringsmetoden.
2. Anpassa autentiseringsmetoden. Remote ID och Local ID ersätter inte användarnamn och lösenord, och en certifikatprofil accepterar inte ett lösenord.
3. Skriv in värdena exakt, inklusive versaler och gemener, utan mellanslag i slutet.
4. Låt certifikatvalideringen vara på. Att installera ett orelaterat rotcertifikat för att tysta en varning döljer en namnavvikelse i stället för att åtgärda den.
5. Testa på mobildata, inte på kontorets Wi-Fi, så att en captive portal eller delad DNS inte uppträder som ett identitetsproblem.

Läs tabellen uppifrån. En timeout på raden Server betyder att identitetsfälten aldrig testades, så stanna där. Ett fel som först visas efter serverns svar är nästan alltid en avvikelse i Remote ID eller Local ID.

Fel som pekar på fel fält

Ett meddelande som "User authentication failed" handlar om inloggningsuppgifter eller EAP, inte om Remote ID. En certifikatvarning handlar om namnet i certifikatet, och där möts Remote ID och fältet Server. "The VPN server did not respond" betyder oftast att UDP 500 och 4500 aldrig slutfördes, eller att NAT-traverseringen misslyckades, och att ingen identitet jämfördes.

På gateway-sidan ser identitetsfel annorlunda ut: peer-en avvisas under IKE_AUTH, eller loggen namnger det ID som klienten skickade och säger att det inte matchar någon anslutning. Den loggraden är det snabbaste sättet att avgöra diskussionen, eftersom den visar den exakta sträng som telefonen skickade.

Att återställa ett lösenord reparerar inte en förväntad serveridentitet, och att ändra Remote ID reparerar inte ett felaktigt lösenord. Separera fasen först och redigera sedan fältet som hör till den fasen.

När profilen hanteras

Om fälten är gråa kom konfigurationen från MDM och telefonen är inte platsen att åtgärda det. VPN-nyttolasten bär identifierarna, så den riktiga ändringen är i profilen på hanteringsservern, följd av ominstallation på enheten.

Kontrollera i Inställningar > Allmänt > VPN och enhetshantering om profilen hanteras och vem som signerade den. Om du inte kan ta bort den kan du inte redigera identifierarna lokalt, och en extra lokal profil skapar bara en motstridig konfiguration.

Innan du stänger Inställningar, skriv ner de tre strängar du angav och var de kom ifrån. Nästa gång tunneln fallerar, jämför ID:t som gatewayloggen tog emot med den anteckningen: skiljer det sig tittar du på fältet, inte lösenordet.