VPN-app eller innebygd IKEv2 på iPhone: slik velger du
En iPhone-VPN-app og den innebygde IKEv2-klienten løser ulike problemer. Sammenlign først protokollstøtte, autentisering, enhetskontroll og gjenoppretting.
Forrige uke rakte en kollega meg iPhonen sin med to VPN-oppføringer i Innstillinger: den ene etterlatt av en leverandørapp, den andre fra en IKEv2-profil kopiert fra en støtteside. De er ikke konkurrerende versjoner av det samme. En leverandørapp er en beholder som kan ta med sin egen tunnelkode, mens Apples innebygde klient er en IKEv2-klient, konfigurert for hånd eller via en profil. Protokoll, håndtering av påloggingsinformasjon, enhetskontroll og gjenoppretting avgjør valget.
Appen og den innebygde klienten ligger på ulike lag
Apples innebygde VPN-klient er i praksis en IKEv2-klient. Det manuelle skjemaet lister fortsatt den utdaterte L2TP over IPsec og Cisco IPsec-alternativene, men det finnes ikke noe felt for leverandørens transport og ingen steder å lime inn en OpenVPN- eller WireGuard-konfigurasjon. Du fyller enten ut et skjema under Innstillinger > Generelt > VPN & Enhetsadministrasjon eller importerer en profil med en VPN-nyttelast; flaten er en serveradresse, to identiteter, en autentiseringsmetode og valgfrie on demand-regler.
En leverandørapp arbeider ett lag høyere. Den leverer en Network Extension-pakketunnel-leverandør, slik at protokollkoden og rutingslogikken ligger i appen og iOS bare sender pakker videre. Noen apper implementerer WireGuard eller OpenVPN, andre en egen tilslørt transport, og noen få installerer bare en IKEv2-profil og styrer den innebygde klienten bak en penere skjerm. Den siste gruppen er grunnen til at app kontra profil noen ganger er et falskt valg.
Konsekvensen er praktisk: en .ovpn- eller WireGuard-fil erstatter ikke disse feltene, fordi håndtrykket er en annen protokoll.
Les nyttelasten før du sammenligner funksjoner
Når profilen er IKEv2, forklarer nyttelastens nøkler flere feil enn noen funksjonssammenligning. Apples referanse for IKEv2-innstillinger dokumenterer hver nøkkel; en trimmet nyttelast ser slik ut:
<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 felt bærer mesteparten av den diagnostiske vekten. RemoteIdentifier er navnet klienten forventer at serveren presenterer, så en gateway bak NAT eller en lastbalanserer der sertifikatet navngir poolen i stedet for adressen, feiler selv om adressen er riktig. LocalIdentifier er identiteten serveren tror du har, og med sertifikatautentisering må den samsvare med identiteten som er knyttet til kontoen din. ServerCertificateIssuerCommonName fester den utstedende CA-en, så en profil kan feile den dagen sertifikatet utstedes på nytt, uten at noen feilmelding nevner sertifikater.
Hvis AuthenticationMethod er SharedSecret, utfører serveren EAP-brukerautentisering, og hemmeligheten du fikk er egentlig en kontoinnlogging. Det betyr noe når en leverandør sender to dokumenter, ett for brukernavn og passord og ett for et sertifikat, og bare ett passer med det du importerte.
Hva appen kan og den innebygde klienten ikke kan
Protokollvalget er den åpenbare fordelen. Hvis serveren din snakker WireGuard eller OpenVPN, er en app den eneste iOS-klienten som kan bruke det, og å redigere det innebygde skjemaet forhandler det ikke frem. En app kan også implementere delt tunnel etter destinasjon eller app, egen DNS-håndtering, en blokkering i kill switch-stil, servervalg og gjenoppkobling tilpasset sitt eget nettverk.
Prisen er programvare du ikke har revidert, som kjører med en nettverksutvidelses rettigheter. Kvaliteten varierer mer enn butikkoppføringene antyder: én app kobler rent til igjen mens en annen lekker i noen sekunder etter et nettverksbytte, og en kill switch inne i appen er en funksjon i den appen, ikke i iOS. På en administrert enhet bør du sjekke den godkjente listen først.
Hva den innebygde IKEv2-profilen gjør riktig
Færre bevegelige deler er hele argumentet. IKEv2-klienten og IPsec-stakken følger med operativsystemet, så det er ingen utvidelse som kan krasje, ingen prosess per app som må holdes i live, og ingen tredjeparts oppdateringssyklus mellom deg og en fungerende tunnel. En profil kan også låses: på en overvåket enhet kan brukeren ikke fjerne det administrasjonen har installert, og Always On VPN, som kobler til på nytt på alle nettverk uten en brukerbryter, finnes bare i den overvåkede, profiladministrerte formen.
Det den innebygde veien ikke gir deg, er fleksibilitet. Det finnes ingen VPN per app uten administrerte apper, ingen kill switch for brukeren og ingen transport som ser ut som HTTPS på et nettverk som blokkerer IPsec. På hotellnettverk som slipper UDP 500 og 4500, har innebygd IKEv2 ingen reservevei.
En beslutningstabell som avgjør de fleste tilfeller
I praksis avgjør protokollspørsmålet de fleste tilfeller før funksjonene betyr noe.
| 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 rader fortjener et nytt blikk. Et krav per app på en personlig telefon er tilfellet folk leser feil: innstillingen finnes i iOS, men styres av administrasjonen, så en ikke-administrert enhet vil ikke tilby den. Et blokkert nettverk er ikke grunn til å mistro IKEv2; det er grunnen til at leverandørens app finnes.
Bekreft valget med én testkjøring
Test feiltilstandene, ikke koble til-knappen. Koble til én gang, bekreft at VPN-indikatoren vises, åpne deretter en side som sender den offentlige adressen din tilbake og sammenlign den med den forrige. Bytt fra Wi-Fi til mobildata uten å røre VPN og se etter en gjenoppkobling, og ta deretter telefonen gjennom flymodus. Start på nytt og se om tunnelen kommer tilbake av seg selv: en profil med OnDemandEnabled bør gjøre det, mens mange apper må åpnes først.
Når den ikke kommer tilbake, del feilen etter om det i det hele tatt finnes en tunnel. Ingen VPN-indikator betyr at tunnelen aldri kom opp: enten feilet håndtrykket på RemoteIdentifier, den festede CA-en eller en påloggingsdetalj, eller tilkoblingen ble aldri forsøkt fordi on demand-regelen ikke passet og ingen app startet den. En indikator med feilende trafikk betyr ruting, DNS eller serverpolicy, og å installere klienten på nytt rører ingenting av det.
En kort liste så enheten kan forklares for neste person:
- én VPN-oppføring, ikke to;
- profilen eller appen oppkalt etter serveren den kobler til;
- identitetsverdiene skrevet ned der du kan finne dem.
Begynn med protokollraden i tabellen, og stopp der hvis den svarer på spørsmålet.