VPN-app of ynboude IKEv2 op iPhone: hoe't jo kieze
In iPhone-VPN-app en de ynboude IKEv2-klient oplosse ferskillende problemen. Fergelykje earst protokolstipe, autentikaasje, apparaatbehear en werstel.
Ferline wike joech in kollega my syn iPhone mei twa VPN-ynskriuwingen yn Ynsteldingen: ien efterlitten troch in oanbieder-app, ien út in IKEv2-profyl dat fan in stipepagina plakt wie. It binne gjin konkurrearjende ferzjes fan itselde. In oanbieder-app is in kontener dy't syn eigen tunnelkoade meinimme kin, wylst de ynboude klant fan Apple in IKEv2-klant is, mei de hân of fia in profyl konfigurearre. Protokol, omgong mei oanmeldgegevens, apparaatbehear en werstel bepale de kar.
De app en de native klant sitte op ferskillende lagen
De ynboude VPN-klant fan Apple is yn 'e praktyk in IKEv2-klant. It hanmjittige formulier neamt noch de ferâldere L2TP oer IPsec en Cisco IPsec-opsjes, mar der is gjin fjild foar in transport fan de oanbieder en nearne om in OpenVPN- of WireGuard-konfiguraasje te plakken. Jo folje in formulier yn by Ynsteldingen > Algemien > VPN & Apparaatbehear of jo ymportearje in profyl mei in VPN-payload; it oerflak is in serveradres, twa identiteiten, in autentikaasjemetoade en opsjonele on demand-regels.
In oanbieder-app wurket in laach heger. Hy leveret in Network Extension packet tunnel provider, sadat de protokolkoade en de routinglogika yn 'e app sitte en iOS allinnich pakketten trochjaan lit. Guon apps ymplementearje WireGuard of OpenVPN, oaren in eigen ferburgen transport, en in pear ynstallearje allinnich in IKEv2-profyl en bestjoere de native klant efter in moaier skerm. Dy lêste groep is de reden dat app tsjin profyl soms in falske kar is.
It gefolch is praktysk: in .ovpn- of WireGuard-bestân ferfangt dy fjilden net, om't de handshake in oar protokol is.
Lês de payload foardat jo funksjes fergelykje
As it profyl IKEv2 is, ferklearje de payloadkaaien mear flaters as hokker funksjefergeliking dan ek. Apple syn referinsje foar IKEv2-ynstellingen dokumintearret elke kaai; in ynsnoeide payload sjocht der sa út:
<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>Trije fjilden drage it grutste part fan it diagnostyske gewicht. RemoteIdentifier is de namme dy't de klant fan de server ferwachtet, sadat in gateway efter NAT of in load balancer waans sertifikaat de pool ynstee fan it adres neamt, flateret wylst it adres kloppet. LocalIdentifier is wa't de server tinkt dat jo binne, en by sertifikaatautentikaasje moat dy oerienkomme mei de identiteit dy't oan jo akkount keppele is. ServerCertificateIssuerCommonName fêstiget de útjaande CA, sadat in profyl flaterje kin op 'e dei dat it sertifikaat opnij útjûn wurdt, sûnder dat in flaterberjocht sertifikaten neamt.
As AuthenticationMethod gelyk is oan SharedSecret, docht de server EAP-brûkersautentikaasje en is it geheim dat jo krigen ha yn wierheid in akkountreferinsje. Dat telt as in oanbieder twa dokuminten stjoert, ien foar brûkersnamme en wachtwurd en ien foar in sertifikaat, en mar ien oerienkomt mei wat jo ymportearre ha.
Wat de app kin en de native klant net
De protokolkar is it fanselssprekkende foardiel. As jo server WireGuard of OpenVPN praat, is in app de iennige iOS-klant dy't it brûke kin, en it bewurkjen fan it native formulier sil it net ûnderhannelje. In app kin ek split tunnelling op bestimming of app ymplementearje, eigen DNS-ôfhanneling, in blokkade yn 'e styl fan in kill switch, serverseleksje en werferbining ôfstimd op syn eigen netwurk.
De priis is software dy't jo net audite ha, draaiend mei de rjochten fan in network extension. De kwaliteit fariearret mear as de winkelfermeldingen suggerearje: de iene app ferbynt wer skjin wylst in oare nei in netwurkskift in pear sekonden lekket, en in kill switch yn 'e app is in funksje fan dy app, net fan iOS. Kontrolearje op in beheard apparaat earst de goedkarde list.
Wat it native IKEv2-profyl goed docht
Minder beweegjende dielen is it hiele argumint. De IKEv2-klant en syn IPsec-stack komme mei it bestjoeringssysteem, dus der is gjin ekstinsje dy't crashe kin, gjin proses per app dat libben holden wurde moat en gjin update-syklus fan tredden tusken jo en in wurkjende tunnel. In profyl kin ek ferskoattele wurde: op in beheard apparaat kin de brûker net fuorthelje wat it behear ynstallearre hat, en Always On VPN, dat op elk netwurk wer ferbynt sûnder in skakelaar foar de brûker, bestiet allinnich yn dy behearde, troch profyl beheardere foarm.
Wat it native paad jo net jout, is fleksibiliteit. Der is gjin VPN per app sûnder beheardere apps, gjin kill switch foar de brûker en gjin transport dat op HTTPS liket op in netwurk dat IPsec blokkearret. Op hotelnetwurken dy't UDP 500 en 4500 falle litte, hat native IKEv2 gjin weromfal.
In besluttafel dy't de measte gefallen oplost
Yn 'e praktyk beslút de protokolfraach de measte gefallen foardat funksjes der ta dogge.
| 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 |
Twa rigen fertsjinje in twadde eachopslach. In eask per app op in persoanlike telefoan is it gefal dat minsken ferkeard lêze: de ynstelling bestiet yn iOS, mar wurdt troch behear oanstjoerd, sadat in net-beheard apparaat him net oanbiedt. In blokkearre netwurk is gjin reden om IKEv2 te wantrouwen; it is de reden dat de app fan de oanbieder bestiet.
Kontrolearje de kar mei ien testrun
Test de flatermodi, net de ferbiningsknop. Ferbin ien kear, befêstigje dat de VPN-yndikator ferskynt, iepenje dan in side dy't jo iepenbiere adres weromstjoert en fergelykje it mei it foarige. Skeakelje fan Wi-Fi nei mobile data sûnder de VPN oan te reitsjen en let op in werferbining, en lit de telefoan dan troch fleantúchmodus gean. Start opnij en sjoch of de tunnel fansels weromkomt: in profyl mei OnDemandEnabled soe dat moatte, wylst in protte apps earst iepene wurde moatte.
As er net weromkomt, splitsje de flater dan op basis fan oft der oerhaadlik in tunnel is. Gjin VPN-yndikator betsjut dat de tunnel nea omheech kaam: of de handshake mislearre op RemoteIdentifier, op 'e fêstsette CA of op in oanmeldgegevens, of de ferbining waard nea besocht om't de on demand-regel net oerienkaam en gjin app him startte. In yndikator mei mislearjend ferkear betsjut routing, DNS of belied oan 'e serverkant, en de klant opnij ynstallearje rekket dêr neat fan.
In koarte list om it apparaat útlizber te litten foar de folgjende persoan:
- ien VPN-ynskriuwing, net twa;
- it profyl of de app neamd nei de server dêr't it mei ferbynt;
- de identiteitswearden opskreaun wêr't jo se fine kinne.
Begjin mei de protokolrige yn 'e tabel, en stop dêr as dy de fraach beantwurdet.