La VPN su Android risolve il nome host completo ma non quello breve

Digitatefilesin un emulatore di terminale e non torna nulla; digitatefiles.corp.examplee lo stesso server risponde subito. Nulla è cambiato nelle credenziali della VPN, e il server DNS privato non si è mai rotto. Su Android l'etichetta breve e il nome completo seguono percorsi diversi attraverso il resolver, e uno di questi percorsi dipende da un'impostazione che il proprietario del tunnel deve fornire. La decisione davanti a voi non è quale server DNS cambiare, ma chi controlla la rete che l'applicazione usa davvero.

Un dominio di ricerca non è un indirizzo. È un elenco di suffissi che il resolver aggiunge a un'etichetta nuda prima di arrendersi.

Un suffisso di ricerca e un server DNS sono campi separati

L'indirizzo del resolver dice ad Android dove chiedere. Il suffisso di ricerca gli dice cosa chiedere quando fornite solo l'etichetta più a sinistra. Entrambi vivono sullo stesso oggetto di rete, e ciascuno può mancare da solo.

È proprio questa indipendenza a spiegare perché il nome host completo funziona. Un nome completamente qualificato non ha bisogno di suffisso, perché è già la stringa che va al server.

Android espone questa separazione tramiteLinkProperties. L'elenco dei server DNS e l'elenco di ricerca dei domini stanno sullo stesso oggetto, e il secondo è spesso vuoto anche quando il primo è pieno. Una rete con un resolver ma senza dominio è una rete in cui il suffisso non è mai stato applicato, non un server che ha rifiutato il nome breve.

Leggete la rete effettiva prima di cambiare qualcosa

Wi-Fi, rete mobile e interfaccia VPN sono tre reti separate, e il tunnel diventa la predefinita appena sale. Il suffisso che funzionava sul Wi-Fi dell'ufficio non è quindi automaticamente quello in vigore mentre il tunnel è attivo. Ispezionate la rete su cui l'applicazione è realmente selezionata, non quella che avete configurato la settimana scorsa.

Una shell di terminale sul dispositivo è un cattivo testimone qui, perché il suoresolv.confriflette una sola visione del resolver e non quella di ogni applicazione.

Le barre degli indirizzi dei browser aggiungono un altro strato: una parola nuda può essere trattata come query di ricerca, o risolta tramitela politica di DNS cifrato del browser stesso, quindi una pagina che si carica in Chrome non dimostra nulla sulle risoluzioni di sistema. Provate con qualcosa che usi il resolver della piattaforma e stampi cosa è tornato. Poi eseguite la forma breve e quella completa nella stessa sessione, sulla stessa rete, e annotate quale ha prodotto una risposta.

Se sviluppate l'applicazione VPN, collegate il suffisso nel builder

Quando la vostra applicazione stabilisce l'interfaccia tramiteVpnService,addSearchDomainè l'input supportato per questo. Accetta una stringa di dominio comecorp.example, e non è un modo alternativo di passare un indirizzo di server.

La chiamata lega il suffisso alla rete che state costruendo, quindi non c'è alcuna impostazione globale da ribaltare dopo. Se l'applicazione smonta l'interfaccia e la ricostruisce alla riconnessione, il nuovo builder deve aggiungere di nuovo il suffisso, altrimenti la rete sostitutiva sale senza.

È qui che molte importazioni di profili desktop perdono il campo. L'esportatore scrive il dominio nel proprio modello, il frontend Android mappa solo le opzioni che conosce, e l'interfaccia risultante sembra corretta sotto ogni altro aspetto. Un profilo che funziona su un portatile e fallisce su un telefono è di solito una lacuna di mappatura, non un problema di protocollo.

Se consumate soltanto la VPN, non spetta a voi impostarlo

Non esiste alcuna modifica lato client che aggiunga un suffisso, né alcuna proprietà globale che possiate cambiare per simularne uno. Il valore lo fornisce chi possiede il tunnel: nel profilo del client gestito, nella sua mappatura per piattaforma, o tramite ciò che il server invia. Dite su quale piattaforma siete e quale nome fallisce, perché i frontend desktop e mobile divergono proprio su questo campo.

Importare di nuovo un profilo desktop non dimostra comunque nulla sulla mappatura mobile.

Tre condizioni decidono se avete un difetto o un limite atteso. Prima: l'organizzazione tratta l'etichetta breve come un nome supportato, o è una comodità che ha sempre funzionato solo sul Wi-Fi dell'ufficio? Seconda: la risoluzione che fallisce arriva da un browser, che può aggirare del tutto il resolver di sistema? Terza: il nome breve deve essere raggiungibile attraverso il tunnel, o solo dalla LAN? Se l'ultima risposta è solo LAN, aggiungere un suffisso creerebbe un nome che si risolve fuori dall'ufficio e poi non viene instradato.

Quando il suffisso è presente e i nomi brevi falliscono ancora

Se l'elenco di ricerca dei domini mostra giàcorp.example, smettete di dare la colpa al suffisso. Verificate se il resolver restituisce una risposta per il nome esteso, perché un suffisso cambia solo la domanda che fate. Non rende mai il server autorevole per una zona che non ospita.

Poi verificate la rotta. Un indirizzo che si risolve ma non è trasportato dal tunnel fallisce al momento della connessione, il che appare identico a una risoluzione fallita in un browser che si arrende in silenzio.

I certificati meritano una menzione a parte. La validazione HTTPS usa il nome host che avete realmente digitato, quindi un nome breve che si espande correttamente presenta comunquefilesnella stretta di mano. Un certificato emesso perfiles.corp.examplenon sarà valido per esso, e quell'errore è un comportamento corretto, non un sintomo del problema DNS con cui avete iniziato.

Cosa fare adesso

Confermate la separazione prima di toccare qualsiasi cosa: il nome completo si risolve, quello breve no, stessa applicazione, stessa sessione. Poi trovate la rete selezionata e leggete il suo elenco di ricerca dei domini accanto a quello dei resolver. Quello dei due che è vuoto vi dice chi deve agire: voi, se l'applicazione è vostra; l'operatore del tunnel, se non lo è.

Infine, preferite il nome host di servizio completo nei segnalibri e nella configurazione del client ovunque conti la portabilità. Sopravvive a un cambio di rete, non dipende da una mappatura che il frontend mobile potrebbe non implementare, e corrisponde al nome per cui è stato emesso un certificato.