Perché il Private DNS del telefono rompe la risoluzione dei nomi della VPN
Un resolver rigoroso sul telefono può sovrascrivere il servizio dei nomi del tunnel. Decidete in base ai nomi che vi servono, poi verificate quale applicazione chiede, e con quale criterio.
Le applicazioni non riescono a risolvere un nome mentre il tunnel resta connesso e ogni altro indicatore sembra sano. Sul telefono, la causa abituale è un resolver scelto dal dispositivo e non dal profilo VPN. Due impostazioni possono ciascuna rivendicare autorità sulla stessa richiesta. Capire quale vince, e se può persino rispondere alla domanda, è più rapido che toccare il tunnel.
Due impostazioni decidono lo stesso nome
L’impostazione Private DNS del telefono sceglie un resolver per il dispositivo, con modalità che vanno dalla selezione automatica a un nome host specifico. Un profilo VPN può imporre il proprio resolver nello stesso momento, e i due si configurano su schermate diverse e da proprietari diversi. Nessuno dei due sovrascrive necessariamente l’altro per ogni applicazione. Per questo un tunnel funzionante e una richiesta che fallisce convivono senza contraddizione.
Il browser può aggiungere un terzo strato, perché il DNS sicuro al suo interno può scegliere un proprio fornitore. L’applicazione che ha prodotto l’errore è l’unica guida affidabile su quale dei tre ha risposto. Anche il resolver deve poter rispondere. Un nome solo aziendale non è nei dati di un resolver pubblico, quindi la richiesta fallisce per il contenuto e non per la connettività.
Scegliete la modalità in base ai nomi che vi servono
Se il dispositivo deve risolvere nomi interni, il resolver deve essere quello che detiene quelle zone, il che di solito significa il resolver del tunnel o un assetto DNS diviso documentato dall’organizzazione. Se contano solo i nomi pubblici, un resolver cifrato rigoroso è una scelta difendibile che elimina anche le richieste in chiaro. La decisione deriva dai nomi, non da una preferenza sulla cifratura.
Anche il comportamento in caso di guasto dipende dalla modalità. Una scelta rigorosa che non raggiunge il proprio resolver produce un guasto per ogni nome, mentre una modalità con ripiego consentito può tenere funzionanti i nomi pubblici e rotti quelli interni. Questa differenza vi dice in quale modalità siete prima di aprire una schermata di impostazioni. Su un dispositivo gestito decide il criterio approvato e l’utente non può aggirarlo in sicurezza. Su un’installazione personale basta un confronto documentato per identificare il conflitto, e l’impostazione di privacy desiderata andrebbe ripristinata dopo invece di lasciarla disattivata.
Verificate quale applicazione chiede
Riproducete il guasto nell’applicazione che lo ha segnalato, e annotate se l’errore è di nome o di connessione. Un errore di nome in un’applicazione e una pagina riuscita in un’altra sono la firma di due resolver, non di un tunnel rotto.
adb shell settings get global private_dns_mode
adb shell settings get global private_dns_specifier
adb shell dumpsys connectivity | grep -i -m 5 dnsQuei comandi leggono la configurazione attuale del dispositivo, e le build dei produttori possono rinominare o limitare i valori sottostanti, quindi trattate l’output come un indizio e non come una specifica. La documentazione Android su Private DNS descrive le modalità e la forma del nome host che un dispositivo si aspetta.
Confrontate quella risposta con il resolver che il profilo VPN impone. Se non concordano, avete trovato il conflitto, e la domanda che resta è quale l’organizzazione voglia vincere.
Ripristinate l’impostazione voluta dopo un confronto
Cambiate un’impostazione, riprovate i due nomi, e rimettete l’impostazione com’era. Un dispositivo lasciato in modalità permissiva risolve i nomi interni e invia in silenzio ogni richiesta pubblica a chi risponde per primo, il che è un cambiamento di privacy che nessuno ha registrato.
Scrivete il risultato come regola: i nomi interni si risolvono con questo resolver, quelli pubblici con quello, e il browser segue o non segue il dispositivo. Una regola che nomina il resolver è verificabile, mentre una nota che dice che la VPN è stata riparata non lo è. Poi verificate se qualcos’altro sul dispositivo dipende dal resolver che avete cambiato. I controlli degli aggiornamenti, il rilevamento dei portali captive e i client di posta fanno le proprie richieste, e falliscono in modi che gli utenti segnalano come problemi non correlati.