DNS di OpenVPN sul gateway: dnsmasq e ambito del firewall

I client nel tunnel raggiungono il gateway e il gateway raggiunge il resolver interno, quindi DNS dovrebbe funzionare. Non funziona, perché sono due autorizzazioni diverse e un servizio DNS funzionante è una terza cosa. L'ascoltatore deve esistere su un indirizzo che i client raggiungono, il firewall deve consentire query a quell'indirizzo e al client va detto di usarlo. Aprire il tunnel in entrambe le direzioni risolve i primi due per caso e lascia il terzo incompiuto.

L'ascoltatore è un servizio locale con due direzioni

In ingresso, un client invia una query all'indirizzo del tunnel del gateway sulla porta 53. In uscita, il demone inoltra quella query al suo upstream configurato. Entrambe le metà devono funzionare, e falliscono in modi diversi.

Un timeout segnalato dal client e un timeout visto sul gateway non sono lo stesso guasto.

Vincolate l'indirizzo del tunnel, non ogni indirizzo

Un'istanza dnsmasq dedicata a questo compito richiede un indirizzo di ascolto esplicito, una modalità di binding che tollera la comparsa del tunnel dopo l'avvio e un upstream chiaro. È la versione più piccola che uso:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic vincola i singoli indirizzi e gestisce il caso in cui tun0 compaia più tardi, cosa che conta su un host dove il servizio VPN si riavvia. Elencare loopback mantiene funzionanti gli strumenti locali senza aggiungere un ascoltatore pubblico. no-resolv impedisce al demone di ereditare upstream dalla configurazione del resolver dell'host, e no-hosts impedisce a questa istanza di pubblicare il file hosts del gateway. Nessuna di queste opzioni dà a qualcuno l'autorizzazione a interrogare il servizio.

Controllate se esiste un ascoltatore già presente sulla porta 53 prima di avviare un secondo demone, e usate il proprietario della configurazione della distribuzione invece di un file smarrito nella directory sbagliata.

Consentite l'ingresso DNS, non il transito del tunnel

Le regole del firewall che rendono possibile tutto questo sono regole di ingresso locale limitate all'interfaccia del tunnel, al pool di client, all'indirizzo del gateway e alla porta 53. Due regole, una per protocollo, bastano:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS passa su TCP come su UDP, quindi una regola solo UDP lascia fallire le risposte grandi in un modo che sembra intermittente. Queste non sono ufw route autorizzazioni, e non devono diventare un permesso ampio su tun0. L'ordine conta quanto il contenuto: una regola precedente che scarta tutto l'ingresso da tun0 vince comunque, e aggiungere un permesso sotto uno scarto terminale non crea nulla.

Se il DNS del gateway ora fa parte del progetto, rivedete quella politica precedente di proposito e annotate perché.

La metà upstream è un percorso separato

Le query lasciano il gateway dal suo indirizzo verso il resolver upstream, quindi la rotta del gateway e la politica di uscita verso quel resolver devono consentire lo scambio. È una regola diversa da quella che lascia i client raggiungere l'ascoltatore, e fallisce con un sintomo diverso.

Non aggiungete uscita tunnel senza restrizioni per far funzionare le risposte; le risposte tracciate non ne hanno bisogno.

Inviate l'opzione, poi controllate la consegna

Il server può annunciare il resolver ai client con un'opzione inviata. È un'opzione, non un'istruzione che il sistema operativo deve obbedire:

push "dhcp-option DNS 10.90.0.1"

Un client Linux da riga di comando può aver bisogno dell'integrazione del resolver del suo gestore di connessioni, e un dispositivo gestito può aver bisogno del profilo di gestione aggiornato. Confermate il resolver attivo sul client dopo la connessione invece di presumere che l'invio sia stato applicato. Quando due meccanismi provano a impostare DNS insieme, si ottiene una corsa che si presenta come risoluzione instabile.

L'obiettivo è un solo proprietario della configurazione del resolver del client, e l'invio è quel proprietario di solito solo quando la piattaforma del client è d'accordo.

Testate ciò che avete davvero costruito

Interrogate un nome privato completamente qualificato e un nome esterno consentito direttamente contro l'indirizzo del tunnel, su UDP e TCP. Poi ripetete lungo il percorso di ricerca ordinario dell'applicazione.

Se le query dirette funzionano e l'applicazione fallisce ancora, il guasto è nella consegna e non sul server:

• Il client non ha mai applicato l'opzione inviata.
• Un altro resolver è stato impostato dopo e ha vinto la corsa.
• L'applicazione usa la propria libreria di resolver o una risposta in cache.

Chiudete confermando che una sorgente fuori dal percorso VPN approvato non può usare affatto l'ascoltatore. Una risoluzione riuscita non autorizza l'indirizzo restituito, quindi tenete separate queste due domande.