Android: Always-On e blocco senza VPN, scegliere la coppia giusta

Always-On e il blocco senza VPN sono due impostazioni e attivare la prima non attiva la seconda. La coppia giusta dipende da chi possiede il dispositivo, quali app copre il tunnel e cosa succede prima dello sblocco.

Due interruttori con promesse diverse

Always-On promette persistenza e riavvia il servizio quando cade; il blocco promette confinamento: senza tunnel il traffico coperto non ha una via d uscita.

Il terzo fattore è l ambito per app, che appartiene al client o alla politica di gestione, non ai due interruttori di sistema; bloccare senza decidere l ambito produce una politica più ampia o più stretta del necessario.

Decisione uno: dispositivo gestito o impostazione utente?

Su un dispositivo gestito la politica detiene Always-On e il blocco, e l interruttore locale può mancare; cambiate il requisito nella politica, non sul dispositivo.

Su un dispositivo personale l utente decide se accettare l assenza di rete quando il tunnel non c è; il blocco è uno scambio di disponibilità e un interruttore mancante non giustifica il root.

L ambito è per profilo, non per dispositivo: Android consente un solo VPN attivo per profilo utente.

Un blocco nel profilo di lavoro non dice nulla del lato personale e testare un contesto non convalida l altro.

Decisione due: bloccare tutto o escludere alcune app?

Le esclusioni per app in modalità blocco si intendono al contrario: secondo Android le app escluse possono perdere la connessione invece di usare in silenzio la rete normale, quindi escludere non è un permesso per internet.

Scegliete consapevolmente: bloccate tutto il traffico coperto e accettate che le app escluse restino al buio, oppure disattivate il blocco e accettate la via alternativa; se un app deve essere sempre connessa, il blocco è lo strumento sbagliato.

Decisione tre: cosa succede prima dello sblocco e su un portale?

Nella maggior parte dei client il tunnel non è attivo finché l utente non sblocca il dispositivo, quindi i primi istanti dopo l avvio sono un vuoto, non un guasto; confermatelo per il client che distribuite.

I portali captive sono l altro bordo: una rete di hotel o aeroporto richiede una sessione browser non autenticata e un blocco rigido può rendere impossibile l accesso; la risposta supportata è un flusso di ripristino approvato con trigger, durata massima, chi lo concede e la verifica che l applicazione torni da sola.

La documentazione sui client VPN Android copre Always-On, blocco, esclusioni per app e la regola di un VPN per profilo; leggetela prima di progettare a memoria.

Provate lo stato offline e poi scrivete la riga di accettazione

Usate traffico innocuo e il test di guasto supportato: connessione normale, perdita del tunnel, ripristino e riavvio prima dello sblocco, annotando se l app è stata bloccata come previsto.

Verificate la risorsa e il resolver, non l icona, e provate a parte un dispositivo dietro il telefono, perché la politica del telefono non crea inoltro per i client hotspot.

La riga di accettazione è concreta e verificabile: l app prevista nel profilo previsto raggiunge il tunnel approvato e resta bloccata quando non può. Prima di firmarla:

• Always-On e blocco sono configurati dove la piattaforma li supporta e il proprietario di ogni impostazione è noto.
• L ambito delle app è deliberato e avete confermato cosa succede alle app escluse in modalità blocco.
• Il vuoto prima dello sblocco e il flusso del portale captive sono decisi, non scoperti.
• Il test di guasto è stato eseguito sulla classe di dispositivi che distribuite davvero.