Interruttore per app contro blocco dell'intero dispositivo: cosa cambia

Un interruttore per app sembra la scelta prudente: solo il client di lavoro perde la rete quando il tunnel cade, e tutto il resto continua a funzionare. Poi qualcuno nota che il browser personale ha comunque caricato una pagina, che l'assistente di sincronizzazione fornito con la stessa suite continuava a riprovare e che un nome in cache si risolveva ancora in un indirizzo che non ha mai toccato il tunnel. L'etichetta della funzione e l'insieme di connessioni che protegge davvero sono due cose diverse. Determinate prima l'insieme protetto, perché è quello che decide se l'applicazione per app o il blocco dell'intero dispositivo è la descrizione onesta.

Cominciate dall'insieme, non dall'etichetta

Una politica per app protegge le applicazioni selezionate. Un blocco del dispositivo punta a un confine di rete più ampio, di solito con eccezioni documentate per la stampa locale, il traffico di gestione o i portali captive. Nessuna delle due etichette è completa finché non potete rispondere a tre domande: cosa succede alle app escluse, cosa succede agli assistenti che quelle app avviano e cosa succede alle connessioni aperte mentre la protezione non è disponibile.

Scrivete queste risposte prima di toccare un'impostazione del client. Se il requisito è "questo client paghe non deve mai parlare con internet fuori dal tunnel, e il mio browser può", l'insieme è piccolo e l'applicazione per app è adatta. Se il requisito è "niente su questo dispositivo raggiunge internet senza protezione, tranne il servizio di aggiornamento", nessuna politica per app lo produrrà, perché le app che non avete nominato sono il problema.

L'applicazione per app abbina identificatori, non nomi di programma

Android espone la VPN per app tramite pacchetti, e la sua documentazione VpnService descrive come questo interagisce con il funzionamento sempre attivo e il blocco. iOS configura la VPN per app tramite un profilo di gestione e abbina per app o per dominio. Windows e Linux non hanno alcuna rotta per processo, quindi la stessa idea è approssimata con una regola del firewall limitata a un programma o con una regola che corrisponde all'utente proprietario.

Il confine è l'identificatore, e gli identificatori sono facili da aggirare. Un'app che consegna un URL al browser di sistema, o apre un documento in un visualizzatore, passa a un processo che la vostra politica non ha mai nominato. Anche un'opzione di terminazione alla caduta non è un filtro di pacchetti: uccide l'app che avete configurato, mentre un processo figlio, un worker di coda o una scheda del browser possono mantenere vivo un socket esistente.

Il blocco copre ciò che una politica per app non può vedere

Il blocco dell'intero dispositivo elimina la scelta. Ogni pacchetto in uscita che non appartiene al tunnel viene scartato, incluso il traffico di processi che la vostra politica delle app non ha mai conosciuto. Su Android è la VPN sempre attiva combinata con l'impostazione di blocco delle connessioni, e l'applicazione avviene nel sistema, non nella finestra del client. Su un desktop è una regola del firewall persistente o una rotta predefinita puntata a un gateway irraggiungibile.

Il costo è che tutto il resto si ferma, quindi le eccezioni diventano parte del progetto invece di un ripensamento. Stampanti locali, scoperta dei servizi, accessi ai portali captive, agenti di gestione e aggiornamenti del sistema operativo hanno ciascuno bisogno di un buco documentato, perché ciascuno è un percorso che resta aperto quando il tunnel è giù. Il blocco è forte solo quanto la voce più corta di quell'elenco.

DNS, IPv6 e assistenti in background nascondono le fughe

Il fatto che un'app protetta non riesca a risolvere un nome non dimostra che le risposte in cache o il traffico IP diretto siano bloccati. Se il resolver è ancora raggiungibile fuori dal tunnel, il nome si risolve e la connessione fallisce, cosa che sembra un interruttore funzionante e non lo è. Peggio, un record in cache può puntare a un indirizzo che il tunnel non trasporta, così la connessione esce direttamente mentre l'app segnala un errore VPN.

IPv6 ha bisogno della propria regola su ogni piattaforma che lo esegue, perché una regola di scarto per v4 non copre una rotta v6. Sul mobile, un'impostazione DNS privata può spostare la risoluzione in un canale cifrato che la politica del dispositivo non ispeziona. E gli assistenti in background sono il colpevole abituale su desktop: un processo di aggiornamento o di sincronizzazione nella tray parte prima del client VPN e mantiene la propria connessione, quindi non vede mai la rotta modificata.

Testate tre app e due transizioni

Eseguite ogni riga due volte, una con un nome host e una con un indirizzo letterale, e ancora una volta su IPv6 se la rete lo offre. Un superamento significa che l'app inclusa si è fermata, quella esclusa si è comportata come avete scritto e l'assistente non è sgusciato fuori. Annotate il comportamento diretto che avete deciso essere accettabile, così il prossimo amministratore può distinguere un'eccezione deliberata da un guasto.

Poi descrivete il risultato in una frase che nomina le app e le condizioni, per esempio: il client paghe non ha alcuna rotta fuori dal tunnel, il browser è diretto per progetto e tutto il resto si ferma quando il tunnel è giù. Se quella frase è difficile da scrivere, la politica è ancora due politiche che si combattono.