VPN-app of ingebouwde IKEv2 op iPhone: hoe je kiest

Vorige week gaf een collega me zijn iPhone met twee VPN-vermeldingen in Instellingen: een van een provider-app, een uit een IKEv2-profiel dat uit een supportpagina was geplakt. Het zijn geen concurrerende versies van hetzelfde. Een provider-app is een container die zijn eigen tunnelcode kan meebrengen, terwijl Apple's ingebouwde client een IKEv2-client is, met de hand of via een profiel geconfigureerd. Protocol, omgang met inloggegevens, apparaatbeheer en herstel bepalen de keuze.

De app en de native client zitten op verschillende lagen

Apple's ingebouwde VPN-client is in de praktijk een IKEv2-client. Het handmatige formulier noemt nog de verouderde L2TP over IPsec en Cisco IPsec-opties, maar er is geen veld voor een providertransport en nergens om een OpenVPN- of WireGuard-configuratie te plakken. Je vult een formulier in bij Instellingen > Algemeen > VPN & Apparaatbeheer of importeert een profiel met een VPN-payload; het oppervlak bestaat uit een serveradres, twee identiteiten, een authenticatiemethode en optionele regels voor on demand.

Een provider-app werkt een laag hoger. Hij levert een Network Extension packet tunnel provider, zodat de protocolcode en de routeringslogica in de app zitten en iOS alleen pakketten doorgeeft. Sommige apps implementeren WireGuard of OpenVPN, sommige een eigen verhulde transport, en een paar installeren alleen een IKEv2-profiel en besturen de native client achter een mooier scherm. Die laatste groep is de reden dat app tegenover profiel soms een valse keuze is.

De consequentie is praktisch: een .ovpn- of WireGuard-bestand vervangt die velden niet, omdat de handshake een ander protocol is.

Lees de payload voordat je functies vergelijkt

Als het profiel IKEv2 is, verklaren de payloadsleutels meer storingen dan welke functievergelijking dan ook. Apples referentiegids voor IKEv2-instellingen documenteert elke sleutel; een ingekorte payload ziet er zo uit:

<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 velden dragen het grootste deel van het diagnostische gewicht. RemoteIdentifier is de naam die de client van de server verwacht, dus een gateway achter NAT of een load balancer waarvan het certificaat de pool in plaats van het adres noemt, faalt terwijl het adres klopt. LocalIdentifier is wie de server denkt dat je bent, en bij certificaatauthenticatie moet die overeenkomen met de identiteit die aan je account is gekoppeld. ServerCertificateIssuerCommonName legt de uitgevende CA vast, dus een profiel kan falen op de dag dat het certificaat opnieuw wordt uitgegeven, zonder foutmelding die certificaten noemt.

Als AuthenticationMethod gelijk is aan SharedSecret, doet de server EAP-gebruikersauthenticatie en is het geheim dat je kreeg in werkelijkheid een accountreferentie. Dat telt wanneer een provider twee documenten stuurt, een voor gebruikersnaam en wachtwoord en een voor een certificaat, en er maar een overeenkomt met wat je hebt geïmporteerd.

Wat de app kan en de native client niet

Protocolkeuze is het duidelijke voordeel. Als je server WireGuard of OpenVPN spreekt, is een app de enige iOS-client die het kan gebruiken, en het native formulier aanpassen onderhandelt het niet. Een app kan ook split tunnelling op bestemming of app implementeren, eigen DNS-afhandeling, een blokkade in de stijl van een kill switch, serverselectie en herverbinding afgestemd op het eigen netwerk.

De prijs is software die je niet hebt gecontroleerd, draaiend met de rechten van een network extension. De kwaliteit varieert meer dan de winkelvermeldingen suggereren: de ene app herverbindt netjes terwijl een andere na een netwerkwissel een paar seconden lekt, en een kill switch in de app is een functie van die app, niet van iOS. Controleer op een beheerd apparaat eerst de goedgekeurde lijst.

Wat het native IKEv2-profiel goed doet

Minder bewegende delen is het hele argument. De IKEv2-client en zijn IPsec-stack komen met het besturingssysteem mee, dus er is geen extensie die kan crashen, geen proces per app dat in leven moet blijven en geen updatecyclus van derden tussen jou en een werkende tunnel. Een profiel kan ook vergrendeld worden: op een gecontroleerd apparaat kan de gebruiker niet verwijderen wat beheer heeft geïnstalleerd, en Always On VPN, dat op elk netwerk opnieuw verbindt zonder schakelaar voor de gebruiker, bestaat alleen in die gecontroleerde, door profielen beheerde vorm.

Wat het native pad je niet geeft, is flexibiliteit. Er is geen VPN per app zonder beheerde apps, geen kill switch voor de gebruiker en geen transport dat op HTTPS lijkt in een netwerk dat IPsec blokkeert. In hotelnetwerken die UDP 500 en 4500 laten vallen, heeft native IKEv2 geen terugval.

Een beslistabel dat de meeste gevallen oplost

In de praktijk beslist de protocolvraag de meeste gevallen voordat functies ertoe doen.

Twee rijen verdienen een tweede blik. Een eis per app op een persoonlijke telefoon is het geval dat mensen verkeerd lezen: de instelling bestaat in iOS maar wordt door beheer aangestuurd, dus een niet-beheerd apparaat biedt hem niet aan. Een geblokkeerd netwerk is geen reden om IKEv2 te wantrouwen; het is de reden dat de app van de provider bestaat.

Controleer de keuze met één testrun

Test de faalmodi, niet de verbindingsknop. Verbind één keer, bevestig dat de VPN-indicator verschijnt, open dan een pagina die je openbare adres teruggeeft en vergelijk dat met het vorige. Schakel van Wi-Fi naar mobiele data zonder de VPN aan te raken en let op een herverbinding, en laat de telefoon daarna door vliegtuigmodus gaan. Herstart en kijk of de tunnel vanzelf terugkomt: een profiel met OnDemandEnabled zou dat moeten doen, terwijl veel apps eerst geopend moeten worden.

Als hij niet terugkomt, splits de storing dan op basis van of er überhaupt een tunnel is. Geen VPN-indicator betekent dat de tunnel nooit is opgekomen: of de handshake faalde op RemoteIdentifier, op de vastgezette CA of op een inloggegeven, of de verbinding is nooit geprobeerd omdat de on-demand-regel niet overeenkwam en geen app hem startte. Een indicator met falend verkeer betekent routering, DNS of beleid aan de serverkant, en de client opnieuw installeren raakt daar niets van.

Een korte lijst om het apparaat uitlegbaar te laten voor de volgende persoon:

• één VPN-vermelding, niet twee;
• het profiel of de app genoemd naar de server waarmee het verbindt;
• de identiteitswaarden opgeschreven waar je ze kunt vinden.

Begin met de protocolrij in de tabel, en stop daar als die de vraag beantwoordt.