Varför din iPhone-app inte kan slå på eller av systemets VPN

En produktchef ber om en knapp som slår på företagets VPN, och förfrågan låter trivial. På iOS är detta ingen liten funktion; den ligger utanför det offentliga kontraktet, och varje kringgående misslyckas antingen i granskningen eller går sönder i nästa version. Kör förfrågan genom vad plattformen faktiskt tillåter, och designen skriver sig till stor del själv. En app kan äga en VPN-konfiguration och starta den. En app kan inte nå systemets strömbrytare, kan inte läsa statusen för en profil som den inte själv har skapat och kan inte hålla en användare ansluten mot dennes vilja.

Börja med de tre saker användaren menar

Separera betydelserna innan du separerar API:erna. Ibland vill användaren att appens tunnel ska vara ansluten, ibland vill hen slå på strömbrytaren i Inställningar för en profil som någon annan har installerat, och ibland vill hen att telefonen inte ska kunna surfa utan tunneln. Det motsvarar tre olika mekanismer, och bara den första är öppen för en vanlig app.

Den andra betydelsen är den som skapar Stack Overflow-frågorna, och den har inget stött svar. Strömbrytaren i Inställningar tillhör användaren och, på hanterade enheter, profilen. Inget offentligt API listar VPN-konfigurationer, rapporterar om systemtunneln är uppe eller växlar den.

Vad en app faktiskt kan skapa

NetworkExtension ger en app en egen konfiguration via NEVPNManager. Med Personal VPN-rättigheten och användarens samtycke sparar appen en konfiguration som visas i Inställningar under sitt eget namn, och den kan starta eller stoppa just den anslutningen. Det är en verklig, granskningsbar förmåga, och det är också hela omfattningen: hanteraren läser och skriver bara det den själv har skapat.

Rättigheten är inte automatisk. Du ansöker om den hos Apple och motiverar varför appen överhuvudtaget behöver en tunnel, och en klient vars enda mål är att slå på någon annans profil har inget bra svar. Leverantörer av pakettunnlar följer samma regel med en annan klass: NETunnelProviderManager äger leverantörsbaserade konfigurationer som appen själv har installerat. Ingen av vägarna når en profil som MDM har levererat.

Samtycke gäller även vid sparning. Att skriva en konfiguration frågar användaren, och den frågan är inte något en app får undertrycka för enkelhetens skull.

Att läsa statusen träffar samma vägg

Status ser vänligare ut än kontroll och är lika stängd. NEVPNStatus rapporterar ogiltig, frånkopplad, ansluter, ansluten, bekräftar igen eller kopplar från för appens egen konfiguration, och en avisering utlöses vid varje ändring. Det säger ingenting om en tunnel som installerats av en hanteringsprofil, och det är just den status en supportdesk vill se.

Nätverksvägsovervakning och gränssnittsändringar erbjuds som ersättningar i designgranskningar. De beskriver den väg appens trafik tar, som ändras av skäl utan koppling till VPN-statusen, och att använda dem som VPN-avläsning ger ett gränssnitt som ljuger åt båda hållen.

On Demand och Always On är de riktiga spakarna

De stödda spakarna bor i profilen och inte i appen. On Demand-regler talar om för systemet när det ska ansluta: en ordnad lista med villkor och åtgärder, bedömd av operativsystemet, inte av din kod. En regel som ansluter på vilket gränssnitt som helst skapar en känsla av alltid ansluten utan att ge någon app kontroll.

Always On VPN är tvingandemekanismen, och den är knuten till övervakning. På en övervakad enhet installerar MDM en profil som håller tunneln uppe; på en personlig telefon utan övervakning ger samma nycklar inte samma beteende. Den asymmetrin är avsiktlig, och ingen kombination av nyttolastnycklar tar bort den. När kravet verkligen är att VPN:en måste vara på, är kravet egentligen att enheten måste hanteras.

Mellan de två sitter den svagare kusinen: en regel som återansluter efter att användaren har kopplat från. Den återansluter när regeln utvärderas nästa gång, vilket inte är samma sak som omedelbart, och en användare som kopplade från med avsikt kommer att märka skillnaden. Designa gränssnittet kring den luckan i stället för att lova ett lås.

Leverera den stödda vägen

Fyra frågor avgör mekanismen innan det finns någon kod: vem som äger enheten, om den är övervakad, vilken klient som avslutar tunneln och var profilen kommer ifrån. Om något av detta är okänt är funktionsförfrågan inte redo att uppskattas.

Ett privat API som petar i systemets VPN klarar en demo och faller i granskningen, och om det levereras på annat sätt går det sönder i nästa iOS-version. Det finns ingen version av den affären som är värd det för en strömbrytare.

Hanteringstelemetri är en egen kanal: den rapporterar att en profil är installerad och om enheten är kompatibel, vilket är rapportering och inte en kontrollvy per app. Testa flödet på en riktig enhet efter varje uppdatering, eftersom det stödda beteendet lever i operativsystemet och operativsystemet rör sig.