VPN-app of ingeboude IKEv2 op iPhone: hoe om te kies
’n iPhone-VPN-app en die ingeboude IKEv2-kliënt los verskillende probleme op. Vergelyk eers protokolondersteuning, verifikasie, toestelbeheer en herstel.
Verlede week het ’n kollega sy iPhone aan my oorhandig met twee VPN-inskrywings in Instellings: een wat deur ’n verskaffer-app gelaat is, een uit ’n IKEv2-profiel wat uit ’n ondersteuningsbladsy geplak is. Dit is nie mededingende weergawes van dieselfde ding nie. ’n Verskaffer-app is ’n houer wat sy eie tonnelkode kan dra, terwyl Apple se ingeboude kliënt ’n IKEv2-kliënt is, met die hand of deur ’n profiel opgestel. Protokol, hantering van geloofsbriewe, toestelbeheer en herstel bepaal die keuse.
Die app en die inheemse kliënt lê op verskillende vlakke
Apple se ingeboude VPN-kliënt is in die praktyk ’n IKEv2-kliënt. Die handmatige vorm lys nog die verouderde L2TP oor IPsec en Cisco IPsec-opsies, maar daar is geen verskaffervervoerveld nie en nêrens om ’n OpenVPN- of WireGuard-opstelling te plak nie. Jy vul óf ’n vorm onder Instellings > Algemeen > VPN & Toestelbestuur in óf voer ’n profiel met ’n VPN-lading in; die oppervlak is ’n bedieneradres, twee identiteite, ’n verifikasiemetode en opsionele op-aanvraag-reëls.
’n Verskaffer-app werk een vlak hoër. Dit lewer ’n Network Extension-pakkettonnelverskaffer, so die protokolkode en roeteringslogika woon in die app en iOS gee net pakkette deur. Sommige apps implementeer WireGuard of OpenVPN, ander ’n eie verduisterde vervoer, en ’n paar installeer net ’n IKEv2-profiel en bestuur die inheemse kliënt agter ’n mooier skerm. Dié laaste groep is die rede waarom app teenoor profiel soms ’n valse keuse is.
Die gevolg is prakties: ’n .ovpn- of WireGuard-lêer vervang nie daardie velde nie, want die handdruk is ’n ander protokol.
Lees die lading voordat jy funksies vergelyk
Wanneer die profiel IKEv2 is, verduidelik die lading se sleutels meer foute as enige funksievergelyking. Apple se IKEv2-instellingsverwysing dokumenteer elke sleutel; ’n verkorte lading lyk so:
<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>Drie velde dra die grootste deel van die diagnostiese gewig. RemoteIdentifier is die naam wat die kliënt van die bediener verwag, so ’n poort agter NAT of ’n lasbalanseerder wie se sertifikaat die poel eerder as die adres noem, misluk al is die adres reg. LocalIdentifier is die identiteit wat die bediener dink jy is, en met sertifikaatverifikasie moet dit ooreenstem met die identiteit wat aan jou rekening gekoppel is. ServerCertificateIssuerCommonName pen die uitreikende CA vas, so ’n profiel kan misluk op die dag wanneer die sertifikaat heruitgereik word, sonder dat enige foutboodskap sertifikate noem.
As AuthenticationMethod gelyk is aan SharedSecret, doen die bediener EAP-gebruikerverifikasie en die geheim wat jy gekry het is eintlik ’n rekeninggeloofsbrief. Dit maak saak wanneer ’n verskaffer twee dokumente stuur, een vir gebruikernaam en wagwoord en een vir ’n sertifikaat, en net een pas by wat jy ingevoer het.
Wat die app kan doen en die inheemse kliënt nie
Protokolkeuse is die ooglopende voordeel. As jou bediener WireGuard of OpenVPN praat, is ’n app die enigste iOS-kliënt wat dit kan gebruik, en om die inheemse vorm te wysig sal dit nie beding nie. ’n App kan ook verdeelde tonnel per bestemming of app, sy eie DNS-hantering, ’n blokkade in kill switch-styl, bedienerkeuse en herverbinding ingestel op sy eie netwerk implementeer.
Die prys is sagteware wat jy nie geouditeer het nie, wat met die regte van ’n netwerkuitbreiding loop. Kwaliteit wissel meer as wat die winkelkaarte voorstel: een app herverbind skoon terwyl ’n ander ná ’n netwerkverandering ’n paar sekondes lek, en ’n kill switch binne die app is ’n funksie van daardie app, nie van iOS nie. Op ’n bestuurde toestel, kyk eers na die goedgekeurde lys.
Wat die ingeboude IKEv2-profiel reg kry
Minder bewegende dele is die hele argument. Die IKEv2-kliënt en sy IPsec-stapel kom saam met die bedryfstelsel, so daar is geen uitbreiding wat kan val nie, geen proses per app wat aan die lewe gehou moet word nie, en geen derdeparty-opdateringsiklus tussen jou en ’n werkende tonnel nie. ’n Profiel kan ook gesluit word: op ’n toesigtoestel kan die gebruiker nie verwyder wat bestuur geïnstalleer het nie, en Always On VPN, wat op enige netwerk herverbind sonder ’n gebruikerskakelaar, bestaan net in daardie toesig-, profielbestuurde vorm.
Wat die ingeboude pad nie gee nie, is buigbaarheid. Daar is geen VPN per app sonder bestuurde apps nie, geen kill switch vir die gebruiker nie, en geen vervoer wat soos HTTPS lyk op ’n netwerk wat IPsec blokkeer nie. In hotelnetwerke wat UDP 500 en 4500 laat val, het ingeboude IKEv2 geen terugval nie.
’n Beslissingstabel wat die meeste gevalle besleg
In die praktyk beslis die protokolvraag die meeste gevalle voordat funksies saak maak.
| 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 |
Twee rye verdien ’n tweede kyk. ’n Vereiste per app op ’n persoonlike telefoon is die geval wat mense verkeerd lees: die instelling bestaan in iOS maar word deur bestuur gedryf, so ’n onbestuurde toestel sal dit nie bied nie. ’n Geblokkeerde netwerk is nie ’n rede om IKEv2 te wantrou nie; dit is die rede waarom die verskaffer se app bestaan.
Verifieer die keuse met een toetslopie
Toets die foutmodusse, nie die koppelknoppie nie. Koppel een keer, bevestig dat die VPN-aanwyser verskyn, maak dan ’n bladsy oop wat jou publieke adres terugstuur en vergelyk dit met die vorige. Skakel van Wi-Fi na mobiele data sonder om aan die VPN te raak en let op ’n herverbinding, en laat die telefoon dan deur vliegtuigmodus gaan. Herbegin en kyk of die tonnel vanself terugkom: ’n profiel met OnDemandEnabled behoort, terwyl baie apps eers oopgemaak moet word.
Wanneer dit nie terugkom nie, verdeel die fout volgens of daar hoegenaamd ’n tonnel is. Geen VPN-aanwyser beteken die tonnel het nooit opgekom nie: óf die handdruk het by RemoteIdentifier, die vasgepen CA of ’n geloofsbrief misluk, óf die verbinding is nooit probeer nie omdat die op-aanvraag-reël nie gepas het nie en geen app dit begin het nie. ’n Aanwyser met mislukkende verkeer beteken roetering, DNS of bedienerkant-beleid, en om die kliënt te herinstalleer raak niks daarvan nie.
’n Kort lysie om die toestel vir die volgende persoon verduidelikbaar te laat:
- een VPN-inskrywing, nie twee nie;
- die profiel of app vernoem na die bediener waarmee dit verbind;
- die identiteitswaardes neergeskryf waar jy dit kan vind.
Begin by die protokolry in die tabel, en stop daar as dit die vraag beantwoord.