VPN-app eller inbyggd IKEv2 på iPhone: så väljer du
En iPhone-VPN-app och den inbyggda IKEv2-klienten löser olika problem. Jämför först protokollstöd, autentisering, enhetskontroll och återställning.
Förra veckan räckte en kollega över sin iPhone med två VPN-poster i Inställningar: den ena lämnad av en leverantörsapp, den andra från en IKEv2-profil kopierad från en supportsida. De är inte konkurrerande versioner av samma sak. En leverantörsapp är en behållare som kan ta med sin egen tunnelkod, medan Apples inbyggda klient är en IKEv2-klient som konfigureras för hand eller via en profil. Protokoll, hantering av inloggningsuppgifter, enhetskontroll och återställning avgör valet.
Appen och den inbyggda klienten ligger på olika lager
Apples inbyggda VPN-klient är i praktiken en IKEv2-klient. Det manuella formuläret listar fortfarande den föråldrade L2TP över IPsec och Cisco IPsec-alternativen, men det finns inget fält för leverantörens transport och ingenstans att klistra in en OpenVPN- eller WireGuard-konfiguration. Du fyller antingen i ett formulär under Inställningar > Allmänt > VPN & Enhetshantering eller importerar en profil med en VPN-nyttolast; ytan är en serveradress, två identiteter, en autentiseringsmetod och valfria on demand-regler.
En leverantörsapp arbetar ett lager upp. Den levererar en Network Extension-pakettunnelleverantör, så protokollkoden och routningslogiken ligger i appen och iOS skickar bara vidare paket. Vissa appar implementerar WireGuard eller OpenVPN, andra en egen beslöjad transport, och några installerar bara en IKEv2-profil och styr den inbyggda klienten bakom en trevligare skärm. Den sista gruppen är anledningen till att app kontra profil ibland är ett falskt val.
Konsekvensen är praktisk: en .ovpn- eller WireGuard-fil ersätter inte de fälten, eftersom handskakningen är ett annat protokoll.
Läs nyttolasten innan du jämför funktioner
När profilen är IKEv2 förklarar nyttolastens nycklar fler fel än någon funktionsjämförelse. Apples referens för IKEv2-inställningar dokumenterar varje nyckel; en trimmad nyttolast ser ut så här:
<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 fält bär större delen av den diagnostiska vikten. RemoteIdentifier är namnet som klienten förväntar sig att servern presenterar, så en gateway bakom NAT eller en lastbalanserare vars certifikat anger poolen i stället för adressen misslyckas trots att adressen är rätt. LocalIdentifier är den identitet servern tror att du har, och med certifikatautentisering måste den matcha den identitet som är kopplad till ditt konto. ServerCertificateIssuerCommonName låser den utfärdande CA:n, så en profil kan misslyckas den dag certifikatet återutfärdas, utan att något felmeddelande nämner certifikat.
Om AuthenticationMethod är SharedSecret utför servern EAP-användarautentisering, och hemligheten du fick är i själva verket en kontouppgift. Det spelar roll när en leverantör skickar två dokument, ett för användarnamn och lösenord och ett för ett certifikat, och bara ett stämmer med det du importerade.
Vad appen kan som den inbyggda klienten inte kan
Protokollvalet är den självklara fördelen. Om din server talar WireGuard eller OpenVPN är en app den enda iOS-klienten som kan använda det, och att redigera det inbyggda formuläret förhandlar inte fram det. En app kan också implementera delad tunnel efter destination eller app, egen DNS-hantering, en blockering i kill switch-stil, serverval och återanslutning anpassad till sitt eget nätverk.
Priset är programvara du inte har granskat, som körs med en nätverksutvidgnings behörigheter. Kvaliteten varierar mer än butikslistningarna antyder: en app återansluter rent medan en annan läcker i några sekunder efter ett nätverksbyte, och en kill switch inuti appen är en funktion i den appen, inte i iOS. På en hanterad enhet ska du först kontrollera den godkända listan.
Vad den inbyggda IKEv2-profilen gör rätt
Färre rörliga delar är hela argumentet. IKEv2-klienten och dess IPsec-stack följer med operativsystemet, så det finns ingen utvidgning som kan krascha, ingen process per app att hålla vid liv och ingen tredjeparts uppdateringscykel mellan dig och en fungerande tunnel. En profil kan också låsas: på en övervakad enhet kan användaren inte ta bort det som hanteringen installerat, och Always On VPN, som återansluter på alla nätverk utan en användarreglage, finns bara i den övervakade, profilhanterade formen.
Det den inbyggda vägen inte ger dig är flexibilitet. Det finns ingen VPN per app utan hanterade appar, ingen kill switch för användaren och ingen transport som ser ut som HTTPS på ett nätverk som blockerar IPsec. På hotellnätverk som tappar UDP 500 och 4500 har inbyggd IKEv2 ingen reservväg.
En beslutstabell som avgör de flesta fall
I praktiken avgör protokollfrågan de flesta fall innan funktionerna spelar roll.
| 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 |
Två rader förtjänar en andra titt. Ett krav per app på en personlig telefon är fallet folk läser fel: inställningen finns i iOS men styrs av hanteringen, så en ohanterad enhet erbjuder den inte. Ett blockerat nätverk är inte ett skäl att misstro IKEv2; det är skälet till att leverantörens app finns.
Verifiera valet med ett test
Testa fellägena, inte anslutningsknappen. Anslut en gång, bekräfta att VPN-indikatorn visas, öppna sedan en sida som skickar tillbaka din publika adress och jämför den med den förra. Byt från Wi-Fi till mobildata utan att röra VPN och håll utkik efter en återanslutning, kör sedan telefonen genom flygplansläge. Starta om och se om tunneln kommer tillbaka av sig själv: en profil med OnDemandEnabled bör göra det, medan många appar måste öppnas först.
När den inte kommer tillbaka, dela felet efter om det överhuvudtaget finns en tunnel. Ingen VPN-indikator betyder att tunneln aldrig kom upp: antingen misslyckades handskakningen på RemoteIdentifier, den låsta CA:n eller en inloggningsuppgift, eller så försöktes aldrig anslutningen eftersom on demand-regeln inte matchade och ingen app startade den. En indikator med felande trafik betyder routning, DNS eller serverpolicy, och att installera om klienten rör inget av det.
En kort lista så att enheten kan förklaras för nästa person:
- en VPN-post, inte två;
- profilen eller appen namngiven efter servern den ansluter till;
- identitetsvärdena nedskrivna där du kan hitta dem.
Börja med protokollraden i tabellen, och stanna där om den besvarar frågan.