Always On VPN o VPN On Demand su iPhone: cosa distribuire

Due iPhone possono entrambi dire VPN e comportarsi in modo del tutto diverso. On Demand apre un tunnel quando una regola corrisponde, e l’utente può comunque disattivarlo nelle Impostazioni. Always On gestito mantiene la copertura imposta su un dispositivo supervisionato, anche nei momenti in cui il tunnel non riesce a salire. Scegliete chiedendo cosa deve essere vero quando l’utente non fa nulla, poi provate le transizioni invece dello stato stabile. I passi seguenti seguono l’ordine in cui una distribuzione fallisce davvero.

Passo 1: stabilire cosa il dispositivo può imporre

Always On è una funzione per dispositivi supervisionati. Se il parco non è supervisionato, la discussione finisce prima di iniziare, e nessuna chiave payload trasforma un telefono non supervisionato in uno imposto. Confermate la supervisione dal lato gestione e dal dispositivo, poi confermate chi ha firmato il profilo.

Sul telefono: Impostazioni, poi Generali, poi VPN e gestione dispositivo. La voce del profilo ne indica il proprietario, e un profilo personale installato a mano appare diverso da uno consegnato da un servizio di gestione. Non deducete l’imposizione dal nome del profilo o da un’etichetta commerciale del fornitore; l’etichetta non è la politica della piattaforma.

Annotate tre fatti prima di toccare la configurazione: supervisionato o no, profilo gestito o personale, e quale client trasporta il tunnel. Ogni passo successivo dipende da questi tre, e trasferire il comportamento da un telefono personale a un profilo gestito è il modo in cui una distribuzione viene approvata su una base sbagliata.

Passo 2: leggete le regole on-demand, non il nome della funzione

On Demand è un elenco di regole valutate in ordine. Ogni regola indica un’azione e le condizioni che la selezionano, e le condizioni sono la parte interessante: tipo di interfaccia, SSID Wi-Fi, suffisso di dominio DNS o un URL di sonda. Un insieme di regole che non corrisponde mai è una funzione che non si connette mai.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Leggete l’intero array e fate due domande per regola: questa condizione può mai essere vera su questo parco, e cosa succede quando nessuna regola corrisponde? Le reti aziendali rinominano gli access point, uniscono gli SSID e cambiano i suffissi DNS, e ciascuna di queste modifiche stacca silenziosamente una regola dalla realtà.

La condizione del suffisso DNS è quella più spesso sbagliata sul campo, perché il suffisso che un telefono riporta su una rete ospiti non è quello servito dal resolver aziendale. Verificate il nome che il dispositivo risolve davvero prima di fidarvi della regola.

Passo 3: provate le transizioni, non la connessione statica

Un tunnel che è su mentre lo guardate dimostra molto poco. Eseguite ogni transizione di proposito e annotate cosa fa il dispositivo, usando la stessa risorsa privata ogni volta perché i risultati siano confrontabili:

• Entrate in una rete dove una regola dovrebbe corrispondere, poi richiedete la risorsa privata e confermate che si carica.
• Passate alla rete cellulare con l’app in background, poi portatela in primo piano e ripetete la richiesta.
• Collegatevi a un Wi-Fi con portale captive e vedete se il portale è raggiungibile o se l’imposizione lo blocca prima che possiate autenticarvi.
• Disattivate il tunnel a mano su un dispositivo supervisionato e controllate se torna da solo, e quanto in fretta.

Eseguite lo stesso elenco su un dispositivo non supervisionato se ne avete uno. La differenza tra i due risultati è il comportamento reale della distribuzione, ed è la parte che uno screenshot di un tunnel connesso non mostra mai.

Passo 4: conoscere le due forme di guasto

La copertura imposta fallisce bloccando. Quando il tunnel non si stabilisce, il dispositivo perde l’accesso internet ordinario insieme alle risorse private, e l’utente vive un telefono online ma incapace di navigare. Riconnessione e blocco sono osservazioni separate, quindi registrate entrambe invece di trattare l’assenza di internet come un solo sintomo.

On Demand fallisce non attivandosi. La regola non corrisponde, nessun tunnel appare, e la risorsa privata semplicemente scade. È facile diagnosticarlo male come problema del server, perché il client si comporta esattamente come configurato.

Un portale captive sta fra i due: ha bisogno di connettività prima che il tunnel esista, quindi una politica che blocca tutto finché il tunnel non sale richiede un percorso documentato attraverso il portale. Decidetelo nel progetto, non al banco di assistenza.

Passo 5: verificate, poi provate il rollback

La verifica va sul percorso reale con traffico innocuo: richiedete una risorsa privata che non deve essere pubblica, confermate quale indirizzo il dispositivo presenta verso l’esterno, e ripetete dopo un riavvio per aver visto la sequenza di avvio e non solo lo stato caldo.

Poi provate la rimozione su un dispositivo di test prima di averne bisogno in produzione. Rimuovere il profilo riporta il dispositivo allo stato precedente, e sapere quanto dura e cosa vede l’utente fa parte del runbook. La guida alla sicurezza VPN di Apple è il riferimento per ciò che la piattaforma documenta su queste politiche, e vale la pena leggerla prima di scrivere una configurazione che afferma più della piattaforma.

Tenete i tre fatti del primo passo accanto all’insieme di regole e ai risultati dei test. Quando la persona successiva chiederà perché un telefono si connette su una rete e non su un’altra, quelle note rispondono in un minuto invece di ricostruire.