VPN per dominio su iPhone: decidere dove avviene il rifiuto
NeverConnect impedisce l'avvio della VPN; non blocca un sito web. Decidere se il rifiuto appartiene al confine del servizio o a una policy gestita.
Due requisiti vengono scritti come un'unica frase e poi implementati in luoghi completamente diversi. «Questo sito deve essere raggiungibile solo tramite la VPN» è un'affermazione sull'ammissione, e la sua casa naturale è la rete davanti al servizio. «Questo iPhone non deve mai contattare direttamente quel dominio» è un'affermazione sul dispositivo, e solo una policy client gestita può esprimerla. Decidere quale si ha davvero prima di aprire un editor di profili.
Due requisiti che suonano identici
Prendere l'host illustrativo records.corp.example. Nel caso dell'ammissione lo si pubblica solo verso indirizzi dietro la VPN, quindi un tentativo diretto da un telefono in rete cellulare fallisce a livello di rete, mentre la stessa richiesta attraverso il tunnel riesce e richiede comunque un vero accesso all'account. Nel caso del dispositivo il telefono può raggiungere internet pubblico, quindi l'host si risolve e risponde a chiunque, e l'unico posto per fermare il tentativo è il dispositivo. Il servizio non può applicare una regola a una richiesta che non gli arriva mai.
Una lettura errata del requisito si manifesta come un'implementazione precisa. Il record resta pubblico, l'operatore crede che la VPN sia obbligatoria, e un audit di un tentativo cellulare mostra che la richiesta non è mai entrata nel tunnel. Niente nei log sembra rotto, perché niente è stato bloccato.
Leggere alla lettera le azioni di valutazione
Il meccanismo su richiesta ha due livelli distinti di azioni, e confonderli produce la maggior parte della confusione qui. L'azione della regola esterna decide cosa accade al tunnel quando la regola corrisponde, e l'azione di valutazione della connessione decide cosa accade a una corrispondenza di nome host dentro una regola di valutazione. Il riferimento Never Connect di Apple descrive solo il secondo livello.
| Layer | Action | What it controls |
|---|---|---|
| Outer rule | connect | Bring the tunnel up when the rule matches |
| Outer rule | disconnect | Tear the tunnel down when the rule matches |
| Outer rule | evaluateConnection | Run a hostname evaluation instead of acting directly |
| Outer rule | ignore | Leave the current tunnel state alone |
| Connection evaluation | connectIfNeeded | Start the tunnel when the hostname cannot be resolved |
| Connection evaluation | neverConnect | Do not start the tunnel for that match |
neverConnect è il valore più spesso letto male, perché il nome suggerisce un blocco. Governa l'avvio del tunnel per un nome host corrispondente, non il permesso del telefono di raggiungere un nome, quindi una voce Never Connect non è un blocco di dominio. Etichettarla così in un documento di progettazione è il modo in cui un'implementazione viene approvata con un confine di applicazione che non ha.
Quando il servizio è tuo, applica al confine
Limitare l'ammissione significa pubblicare il nome solo dove il percorso VPN può raggiungerlo, poi verificare che il percorso previsto funzioni e un altro percorso no. Coprire ogni record pubblicato, entrambe le famiglie di indirizzi se le pubblichi, e qualsiasi nome intermedio o alternativo usato dall'app. Un vecchio CNAME che punta ancora a un bilanciatore di carico pubblico mantiene vivo il percorso diretto, per quanto ordinato sia il record principale.
Questo protegge il servizio anziché il dispositivo. Non impedisce al telefono di inviare una query DNS, né all'app di provare. Se quei tentativi sono accettabili, l'applicazione al confine è la scelta più economica e duratura, perché vale per ogni client e non solo per quelli configurati. Sopravvive anche a un telefono che non è mai stato registrato.
Quando il telefono non deve nemmeno provare, serve una policy gestita
Fermare il tentativo richiede una policy di applicazione supportata che copra l'app o le destinazioni prima della connessione, durante un guasto del tunnel e dopo un cambio di rete. Chiedere al fornitore VPN o di gestione dei dispositivi di nominare quella policy, dire se richiede una gestione organizzativa e descrivere cos'altro influisce. Un tunnel per app più una regola su richiesta non sono la stessa cosa, e nemmeno una scorciatoia dalla schermata iniziale a una connessione.
Testare il caso di guasto disabilitando il tunnel e osservando se la richiesta esce. Se esce, il confine documentato non è quello implementato.
Decidere con tre domande
Primo, controlli il servizio o solo il telefono? Secondo, il dispositivo può usare legittimamente internet pubblico per tutto il resto? Terzo, il telefono è gestito, e da chi? Possedere il servizio più una flotta gestita significa che entrambi i livelli sono disponibili, mentre possedere solo il telefono rende la policy client l'unica opzione e questa deve essere supportata.
Rispondere a queste tre prima di toccare un profilo. Allora la configurazione smette di essere una supposizione su cosa significhi una casella chiamata Never.