VPN-App oder integriertes IKEv2 auf dem iPhone: So wählen Sie
Eine iPhone-VPN-App und der integrierte IKEv2-Client lösen unterschiedliche Probleme. Vergleichen Sie zuerst Protokollunterstützung, Authentifizierung, Gerätekontrolle und Wiederherstellung.
Letzte Woche reichte mir ein Kollege sein iPhone mit zwei VPN-Einträgen in den Einstellungen: einen von einer Anbieter-App, einen aus einem IKEv2-Profil, das aus einer Support-Seite kopiert war. Sie sind keine konkurrierenden Versionen derselben Sache. Eine Anbieter-App ist ein Container, der eigenen Tunnelcode mitbringen kann, während Apples integrierter Client ein IKEv2-Client ist, der manuell oder per Profil konfiguriert wird. Protokoll, Umgang mit Zugangsdaten, Gerätekontrolle und Wiederherstellung entscheiden über die Wahl.
App und nativer Client liegen auf verschiedenen Ebenen
Apples integrierter VPN-Client ist in der Praxis ein IKEv2-Client. Das manuelle Formular listet noch die veraltete L2TP über IPsec und Cisco-IPsec-Optionen, aber es gibt kein Feld für ein Anbieter-Transportprotokoll und keine Stelle, an der man eine OpenVPN- oder WireGuard-Konfiguration einfügen könnte. Sie füllen entweder ein Formular unter Einstellungen > Allgemein > VPN & Geräteverwaltung aus oder importieren ein Profil mit einer VPN-Nutzlast; die Oberfläche besteht aus einer Serveradresse, zwei Identitäten, einer Authentifizierungsmethode und optionalen On-Demand-Regeln.
Eine Anbieter-App arbeitet eine Ebene höher. Sie liefert einen Packet-Tunnel-Provider als Network Extension, sodass der Protokollcode und die Routing-Logik in der App liegen und iOS nur Pakete durchreicht. Manche Apps implementieren WireGuard oder OpenVPN, manche einen eigenen verschleierten Transport, und einige installieren nur ein IKEv2-Profil und steuern den nativen Client hinter einer schöneren Oberfläche. Wegen dieser letzten Gruppe ist die Wahl zwischen App und Profil manchmal eine Scheinalternative.
Die Folge ist praktisch: Eine .ovpn- oder WireGuard-Datei ersetzt diese Felder nicht, weil der Handshake ein anderes Protokoll ist.
Lesen Sie die Nutzlast, bevor Sie Funktionen vergleichen
Wenn das Profil IKEv2 ist, erklären die Nutzlastschlüssel mehr Fehler als jeder Funktionsvergleich. Apples IKEv2-Einstellungsreferenz dokumentiert jeden Schlüssel; eine gekürzte Nutzlast sieht so aus:
<key>VPNType</key><string>IKEv2</string>
<key>RemoteAddress</key><string>vpn.example.net</string>
<key>RemoteIdentifier</key><string>vpn.example.net</string>
<key>LocalIdentifier</key><string>[email protected]</string>
<key>AuthenticationMethod</key><string>Certificate</string>
<key>ServerCertificateIssuerCommonName</key><string>Example Issuing CA</string>Drei Felder tragen den größten Teil der Diagnoselast. RemoteIdentifier ist der Name, den der Client vom Server erwartet, sodass ein Gateway hinter NAT oder ein Load Balancer, dessen Zertifikat den Pool statt der Adresse nennt, fehlschlägt, obwohl die Adresse stimmt. LocalIdentifier ist, für wen der Server Sie hält, und bei Zertifikatsauthentifizierung muss er mit der Identität übereinstimmen, die Ihrem Konto zugeordnet ist. ServerCertificateIssuerCommonName legt die ausstellende CA fest, sodass ein Profil am Tag der Zertifikatserneuerung fehlschlagen kann, ohne dass eine Fehlermeldung Zertifikate erwähnt.
Wenn AuthenticationMethod gleich SharedSecret ist, führt der Server eine EAP-Benutzerauthentifizierung durch, und das Geheimnis, das Sie erhalten haben, ist in Wahrheit ein Kontozugangsdatum. Das zählt, wenn ein Anbieter zwei Dokumente schickt, eines für Benutzername und Passwort und eines für ein Zertifikat, und nur eines zu dem passt, was Sie importiert haben.
Was die App kann, was der native Client nicht kann
Die Protokollwahl ist der offensichtliche Vorteil. Wenn Ihr Server WireGuard oder OpenVPN spricht, ist eine App der einzige iOS-Client, der ihn nutzen kann, und das Bearbeiten des nativen Formulars wird ihn nicht aushandeln. Eine App kann außerdem Split-Tunneling nach Ziel oder App, eigene DNS-Behandlung, eine Blockade im Stil eines Kill-Switch, Serverauswahl und auf ihr eigenes Netz abgestimmte Wiederverbindung umsetzen.
Der Preis ist Software, die Sie nicht geprüft haben und die mit den Rechten einer Network Extension läuft. Die Qualität schwankt stärker, als die Store-Einträge vermuten lassen: Eine App verbindet sich sauber neu, während eine andere nach einem Netzwerkwechsel einige Sekunden lang leckt, und ein Kill-Switch in der App ist eine Funktion dieser App, nicht von iOS. Prüfen Sie auf einem verwalteten Gerät zuerst die Liste der zugelassenen Apps.
Was das native IKEv2-Profil richtig macht
Weniger bewegliche Teile sind das ganze Argument. Der IKEv2-Client und sein IPsec-Stack gehören zum Betriebssystem, es gibt also keine Erweiterung, die abstürzen kann, keinen Prozess pro App, der am Leben gehalten werden muss, und keinen Update-Zyklus Dritter zwischen Ihnen und einem funktionierenden Tunnel. Ein Profil lässt sich außerdem sperren: Auf einem überwachten Gerät kann der Benutzer nicht entfernen, was die Verwaltung installiert hat, und Always On VPN, das sich in jedem Netz ohne Benutzerschalter neu verbindet, existiert nur in dieser überwachten, profilverwalteten Form.
Was der native Weg Ihnen nicht gibt, ist Flexibilität. Es gibt kein VPN pro App ohne verwaltete Apps, keinen benutzerseitigen Kill-Switch und keinen Transport, der in einem IPsec blockierenden Netz wie HTTPS aussieht. In Hotelnetzen, die UDP 500 und 4500 verwerfen, hat natives IKEv2 keinen Rückfall.
Eine Entscheidungstabelle, die die meisten Fälle klärt
In der Praxis entscheidet die Protokollfrage die meisten Fälle, bevor Funktionen zählen.
| What you were given | Device situation | What to use |
|---|---|---|
| An .ovpn or WireGuard config | Personal phone | Provider app; the native form cannot load it |
| IKEv2 host plus CA name | Personal or managed | Profile, or the app's own IKEv2 mode |
| IKEv2 with username and secret | Personal phone | Either; the profile is simpler if you never switch servers |
| A management-installed profile | Supervised, MDM | Native client; do not add a second app entry |
| A per-app tunnelling requirement | Personal phone | App, or accept a full tunnel; iOS cannot split by app without management |
| IPsec blocked on your main network | Any | App with a transport that survives the block |
Zwei Zeilen verdienen einen zweiten Blick. Eine Anforderung pro App auf einem privaten Telefon ist der Fall, den Leute falsch lesen: die Einstellung existiert in iOS, wird aber von der Verwaltung gesteuert, sodass ein nicht verwaltetes Gerät sie nicht anbietet. Ein blockiertes Netz ist kein Grund, IKEv2 zu misstrauen; es ist der Grund, warum die App des Anbieters existiert.
Prüfen Sie die Wahl mit einem Testlauf
Testen Sie die Fehlerfälle, nicht den Verbinden-Knopf. Verbinden Sie einmal, bestätigen Sie, dass die VPN-Anzeige erscheint, öffnen Sie dann eine Seite, die Ihre öffentliche Adresse zurückspiegelt, und vergleichen Sie sie mit der vorherigen. Wechseln Sie von WLAN zu Mobilfunk, ohne das VPN anzufassen, und achten Sie auf eine Wiederverbindung, dann führen Sie das Telefon durch den Flugmodus. Starten Sie neu und sehen Sie, ob der Tunnel von selbst zurückkommt: Ein Profil mit OnDemandEnabled sollte es, während viele Apps zuerst geöffnet werden müssen.
Wenn er nicht zurückkommt, teilen Sie den Fehler danach auf, ob überhaupt ein Tunnel existiert. Keine VPN-Anzeige bedeutet, dass der Tunnel nie hochkam: Entweder scheiterte der Handshake an RemoteIdentifier, an der festgelegten CA oder an einem Zugangsdatum, oder die Verbindung wurde nie versucht, weil die On-Demand-Regel nicht passte und keine App sie startete. Eine Anzeige bei scheiterndem Datenverkehr bedeutet Routing, DNS oder serverseitige Richtlinie, und eine Neuinstallation des Clients berührt nichts davon.
Eine kurze Liste, damit das Gerät der nächsten Person erklärbar bleibt:
- ein VPN-Eintrag, nicht zwei;
- das Profil oder die App nach dem Server benannt, mit dem es verbindet;
- die Identitätswerte dort notiert, wo Sie sie finden.
Beginnen Sie mit der Protokollzeile in der Tabelle, und hören Sie dort auf, wenn sie die Frage beantwortet.