Perché la tua app per iPhone non può attivare o disattivare la VPN di sistema

Un product manager chiede un pulsante che accenda la VPN aziendale, e la richiesta sembra banale. Su iOS non è una funzione piccola; sta fuori dal contratto pubblico, e ogni aggiramento o fallisce la revisione o si rompe alla release successiva. Passa la richiesta attraverso ciò che la piattaforma permette davvero e il design si scrive in gran parte da solo. Un’app può possedere una configurazione VPN e avviarla. Un’app non può raggiungere l’interruttore di sistema, non può leggere lo stato di un profilo che non ha creato e non può mantenere un utente connesso contro la sua volontà.

Parti dalle tre cose che l’utente intende

Separa i significati prima di separare le API. A volte l’utente vuole il tunnel della tua app connesso, a volte vuole che l’interruttore in Impostazioni sia attivo per un profilo installato da qualcun altro, e a volte vuole che il telefono non possa navigare senza il tunnel. Corrispondono a tre meccanismi diversi, e solo il primo è aperto a un’app normale.

Il secondo significato è quello che genera le domande su Stack Overflow, e non ha una risposta supportata. L’interruttore in Impostazioni appartiene all’utente e, sui dispositivi gestiti, al profilo. Nessuna API pubblica elenca configurazioni VPN, riporta se il tunnel di sistema è attivo né lo commuta.

Cosa può davvero creare un’app

NetworkExtension dà a un’app una configurazione propria tramite NEVPNManager. Con il diritto Personal VPN e il consenso dell’utente, l’app salva una configurazione che appare in Impostazioni con il suo nome, e può avviare o fermare quella singola connessione. È una capacità reale e verificabile, ed è anche l’intero perimetro: il gestore legge e scrive solo ciò che ha creato.

Il diritto non è automatico. Lo richiedi ad Apple e giustifichi perché l’app abbia bisogno di un tunnel, e un client il cui unico scopo è accendere il profilo di qualcun altro non ha una buona risposta. I fornitori di tunnel a pacchetto seguono la stessa regola con un’altra classe: NETunnelProviderManager possiede configurazioni basate sul fornitore che l’app stessa ha installato. Nessuna delle due strade raggiunge un profilo consegnato dall’MDM.

Il consenso vale anche al momento del salvataggio. Scrivere una configurazione chiede all’utente, e quella richiesta non è qualcosa che un’app possa sopprimere per comodità.

Leggere lo stato sbatte contro lo stesso muro

Lo stato sembra più amichevole del controllo ed è altrettanto chiuso. NEVPNStatus riporta non valido, disconnesso, connessione, connesso, riconferma o disconnessione per la configurazione propria dell’app, e a ogni cambiamento scatta una notifica. Non dice nulla di un tunnel installato da un profilo di gestione, che è proprio lo stato che un help desk vuole vedere.

Il monitoraggio del percorso di rete e i cambi di interfaccia vengono offerti come sostituti nelle revisioni di design. Descrivono il percorso che prende il traffico dell’app, che cambia per motivi estranei allo stato della VPN, e usarli come indicatore VPN dà un’interfaccia che mente in entrambe le direzioni.

On Demand e Always On sono le leve vere

Le leve supportate vivono nel profilo e non nell’app. Le regole On Demand dicono al sistema quando connettersi: un elenco ordinato di condizioni con azioni, valutato dal sistema operativo, non dal tuo codice. Una regola che si connette su qualsiasi interfaccia crea una sensazione di connessione permanente senza dare alcun controllo all’app.

Always On VPN è il meccanismo di imposizione, ed è legato alla supervisione. Su un dispositivo supervisionato, l’MDM installa un profilo che mantiene il tunnel attivo; su un telefono personale non supervisionato le stesse chiavi non producono lo stesso comportamento. Quell’asimmetria è deliberata, e nessuna combinazione di chiavi di payload la elimina. Quando il requisito è davvero che la VPN sia accesa, il requisito è in realtà che il dispositivo sia gestito.

Fra i due sta il cugino più debole: una regola che si riconnette dopo che l’utente si è disconnesso. Si riconnette alla successiva valutazione della regola, che non è lo stesso di subito, e un utente che si è disconnesso apposta noterà la differenza. Progetta l’interfaccia intorno a quel vuoto invece di promettere un lucchetto.

Rilascia il percorso supportato

Quattro domande fissano il meccanismo prima che esista codice: chi possiede il dispositivo, se è supervisionato, quale client termina il tunnel e da dove arriva il profilo. Se una di queste è ignota, la richiesta di funzionalità non è pronta per la stima.

Un’API privata che armeggia con la VPN di sistema supererà una demo e fallirà la revisione, e se viene distribuita per altre vie si rompe alla release iOS successiva. Non esiste versione di questo scambio che valga la pena per un interruttore.

La telemetria di gestione è un canale a parte: riporta che un profilo è installato e se il dispositivo è conforme, che è reportistica e non una superficie di controllo per app. Prova il flusso su un dispositivo reale dopo ogni aggiornamento, perché il comportamento supportato vive nel sistema operativo e il sistema operativo si muove.