DNS WireGuard su iPhone: il dominio è solo un suffisso di ricerca

Scrivete una riga con un indirizzo di resolver e un dominio aziendale, aspettandovi che solo i nomi di quel dominio usino il resolver del tunnel. Sul client Apple, ora tutti i nomi vanno lì, e anche i nomi brevi del dominio vengono risolti. La riga fa due cose separate, e solo una riguarda quali query gestisce il tunnel. L’altra è una comodità di digitazione promossa a politica da una lettura compiacente.

In cosa viene suddivisa la riga DNS

Il client legge la voce come un elenco e classifica ogni elemento in base alla forma. Tutto ciò che sembra un indirizzo diventa un server DNS; tutto ciò che sembra un dominio diventa un suffisso di ricerca. Entrambi finiscono nelle impostazioni del tunnel, ma in campi diversi. Una riga illustrativa per un tunnel che porta un resolver privato e un dominio interno appare così.

DNS = 10.24.8.53, lab.internal.example

L’indirizzo fornisce il resolver. Il dominio fornisce un suffisso che consente al client di digitare un nome breve e al sistema di aggiungere il resto prima di chiedere. Nessuno dei due dice nulla sul limitare il resolver a quel dominio, ed è proprio la parte che le persone si aspettano e non ottengono. Solo un campo della piattaforma può esprimere questa restrizione, e non è questo.

Due campi Apple, due compiti diversi

Apple espone la distinzione nel suo oggetto delle impostazioni DNS. L’elenco dei domini di ricerca è documentato come l’elenco usato per qualificare i nomi host a etichetta singola: digitate un nome host nudo e il sistema può aggiungere ogni suffisso a turno. È una regola di completamento, non una regola di instradamento. Niente in quell’elenco decide quale server viene interrogato.

L’elenco dei domini di corrispondenza è una proprietà diversa. Decide quali spazi dei nomi usano questo insieme di impostazioni DNS, e una voce vuota significa il dominio predefinito anziché un suffisso specifico. generatore delle impostazioni del tunnel di pacchetti nel client Apple segue quel modello. Mette i suffissi di ricerca analizzati nell’elenco di ricerca, e quando sono presenti server imposta l’elenco di corrispondenza sulla stringa vuota. Il risultato è un resolver del tunnel che risponde a tutto ciò che il sistema gli invia, più un suffisso che aiuta con i nomi brevi.

Quindi un dominio su quella riga non è un selettore di spazio dei nomi. Aggiungerne un altro non restringe quali query usa il tunnel, e rimuoverlo non le amplia. L’unica cosa che cambia è quanti nomi brevi vengono completati.

Perché ogni nome raggiunge comunque il resolver del tunnel

Con la voce di corrispondenza vuota, il tunnel è un resolver candidato per i nomi ordinari, non solo per il dominio aziendale. In una configurazione a tunnel completo questo di solito conta poco, perché tutto il traffico è comunque nel tunnel. In un tunnel diviso conta molto. I nomi pubblici possono ora essere risolti da un resolver che detiene solo una zona privata, e un errore sembra un VPN rotto quando in realtà è un resolver che risponde solo a una parte dello spazio dei nomi. Il tunnel va bene, le query escono, e le risposte tornano vuote.

Sono disponibili due riparazioni e sono decisioni diverse. Rendete il resolver del tunnel un resolver completo che inoltra i nomi pubblici lungo il percorso approvato, oppure smettete di inviargli nomi pubblici modificando la configurazione del client invece dell’elenco dei domini. La prima mantiene ogni query sul tunnel e si fida dell’upstream. La seconda mantiene alcune query in locale e accetta che i nomi privati possano smettere di risolversi mentre il tunnel è inattivo.

Di cosa avrebbe davvero bisogno un DNS diviso

Una politica di resolver limitata a uno spazio dei nomi richiede un client che vi permetta di esprimerla: fate corrispondere i domini sulle piattaforme Apple, o un’impostazione equivalente nel prodotto che usate. Un campo di configurazione che accetta solo server e suffissi non può esprimerla, per quanto sia punteggiato bene. Un profilo può portare la politica perché descrive una configurazione gestita e non un suggerimento al momento della connessione. Può nominare il dominio, i server e ciò che dovrebbe accadere quando quel dominio non è raggiungibile. Questa è la differenza tra un’impostazione e un contratto.

Sui dispositivi Apple gestiti questo viene di solito fornito tramite un profilo di configurazione che porta le impostazioni DNS specifiche del dominio. È un meccanismo diverso dal file di configurazione di WireGuard, e i due possono coesistere solo se il client rispetta il profilo. Controllate come il vostro client chiama davvero il campo prima di supporre che i due prodotti si comportino allo stesso modo. Uno script con wg-quick su un Mac e l’app WireGuard su un iPhone leggono righe simili e le installano attraverso livelli diversi.

Leggete le impostazioni installate, non il file

Su un Mac potete ispezionare ciò a cui è arrivato il sistema, il che è più informativo che rileggere il file che avete scritto. L’elenco dei resolver mostra quali server sono configurati per quali domini, e le query con ambito mostrano quale ha vinto. Un client che rovina la riga lo mostra qui invece che nel file che avete scritto. Su iOS non esiste una riga di comando equivalente, quindi la prova lì è un risultato: un nome privato che si risolve attraverso il tunnel, e un nome pubblico la cui risposta rivela quale resolver ha risposto.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Questi due comandi stampano la configurazione attuale del resolver e i server DNS del servizio attivo. Se il resolver del tunnel appare come resolver predefinito senza restrizione di dominio, la configurazione fa esattamente ciò che il client ha chiesto. Correggetelo cambiando il meccanismo, non aggiungendo un secondo suffisso e sperando che il comportamento cambi.