Persoonlijke VPN of pakkettunnel: twee VPN-modellen voor iPhone
Het ene model configureert de ingebouwde IPsec of IKEv2 van iOS; het andere levert een provider die zijn eigen protocol implementeert. De productnaam zegt niet welke je hebt gekregen.
Twee iPhone-apps kunnen allebei een VPN-vermelding in Instellingen plaatsen, allebei zichzelf VPN-client noemen en vrijwel geen implementatie delen. Apple noemt een van die integraties Persoonlijke VPN, en die naam veroorzaakt het grootste deel van de verwarring. Persoonlijke VPN is een API voor het maken en beheren van configuraties die de ingebouwde IPsec- of IKEv2-implementatie gebruiken. Een pakkettunnelprovider is het andere model: de app levert een extensie die de clientzijde van zijn eigen protocol implementeert. Alles wat mensen daarna uit het label afleiden, van cijfers tot eigendom tot of de telefoon beheerd moet worden, is afleiding en geen uitspraak.
Wie de tunnel implementeert
De splitsing bepaalt wie verantwoordelijk is als er iets kapotgaat. Met ingebouwde IPsec of IKEv2 bezit iOS de toestandsmachine van de tunnel en bezit de app de configuratie en de knoppen. Met een provider bezit de app beide, dus een protocolfout wordt een app-update in plaats van een besturingssysteemupdate.
De vergelijking is kort als je vraagt wie het protocol implementeert.
| Integration | Apple interface | Protocol implementation |
|---|---|---|
| Personal VPN | NEVPNManager with a Personal VPN configuration | The system IPsec or IKEv2 client |
| Packet tunnel | NETunnelProviderManager plus the provider extension | Whatever the extension implements |
Persoonlijke VPN-documentatie vermeldt ook de expliciete autorisatieprompt voor de gebruiker wanneer een app voor het eerst een configuratie opslaat, wat bij dat model hoort en niet bij VPN-apps in het algemeen.
Twee beweringen over het label die je beter kunt laten vallen
De eerste is dat Persoonlijke VPN een cijfer kiest. Dat doet het niet; de onderhandelde suite komt uit het protocol en zijn configuratie, en een Persoonlijk-label zegt niets over welke je krijgt. De tweede is dat Persoonlijke VPN een proxy of een beperkte tunnel impliceert. Het impliceert ingebouwde IPsec of IKEv2, wat een volledige tunnel is wanneer de routes dat zeggen.
De aanwezigheid van een app is dus geen bewijs over het draadprotocol. Een externe client die WireGuard of OpenVPN spreekt, is per constructie een providerapp, omdat iOS die protocollen niet native implementeert.
Waarom de bedrijfsformulering misleidt
Apple's documentatie classificeert NETunnelProviderManager-configuraties als gewone bedrijfs-VPN-configuraties. Die formulering is een API-categorie, en ze duwt mensen naar twee tegengestelde fouten: aannemen dat een consumentenapp het providermodel niet kan gebruiken, en aannemen dat de telefoon daarvoor onder toezicht moet staan. Geen van beide volgt. Consumentenapps leveren regelmatig providers, en toezicht is een aparte vraag over wie beleid mag handhaven.
Beheereigendom is die vierde vraag, en het is onafhankelijk van beide modellen. Een configuratie die door een organisatie is geïnstalleerd, draagt zijn eigen identiteit, verkeersbereik en levenscyclusregels, en die reizen mee met het profiel en niet met de app die toevallig is geïnstalleerd. Lees ze naast het integratiemodel, want een beheerd ingebouwd profiel en een onbeheerd providerprofiel kunnen tegelijk op één telefoon staan.
Controleer het bewijs in plaats van de schermafbeelding
Schermafbeeldingen zijn het slechtste bewijs dat er is, omdat de groepering in Instellingen tussen releases verandert. Een beheerd profiel noemt zijn eigen payloadtype: een ingebouwd profiel verklaart een VPN-type zoals IKEv2 of IPsec, terwijl een providerprofiel een subtype draagt dat de bundel-id van de provider noemt. Dat is controleerbaar op het apparaat voor je, en het overleeft de volgende herinrichting.
Voor de app zelf beantwoordt de gebruikte klasse dezelfde vraag van de andere kant: configuratieobjecten uit de Persoonlijke VPN-API, of een providermanager en zijn extensie.
Kies dan op basis van wat de operator werkelijk levert. Waar een compatibel native profiel bestaat, heeft het ingebouwde pad minder bewegende delen en één ding minder om bij te werken. Waar de dienst een protocol nodig heeft dat iOS niet levert, is een providerapp de enige optie en wordt het releasetempo ervan deel van je risico.
Bewaar het record bij de verbinding
Koppel authenticatie en resourcebeleid aan het verbindingsrecord in plaats van aan de app, zodat een herinstallatie het autorisatiemodel niet meeneemt. Dat record is ook wat een supportengineer nodig heeft wanneer de tunnel omhoog komt en niets anders werkt.
De vraag die je uiteindelijk moet stellen is niet welk model beter is. Het is welk model je operator ondersteunt, en welke je om twee uur 's nachts kunt debuggen met de tools die je werkelijk hebt.