DNS del VPN su iPhone: chi possiede l'impostazione decide dove si applica

Digitare un indirizzo di resolver privato nelle impostazioni Wi-Fi di un iPhone e funzionerà finché il telefono non lascia quella rete, cioè esattamente quando un VPN dovrebbe subentrare. È la prima trappola del DNS mobile: il punto in cui si è inserita l'impostazione ne definisce l'ambito, e l'ambito è più ristretto di quanto la maggior parte delle persone supponga. Prima di modificare qualcosa, rispondere a tre domande sul deployment, perché le risposte decidono quale controllo si deve toccare. Trattare la sequenza come una revisione di progettazione e non come una caccia alle impostazioni.

Tre domande prima di digitare un indirizzo di resolver

Primo, quali nomi richiedono davvero un trattamento speciale? Una zona privata come corp.example è uno spazio dei nomi, non un singolo host, e la risposta dovrebbe essere un dominio e non un singolo record. Secondo, quale resolver è autoritativo per essa, e chi possiede quel servizio? Terzo, quale percorso rende quel resolver raggiungibile dal telefono: il tunnel, una rete Wi-Fi instradata o qualcosa di completamente diverso?

Se uno di questi tre non ha un proprietario, fermarsi. Una modifica DNS fatta senza uno spazio dei nomi, una fonte autoritativa e un percorso raggiungibile è un'ipotesi che fallirà in modo diverso sulla rete cellulare rispetto all'ufficio.

Una voce DNS Wi-Fi appartiene a quella rete Wi-Fi

La configurazione manuale del DNS su iOS è memorizzata per rete. Si applica finché il telefono è associato a quel SSID e smette di applicarsi quando non lo è, il che significa che non può governare il traffico cellulare né descrivere cosa fa un client VPN. Modificarla per riparare un'app che fallisce sulla rete cellulare significa cambiare un'impostazione che il percorso che fallisce non legge mai.

Ciò non rende inutile il DNS per rete. Per un laboratorio domestico o un singolo SSID d'ufficio, è il modo più semplice per raggiungere un resolver interno, ed è onesto sul suo confine.

Il meccanismo DNS del VPN segue il protocollo e il client

Un provider di tunnel di pacchetti su iOS può configurare il DNS tramite l'API delle impostazioni DNS di Apple, che espone indirizzi di resolver e corrispondenza dei domini al tunnel che possiede la connessione. Una configurazione IKEv2 nativa può ricevere il DNS tramite il payload di configurazione IKE quando il gateway lo spinge, ma se un dato client applichi ciò che riceve è un dettaglio implementativo che va verificato. Un client basato su app può implementare interamente il proprio percorso di risoluzione.

Sono punti di integrazione diversi, e il risultato di uno di essi non diventa una regola per tutti gli iPhone. Il meccanismo supportato è ciò che il profilo o il provider documenta per il protocollo in uso.

Decidere per proprietà, non per comodità

Se il dispositivo è gestito, il proprietario del profilo dovrebbe fornire l'impostazione DNS insieme alla configurazione VPN, così che una nuova registrazione la ripristini senza che l'utente debba ricordare nulla. Se un'app del provider possiede il tunnel, la sua schermata delle impostazioni è il posto da guardare, e la sua documentazione è l'autorità su ciò che può separare. Se il telefono è personale e l'esigenza è un nome interno su una rete, l'impostazione per rete è proporzionata.

La regola decisionale è breve: l'impostazione appartiene a dove viene effettuato il provisioning della connessione. Ovunque altro, è un'eccezione locale che il prossimo cambio di rete cancellerà.

Verificare sui percorsi che il telefono usa davvero

Provare una richiesta nuova dall'app che ha bisogno del nome privato, sul Wi-Fi in ufficio, sulla rete cellulare e durante una transizione tra le due. Un'app con una propria integrazione del resolver può seguire un percorso diverso da quello del sistema, quindi provare l'applicazione reale e non una scheda del browser che funziona per caso.

Quando il nome privato fallisce, conservare l'errore esatto e lo stato del profilo. Un resolver pubblico che risponde che il nome non esiste dà una risposta corretta alla domanda sbagliata, e aggiungerlo accanto al resolver aziendale non è una progettazione dello spazio dei nomi.

Infine, conservare la policy verificata insieme alla fonte del provisioning. La prossima riconnessione o registrazione dovrebbe ripristinare lo stesso servizio dei nomi perché il profilo lo ha detto, non perché qualcuno ha ricordato una modifica fatta su un hotspot due anni fa.