VPN su iPhone dopo un riavvio: cosa dovrebbe succedere prima
Trasformate «tieni attiva la VPN» in un requisito di avvio: cosa si collega, cosa richiede ancora voi e cosa resta bloccato prima che la prima attività protetta venga eseguita.
«Tieni attiva la VPN» resiste circa trenta secondi di domande. Attiva dopo un riavvio? Attiva prima che sblocchiate il telefono? Attiva mentre il Wi-Fi mostra ancora una pagina di accesso? Bloccare il traffico finché il tunnel non sale o lasciare che la prima app provi la connessione diretta? Sono quattro requisiti diversi, e solo alcuni possono essere garantiti configurando un telefono. Scrivete la risposta come una cronologia con fasi, poi verificate ogni fase dopo un riavvio reale.
| Stage | Personal profile | Supervised Always On |
|---|---|---|
| Before first unlock | do not assume a tunnel | do not assume a tunnel either |
| After unlock, network up | depends on the provider or On Demand rule | activates without user interaction |
| Tunnel negotiating | first app may already be trying | policy decides whether traffic waits |
| Gateway unreachable | usually falls back to whatever the client allows | follows the deployed policy |
Scrivete il requisito come una cronologia
Partite dal momento che conta per l’azienda: quale attività protetta non deve avvenire senza tunnel e quanto tempo dopo l’avvio si tenta realmente quella attività. Tutto ciò che precede quel momento è una sequenza, ed è la sequenza che verificate. Una nota che dice «la VPN deve essere attiva» non si può testare, mentre «nessun traffico verso l’host dei registri prima che il tunnel sia stabilito» si può.
Poi separate ciò che può fare un telefono personale da ciò che può fare un parco supervisionato, perché le due risposte non sono intercambiabili.
Primo passo: lo stato prima del primo sblocco
Non deducete il comportamento prima dello sblocco da un tunnel visto dopo lo sblocco. Il test onesto è riavviare, lasciare il telefono bloccato e osservare dall’altro capo se si forma un tunnel. Nella maggior parte delle configurazioni personali la risposta sarà no, e non è un difetto; significa solo che la prima attività protetta non va tentata prima dello sblocco del telefono.
Se un requisito dipende davvero dalla copertura prima dello sblocco, portatelo al responsabile della distribuzione e non a un’impostazione del client.
Secondo passo: prontezza della rete e portali captive
L’Always On supervisionato si attiva senza interazione dell’utente e persiste tra i riavvii finché il suo profilo resta installato, e la stabilizzazione segue il momento in cui l’interfaccia ottiene raggiungibilità IP. È quest’ultima frase quella importante: un telefono che non ha ancora ottenuto un indirizzo non ha nulla su cui costruire. Un portale d’albergo non accettato è una rete che non è pronta esattamente in questo senso, e nessuna preferenza VPN memorizzata lo completa per voi.
Quindi la nota di accettazione ha bisogno di una riga per il caso del portale. O il telefono attende, oppure un utente attraversa prima il portale, e quale delle due sia accettabile dipende da chi viaggia. Scrivete la scelta, perché la persona che riavvia alle sette del mattino non la inventerà. Un portale che richiede un numero di camera è anche un caso diverso da uno che accetta solo una casella di controllo.
Terzo passo: autenticazione che richiede ancora una persona
L’attivazione automatica e l’autenticazione automatica sono capacità separate. Un profilo con certificato del dispositivo può completare la seconda senza una persona, mentre un gateway che esige un fattore monouso non può, e nessuna policy lo farà. Determinate quale delle due state distribuendo prima di promettere una sequenza di avvio senza mani.
Poi annotate esplicitamente lo stato intermedio: se l’autenticazione è in sospeso, il traffico viene bloccato, messo in coda o inviato direttamente? La risposta appartiene al piano perché è la finestra in cui una configurazione errata diventa una fuga. Provatelo rendendo il gateway irraggiungibile e osservando cosa fa il telefono, invece di leggere la descrizione che il client fa di sé.
Quarto passo: la prima attività protetta, poi una transizione
Dopo il riavvio pianificato aprite l’attività protetta e confermate che riesce e che ha davvero usato il tunnel. Poi ripetete la stessa attività durante una transizione dal Wi-Fi alla rete mobile, perché quello spostamento rinegozia la rete sottostante ed è lì che un profilo funzionante solo all’avvio comincia a fallire. Registrate tre fatti per ogni esecuzione: se la connessione è salita automaticamente, se avete dovuto autenticarvi e se la risorsa attesa ha risposto.
Se la protezione durante l’intervallo è obbligatoria, usate il metodo di verifica approvato dal responsabile della distribuzione. Un singolo caricamento di pagina riuscito non può dimostrare che nulla sia andato diretto prima.