De ce aplicația ta pentru iPhone nu poate porni sau opri VPN-ul sistemului

Un manager de produs cere un buton care pornește VPN-ul companiei, iar cererea sună banal. Pe iOS aceasta nu este o funcție mică; se află în afara contractului public, iar fiecare ocol fie pică la revizuire, fie se rupe în următoarea versiune. Treci cererea prin ce permite platforma cu adevărat, iar designul se scrie în mare parte singur. O aplicație poate deține o configurație VPN și o poate porni. O aplicație nu poate ajunge la întrerupătorul sistemului, nu poate citi starea unui profil pe care nu l-a creat și nu poate ține un utilizator conectat împotriva voinței lui.

Începe cu cele trei lucruri la care se referă utilizatorul

Separă semnificațiile înainte de a separa API-urile. Uneori utilizatorul vrea ca tunelul aplicației tale să fie conectat, uneori vrea să comute întrerupătorul din Setări pentru un profil instalat de altcineva, iar uneori vrea ca telefonul să nu poată naviga fără tunel. Acestea corespund la trei mecanisme diferite, iar doar primul este deschis unei aplicații obișnuite.

A doua semnificație este cea care generează întrebările de pe Stack Overflow și nu are un răspuns susținut. Întrerupătorul din Setări aparține utilizatorului și, pe dispozitivele gestionate, profilului. Nicio API publică nu enumeră configurații VPN, nu raportează dacă tunelul sistemului este activ și nu îl comută.

Ce poate crea de fapt o aplicație

NetworkExtension îi dă unei aplicații o configurație proprie prin NEVPNManager. Cu dreptul Personal VPN și consimțământul utilizatorului, aplicația salvează o configurație care apare în Setări sub numele ei, și poate porni sau opri acea singură conexiune. Este o capacitate reală și verificabilă, și este totodată întregul domeniu: managerul citește și scrie doar ce a creat.

Dreptul nu este automat. Îl ceri de la Apple și justifici de ce aplicația are nevoie de un tunel, iar un client al cărui singur scop este să pornească profilul altcuiva nu are un răspuns bun. Furnizorii de tuneluri pe pachete urmează aceeași regulă cu altă clasă: NETunnelProviderManager deține configurații bazate pe furnizor pe care aplicația însăși le-a instalat. Niciuna dintre căi nu ajunge la un profil livrat de MDM.

Consimțământul se aplică și la salvare. Scrierea unei configurații cere utilizatorului, iar acea solicitare nu este ceva ce o aplicație poate suprima pentru comoditate.

Citirea stării lovește în același zid

Starea pare mai prietenoasă decât controlul și este la fel de închisă. NEVPNStatus raportează invalid, deconectat, conectare, conectat, reafirmare sau deconectare pentru configurația proprie a aplicației, iar la fiecare schimbare pornește o notificare. Nu spune nimic despre un tunel instalat de un profil de administrare, iar aceasta este exact starea pe care un help desk vrea să o vadă.

Monitorizarea traseului de rețea și modificările de interfață sunt oferite ca substitute în revizuirile de design. Ele descriu traseul pe care merge traficul aplicației, care se schimbă din motive fără legătură cu starea VPN, iar folosirea lor ca citire VPN dă o interfață care minte în ambele direcții.

On Demand și Always On sunt pârghiile reale

Pârghiile acceptate trăiesc în profil, nu în aplicație. Regulile On Demand spun sistemului când să se conecteze: o listă ordonată de condiții cu acțiuni, evaluată de sistemul de operare, nu de codul tău. O regulă care se conectează pe orice interfață creează senzația de conectare permanentă fără a da aplicației vreun control.

Always On VPN este mecanismul de impunere și este legat de supraveghere. Pe un dispozitiv supravegheat, MDM instalează un profil care ține tunelul activ; pe un telefon personal nesupravegheat aceleași chei nu produc același comportament. Această asimetrie este intenționată și nicio combinație de chei de încărcătură nu o elimină. Când cerința este într-adevăr ca VPN-ul să fie pornit, cerința este de fapt ca dispozitivul să fie gestionat.

Între cele două stă vărul mai slab: o regulă care se reconectează după ce utilizatorul se deconectează. Se reconectează când regula este evaluată data viitoare, ceea ce nu este același lucru cu imediat, iar un utilizator care s-a deconectat intenționat va observa diferența. Proiectează interfața în jurul acelei lacune în loc să promiți un lacăt.

Livrează calea acceptată

Patru întrebări stabilesc mecanismul înainte să existe cod: cine deține dispozitivul, dacă este supravegheat, ce client încheie tunelul și de unde vine profilul. Dacă vreuna dintre ele este necunoscută, cererea de funcționalitate nu este gata de estimare.

O API privată care bâjbâie prin VPN-ul sistemului va trece un demo și va pica la revizuire, iar dacă este livrată pe altă cale se rupe în următoarea versiune iOS. Nu există versiune a acestui schimb care să merite pentru un întrerupător.

Telemetria de administrare este un canal separat: raportează că un profil este instalat și dacă dispozitivul este conform, ceea ce este raportare, nu o suprafață de control pentru fiecare aplicație. Testează fluxul pe un dispozitiv real după fiecare actualizare, pentru că comportamentul acceptat trăiește în sistemul de operare, iar sistemul de operare se mișcă.