Remote ID im VPN auf dem iPhone: Was das Feld wirklich bedeutet
Remote ID ist die Identität, die der Server deinem iPhone gegenüber beweisen muss; Local ID ist die Identität, die der Client behauptet. Hier steht, welche Zeichenfolge in welches Feld gehört.
Du bist in den Einstellungen und legst eine IKEv2-Konfiguration an, und zwei Felder verlangen Text, den dir niemand gegeben hat: Remote ID und Local ID. Keines von beiden ist dein Benutzername, und keines ist eine zweite Kopie des Feldes Server. Remote ID ist die Identität, die das Gateway deinem iPhone gegenüber beweisen muss; Local ID ist die Identität, die dein iPhone gegenüber dem Gateway behauptet. Vertauschst du eine davon, stirbt der Tunnel, nachdem der Server bereits geantwortet hat — deshalb sieht der Fehler wie ein Passwortproblem aus, ist aber keines.
Wo die Felder in iOS sitzen
Öffne Einstellungen > Allgemein > VPN & Geräteverwaltung > VPN und füge eine IKEv2-Konfiguration hinzu. Unter Authentifizierung wählst du Benutzername oder Zertifikat, und erst dann erscheinen Remote ID und Local ID als Freitextfelder. Sie sind Identifikatoren, keine Adressen: iOS trägt sie im IKE_AUTH-Austausch, wo IKEv2 die Identität des Initiators IDi und die des Responders IDr nennt.
Nach dem Sichern faltet iOS die Konfiguration in eine einzige Zeile und zeigt die Werte nicht mehr an. Tippe auf die Info-Schaltfläche oder öffne das Profil erneut, bevor du schließt, die Felder seien leer. Eine per MDM verteilte Konfiguration kann sie vollständig ausgrauen, was ändert, wer das Problem beheben kann.
Remote ID ist der Name des Gateways
Das ist der Wert, dessen Beweis dein iPhone vom Server erwartet. Bei Zertifikatsauthentifizierung wird er mit dem Namen im Serverzertifikat verglichen, meist dem Subject oder einem subjectAltName-Eintrag. Ist das Zertifikat auf vpn.example.com ausgestellt, ist dieser Hostname die Remote ID, selbst wenn du die Box über eine blanke IP-Adresse erreichst.
Diese Abweichung ist der klassische Fehler: Pakete kommen an, der Server antwortet, und die Verbindung bricht trotzdem zusammen, weil die Identität im Zertifikat nicht zu dem passt, was das Profil verlangt hat. Das Feld Server auf die rohe IP zu zeigen hilft nicht, und bei vielen Gateways hört der Server einfach auf, auf eine Identität zu antworten, die er nicht zuordnen kann.
Das Gateway hat eine passende Einstellung. Ein strongSwan-Server sendet seine eigene Identität mit leftid und kann die Client-Identität mit rightid einschränken; sind sich beide Seiten über die Zeichenfolge uneinig, scheitert IKE_AUTH in beide Richtungen. Frage den Betreiber, für welche Identität das Zertifikat ausgestellt wurde, statt die URL aus der Adressleiste abzuschreiben.
Apple dokumentiert die Payload-Schlüssel als RemoteIdentifier und LocalIdentifier in seiner IKEv2-Einstellungsreferenz. Beide sind einfache Zeichenfolgen, daher können Groß- und Kleinschreibung und ein Leerzeichen am Ende zählen.
Local ID ist das, was dein iPhone behauptet
Bei Benutzernamen-Authentifizierung prüft EAP Benutzername und Passwort, und Local ID ist eine eigene IKE-Identität, die manche Gateways zusätzlich erzwingen. Ein Gateway kann verlangen, dass Local ID dem Benutzernamen entspricht, eine E-Mail-Adresse ist oder einem Eintrag in seiner Verbindungsrichtlinie gleicht; andere ignorieren sie. Sie leer zu lassen ist nur sicher, wenn der Betreiber es sagt.
Bei Zertifikatsauthentifizierung sollte Local ID zu einer Identität passen, die das Gateway für dieses Clientzertifikat akzeptiert, oft der Common Name des Zertifikats oder ein einem Gerätedatensatz zugeordneter Wert. Das Profil eines Kollegen zu kopieren kopiert auch dessen Identität. Im besten Fall protokolliert das Gateway das falsche Gerät, im schlechtesten lehnt eine Richtlinie pro Gerät dich ab.
Die Falle ist die Annahme, leer bedeute keine Identität. Fülle ein leeres Feld nicht mit deiner E-Mail-Adresse, nur weil es unfertig aussieht. Bestätige den beabsichtigten Wert und gib ihn genau so ein, wie er gegeben wurde.
Eine Fünf-Minuten-Prüfung vor dem Sichern
Arbeite sie der Reihe nach ab; der erste Schritt, der scheitert, ist der zu behebende.
- Hole drei Zeichenfolgen beim Betreiber: den Namen im Serverzertifikat, die erwartete Local ID und die Authentifizierungsmethode.
- Gleiche die Authentifizierungsmethode ab. Remote ID und Local ID ersetzen keinen Benutzernamen und kein Passwort, und ein Zertifikatsprofil akzeptiert kein Passwort.
- Gib die Werte exakt ein, einschließlich Groß- und Kleinschreibung, ohne Leerzeichen am Ende.
- Lass die Zertifikatsprüfung an. Ein fremdes Root-Zertifikat zu installieren, um eine Warnung stumm zu schalten, verbirgt eine Namensabweichung, statt sie zu beheben.
- Teste über Mobilfunkdaten, nicht über das Büro-WLAN, damit ein Captive Portal oder geteiltes DNS nicht als Identitätsproblem erscheint.
| Field | What belongs there | What a wrong value looks like |
|---|---|---|
| Remote ID | The DNS name in the gateway certificate | Server answers, then the tunnel drops with a certificate or identity error |
| Local ID | The identity the gateway policy expects for you | IKE_AUTH or user authentication fails after the server responds |
| Server | A reachable hostname or IP | Timeout with no identity exchange at all |
Lies die Tabelle von oben. Eine Zeitüberschreitung in der Zeile Server bedeutet, dass die Identitätsfelder nie getestet wurden — hör dort auf. Ein Fehler, der erst nach der Antwort des Servers auftritt, ist fast immer eine Abweichung bei Remote ID oder Local ID.
Fehler, die auf das falsche Feld zeigen
Eine Meldung wie "User authentication failed" betrifft Anmeldedaten oder EAP, nicht Remote ID. Eine Zertifikatswarnung betrifft den Namen im Zertifikat, und dort treffen Remote ID und das Feld Server aufeinander. "The VPN server did not respond" heißt meist, dass UDP 500 und 4500 nie zustande kamen oder NAT-Traversal scheiterte und keine Identität verglichen wurde.
Auf der Gateway-Seite sehen Identitätsfehler anders aus: Der Peer wird während IKE_AUTH abgelehnt, oder das Log nennt die vom Client gesendete ID und sagt, sie passe zu keiner Verbindung. Diese Logzeile ist der schnellste Weg, den Streit zu klären, denn sie zeigt die genaue Zeichenfolge, die das Telefon gesendet hat.
Ein Passwort zurückzusetzen repariert keine erwartete Serveridentität, und Remote ID zu ändern repariert kein falsches Passwort. Trenne zuerst die Phase und bearbeite dann das Feld, das zu dieser Phase gehört.
Wenn das Profil verwaltet wird
Sind die Felder ausgegraut, kam die Konfiguration von MDM, und das Telefon ist nicht der Ort, das zu beheben. Die VPN-Payload trägt die Identifikatoren, also gehört die richtige Änderung in das Profil auf dem Verwaltungsserver, gefolgt von einer Neuinstallation auf dem Gerät.
Prüfe in Einstellungen > Allgemein > VPN & Geräteverwaltung, ob das Profil verwaltet wird und wer es signiert hat. Lässt es sich nicht entfernen, kannst du die Identifikatoren nicht lokal bearbeiten, und ein zweites lokales Profil erzeugt nur eine widersprüchliche Konfiguration.
Bevor du die Einstellungen schließt, notiere die drei Zeichenfolgen, die du eingegeben hast, und woher sie stammen. Wenn der Tunnel das nächste Mal scheitert, vergleiche die im Gateway-Log empfangene ID mit dieser Notiz: Weicht sie ab, betrachtest du das Feld, nicht das Passwort.