Consentire il DNS solo tramite il vostro resolver VPN: un percorso passo dopo passo

Seguite una sola risoluzione di nome dal momento in cui la digitate. Il browser interroga il sistema operativo, il sistema operativo interroga il resolver scelto dalla sua politica, e la query esce dal dispositivo attraverso un’interfaccia con un trasporto qualsiasi. Il vostro progetto VPN afferma che la risposta deve arrivare da un resolver preciso per un percorso preciso. Il divario tra queste due affermazioni è ciò che configurate e poi fate rispettare.

Passo 1: nominate il resolver e il percorso

Annotate tre cose prima di toccare un firewall: l’indirizzo del resolver, il protocollo e la porta che vi aspettate, e l’interfaccia da cui la query deve uscire. Senza quell’elenco una regola è una congettura sul traffico, non l’applicazione di una decisione. Una VPN può trasportare i dati delle applicazioni mentre il DNS segue un assetto separato, e questo di per sé non è un errore. È ciò che accade quando nessuno ha detto al client qualcosa di diverso.

Nominare il percorso in modo esplicito è la differenza tra un progetto e un incidente. Vi dà anche qualcosa da verificare più avanti, perché ogni osservazione può essere confrontata con un’attesa scritta. Tenete quell’elenco nel ticket di modifica e non nella testa di qualcuno.

Passo 2: mettete la politica dove vive davvero

La scelta del resolver spetta al client: configurazione di rete del sistema operativo, impostazioni del client VPN stesso o politica del browser gestita. Mettetela prima lì, con il meccanismo che la piattaforma supporta, perché un firewall non può obbligare un client a scegliere un resolver di cui non ha mai sentito parlare. Su un client con tunnel diviso, dite esplicitamente quali domini vanno al resolver interno. In una flotta gestita la politica del browser è spesso l’unica leva per DoH, perché il browser può scegliere il proprio resolver cifrato indipendentemente dall’impostazione di sistema.

Saltate questo passaggio e andate dritti al firewall: ottenete una regola che permette il resolver giusto e un client che non lo usa mai. La regola sembra corretta e i log del resolver restano vuoti, un binomio sconcertante da diagnosticare. Configurate prima la scelta, poi imponetela.

Passo 3: imponete il percorso in modo stretto

Aggiungete ora il permesso di rete per il percorso consentito: l’indirizzo del resolver, il protocollo e la porta, e l’interfaccia da cui deve uscire. Tenete la regola limitata a quel resolver invece di consentire tutto il DNS in uscita. I tre percorsi sotto sono quelli che un client moderno può imboccare, e solo il primo è coperto da una regola sulla porta 53.

Bloccare DoH e DoT è legittimo; dare per scontato che una regola sulla porta 53 li abbia già bloccati non lo è. Un browser con DoH risolve i nomi per un percorso che la vostra regola non ha mai descritto, e un’applicazione che porta il proprio resolver fa lo stesso. Scrivete ogni percorso che intendete consentire e ognuno che intendete rifiutare. Una regola che non nomina un percorso non ha deciso nulla su di esso.

Passo 4: seguite i nomi privati e pubblici

Il DNS diviso manda di proposito solo spazi di nomi privati a un resolver interno mentre i nomi pubblici vanno altrove, quindi più di un resolver nel progetto non è una fuga. La fuga è una query che doveva andare al vostro resolver e arriva altrove, oppure un percorso previsto irraggiungibile che fa ripiegare il client in silenzio. Sono questi due casi da cercare. Seguite un nome interno e un nome pubblico con la politica prevista e annotate quale resolver ha risposto a ciascuno.

Un sito di prova che riporta il vostro resolver è un indizio, non una prova, perché vede solo le query che lo hanno raggiunto. Catturate la query lato client quando dovete sapere quale percorso ha davvero preso, poi confrontate le due osservazioni. Quando non concordano, avete trovato un ripiego che nessuno ha documentato.

Se l’indirizzo del resolver è corretto ma irraggiungibile, il problema è nell’instradamento o nel filtraggio e non nella politica. Tracciate la query verso quell’indirizzo e confermate che la risposta torni sull’interfaccia attesa prima di cambiare qualsiasi impostazione del resolver.

Passo 5: tenete una via di ritorno

Prima di irrigidire l’accesso DNS sul gateway, confermate un metodo di recupero che non dipenda dalla risoluzione dei nomi. Un resolver rotto rende ogni strumento di riparazione più difficile da raggiungere, compresi quelli che usereste per annullare la modifica. Tenete una console locale o una via fuori banda aperta finché la nuova politica non è dimostrata. Rimuovetela solo dopo che la politica ha superato una riconnessione.

Dopo una riconnessione o un aggiornamento della politica del browser, ispezionate di nuovo lo stato effettivo, perché entrambi possono cambiare il resolver senza cambiare la vostra regola. Il requisito è un destinatario noto e un percorso protetto per le query, non un’etichetta di resolver rassicurante su un’unica schermata. La specifica RFC 8484 di DNS over HTTPS è il riferimento per il percorso cifrato che la vostra regola di porta non vede.