VPN-app eller indbygget IKEv2 på iPhone: sådan vælger du
En iPhone-VPN-app og den indbyggede IKEv2-klient løser forskellige problemer. Sammenlign først protokolstøtte, godkendelse, enhedskontrol og gendannelse.
I sidste uge rakte en kollega sin iPhone til mig med to VPN-poster i Indstillinger: den ene efterladt af en udbyderapp, den anden fra en IKEv2-profil kopieret fra en supportside. De er ikke konkurrerende versioner af det samme. En udbyderapp er en container, der kan medbringe sin egen tunnelkode, mens Apples indbyggede klient er en IKEv2-klient, konfigureret manuelt eller via en profil. Protokol, håndtering af legitimationsoplysninger, enhedskontrol og gendannelse afgør valget.
Appen og den native klient ligger på forskellige lag
Apples indbyggede VPN-klient er i praksis en IKEv2-klient. Den manuelle formular viser stadig den forældede L2TP over IPsec og Cisco IPsec-mulighederne, men der er intet felt til udbyderens transport og ingen steder at indsætte en OpenVPN- eller WireGuard-konfiguration. Du udfylder enten en formular under Indstillinger > Generelt > VPN & Enhedsstyring eller importerer en profil med en VPN-payload; fladen er en serveradresse, to identiteter, en godkendelsesmetode og valgfri on-demand-regler.
En udbyderapp arbejder et lag højere oppe. Den leverer en Network Extension-pakketunneludbyder, så protokolkoden og routinglogikken ligger i appen, og iOS sender blot pakker videre. Nogle apps implementerer WireGuard eller OpenVPN, andre en egen sløret transport, og nogle få installerer kun en IKEv2-profil og styrer den native klient bag en pænere skærm. Det sidste er grunden til, at app kontra profil nogle gange er et falsk valg.
Konsekvensen er praktisk: en .ovpn- eller WireGuard-fil erstatter ikke de felter, fordi håndtrykket er en anden protokol.
Læs payloaden, før du sammenligner funktioner
Når profilen er IKEv2, forklarer payloadens nøgler flere fejl end enhver funktionssammenligning. Apples referencedokumentation til IKEv2-indstillinger dokumenterer hver nøgle; en trimmet payload ser sådan ud:
<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>Tre felter bærer det meste af den diagnostiske vægt. RemoteIdentifier er det navn, klienten forventer, at serveren præsenterer, så en gateway bag NAT eller en load balancer, hvis certifikat angiver puljen i stedet for adressen, fejler, selv om adressen er rigtig. LocalIdentifier er den identitet, serveren tror du har, og med certifikatgodkendelse skal den matche den identitet, der er knyttet til din konto. ServerCertificateIssuerCommonName fastlåser den udstedende CA, så en profil kan fejle den dag certifikatet genudstedes, uden at nogen fejlmeddelelse nævner certifikater.
Hvis AuthenticationMethod er SharedSecret, udfører serveren EAP-brugergodkendelse, og den hemmelighed, du fik, er faktisk en kontolegitimation. Det betyder noget, når en udbyder sender to dokumenter, ét til brugernavn og adgangskode og ét til et certifikat, og kun ét passer til det, du importerede.
Hvad appen kan, og den native klient ikke kan
Protokolvalget er den åbenlyse fordel. Hvis din server taler WireGuard eller OpenVPN, er en app den eneste iOS-klient, der kan bruge det, og det ændrer ikke ved at redigere den native formular. En app kan også implementere split tunnelling efter destination eller app, sin egen DNS-håndtering, en blokering i stil med en kill switch, servervalg og genopkobling tilpasset dens eget netværk.
Prisen er software, du ikke har revideret, der kører med en netværksudvidelses privilegier. Kvaliteten svinger mere, end butiksopslagene antyder: én app genopkobler rent, mens en anden lækker i et par sekunder efter et netværksskift, og en kill switch inde i appen er en funktion i den app, ikke i iOS. På en administreret enhed skal du først kontrollere den godkendte liste.
Hvad den native IKEv2-profil gør rigtigt
Færre bevægelige dele er hele argumentet. IKEv2-klienten og dens IPsec-stak leveres med styresystemet, så der er ingen udvidelse, der kan gå ned, ingen proces pr. app, der skal holdes i live, og ingen tredjeparts opdateringscyklus mellem dig og en fungerende tunnel. En profil kan også låses: på en overvåget enhed kan brugeren ikke fjerne det, styringen har installeret, og Always On VPN, der genopkobler på ethvert netværk uden en brugerswitch, findes kun i den overvågede, profiladministrerede form.
Det, den native vej ikke giver dig, er fleksibilitet. Der er ingen VPN pr. app uden administrerede apps, ingen kill switch for brugeren og ingen transport, der ligner HTTPS på et netværk, der blokerer IPsec. På hotelnetværk, der dropper UDP 500 og 4500, har native IKEv2 ingen fallback.
En beslutningstabel, der afgør de fleste tilfælde
I praksis afgør protokolspørgsmålet de fleste tilfælde, før funktionerne betyder noget.
| 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 |
To rækker fortjener et andet blik. Et krav pr. app på en personlig telefon er det tilfælde, folk læser forkert: indstillingen findes i iOS, men styres af administrationen, så en ikke-administreret enhed vil ikke tilbyde den. Et blokeret netværk er ikke en grund til at mistro IKEv2; det er grunden til, at udbyderens app findes.
Bekræft valget med én testkørsel
Test fejltilstandene, ikke forbind-knappen. Forbind én gang, bekræft at VPN-indikatoren vises, og åbn derefter en side, der sender din offentlige adresse tilbage, og sammenlign den med den forrige. Skift fra Wi-Fi til mobildata uden at røre VPN og hold øje med en genopkobling, og tag derefter telefonen gennem flytilstand. Genstart og se, om tunnelen vender tilbage af sig selv: en profil med OnDemandEnabled bør gøre det, mens mange apps skal åbnes først.
Når den ikke vender tilbage, opdel fejlen efter, om der overhovedet findes en tunnel. Ingen VPN-indikator betyder, at tunnelen aldrig kom op: enten fejlede håndtrykket på RemoteIdentifier, den fastlåste CA eller en legitimationsoplysning, eller forbindelsen blev aldrig forsøgt, fordi on-demand-reglen ikke passede, og ingen app startede den. En indikator med fejlende trafik betyder routing, DNS eller politik på serversiden, og en geninstallation af klienten rører ikke ved noget af det.
En kort liste, så enheden kan forklares for den næste person:
- én VPN-post, ikke to;
- profilen eller appen opkaldt efter den server, den forbinder til;
- identitetsværdierne skrevet ned, hvor du kan finde dem.
Begynd med protokolrækken i tabellen, og stop der, hvis den besvarer spørgsmålet.