Waarom je iPhone-app het systeem-VPN niet aan of uit kan zetten

Een productmanager vraagt om een knop die het bedrijfs-VPN aanzet, en het verzoek klinkt triviaal. Op iOS is dat geen kleine functie; hij staat buiten het publieke contract, en elke omweg faalt in de review of breekt in de volgende release. Voer het verzoek door wat het platform werkelijk toestaat, en het ontwerp schrijft zich grotendeels zelf. Een app kan een VPN-configuratie bezitten en die starten. Een app kan de systeemschakelaar niet bereiken, kan de status van een profiel dat hij niet zelf heeft aangemaakt niet lezen, en kan een gebruiker niet tegen zijn wil verbonden houden.

Begin bij de drie dingen die de gebruiker bedoelt

Scheid de betekenissen voordat je de API’s scheidt. Soms wil de gebruiker de tunnel van je app verbonden, soms wil hij de schakelaar in Instellingen omzetten voor een profiel dat iemand anders heeft geïnstalleerd, en soms wil hij dat de telefoon niet kan browsen zonder de tunnel. Die komen overeen met drie verschillende mechanismen, en alleen de eerste is open voor een gewone app.

De tweede betekenis is degene die de Stack Overflow-vragen oplevert, en er is geen ondersteund antwoord op. De schakelaar in Instellingen is van de gebruiker en, op beheerde apparaten, van het profiel. Geen enkele openbare API somt VPN-configuraties op, meldt of de systeemtunnel actief is of zet hem om.

Wat een app werkelijk kan aanmaken

NetworkExtension geeft een app een eigen configuratie via NEVPNManager. Met het Personal VPN-recht en toestemming van de gebruiker slaat de app een configuratie op die in Instellingen onder zijn eigen naam verschijnt, en hij kan die ene verbinding starten of stoppen. Dat is een echte, toetsbare mogelijkheid, en het is ook de hele reikwijdte: de beheerder leest en schrijft alleen wat hij zelf heeft aangemaakt.

Het recht is niet automatisch. Je vraagt het bij Apple aan en onderbouwt waarom de app überhaupt een tunnel nodig heeft, en een klant wiens enige doel is het profiel van iemand anders aan te zetten heeft geen goed antwoord. Aanbieders van pakkettunnels volgen dezelfde regel met een andere klasse: NETunnelProviderManager bezit aanbiedergebaseerde configuraties die de app zelf heeft geïnstalleerd. Geen van beide paden bereikt een profiel dat MDM heeft geleverd.

Toestemming geldt ook bij het opslaan. Het schrijven van een configuratie vraagt de gebruiker, en die vraag is niet iets wat een app voor het gemak mag onderdrukken.

Het lezen van de status stuit op dezelfde muur

Status lijkt vriendelijker dan besturing en is even gesloten. NEVPNStatus meldt ongeldig, verbroken, verbindt, verbonden, bevestigt opnieuw of verbreekt voor de eigen configuratie van de app, en bij elke wijziging gaat er een melding af. Het zegt niets over een tunnel die door een beheerprofiel is geïnstalleerd, en dat is precies de status die een helpdesk wil zien.

Netwerkpadmonitoring en interfacewijzigingen worden in ontwerpreviews als vervanging aangeboden. Ze beschrijven het pad dat het verkeer van de app neemt, dat verandert om redenen die niets met de VPN-status te maken hebben, en ze als VPN-uitlezing gebruiken levert een interface op die in beide richtingen liegt.

On Demand en Always On zijn de echte hefbomen

De ondersteunde hefbomen leven in het profiel en niet in de app. On-Demand-regels vertellen het systeem wanneer het moet verbinden: een geordende lijst van voorwaarden met acties, beoordeeld door het besturingssysteem, niet door jouw code. Een regel die op elke interface verbindt, creëert een altijd-verbonden-gevoel zonder enige app controle te geven.

Always On VPN is het handhavingsmechanisme, en het is gekoppeld aan toezicht. Op een apparaat onder toezicht installeert MDM een profiel dat de tunnel in stand houdt; op een persoonlijke telefoon zonder toezicht geven dezelfde sleutels niet hetzelfde gedrag. Die asymmetrie is bewust, en geen combinatie van payload-sleutels haalt hem weg. Wanneer de eis werkelijk is dat het VPN aan moet staan, is de eis eigenlijk dat het apparaat beheerd moet worden.

Tussen de twee zit de zwakkere neef: een regel die opnieuw verbindt nadat de gebruiker heeft verbroken. Hij verbindt opnieuw wanneer de regel de volgende keer wordt beoordeeld, wat niet hetzelfde is als onmiddellijk, en een gebruiker die opzettelijk verbrak zal het verschil merken. Ontwerp de interface rond die kloof in plaats van een slot te beloven.

Lever het ondersteunde pad

Vier vragen bepalen het mechanisme voordat er code is: wie het apparaat bezit, of het onder toezicht staat, welke client de tunnel beëindigt en waar het profiel vandaan komt. Als iets daarvan onbekend is, is het functieverzoek niet klaar om te worden ingeschat.

Een privé-API die aan het systeem-VPN peutert, haalt een demo en faalt in de review, en als hij via een andere weg wordt geleverd, breekt hij in de volgende iOS-release. Er is geen versie van die ruil die voor één schakelaar de moeite waard is.

Beheertelemetrie is een apart kanaal: het meldt dat een profiel is geïnstalleerd en of het apparaat voldoet, wat rapportage is en geen besturingsoppervlak per app. Test de stroom op een echt apparaat na elke update, want het ondersteunde gedrag leeft in het besturingssysteem en het besturingssysteem beweegt.