DNS trasparente con il bridge NAT: il MikroTik invisibile che risponde a tutti

A cosa serve?

Arrivi da un cliente: il router lo gestisce l’operatore, il DHCP pure, e tu non puoi toccare niente. Però ti chiedono di bloccare qualche sito, o di far risolvere i nomi interni, o semplicemente di vedere chi chiede cosa. E metà degli apparati, telecamere e smart TV in testa, il DNS non lo chiede nemmeno al router: ha 8.8.8.8 scritto dentro.

La soluzione è un MikroTik messo in mezzo come un pezzo di cavo, in bridge fra la rete del cliente e il suo router. Per tutti è invisibile: stessi indirizzi, stesso gateway, stesso DHCP. Ma ogni richiesta DNS che lo attraversa, verso qualunque server, la intercetta e risponde lui.

Il trucco sta in due regole: una nel bridge NAT, che porta la richiesta “su” al router, e una nel NAT normale, che la consegna al DNS del router. Servono tutte e due, e in laboratorio ho provato cosa succede quando ne manca una.

Passo 1: come metto il MikroTik in bridge?

Un bridge con due porte: ether1 verso il router del cliente, ether2 verso la rete (lo switch, gli apparati).

/interface bridge add name=br-trasp
/interface bridge port
add bridge=br-trasp interface=ether1
add bridge=br-trasp interface=ether2
/ip dhcp-client add interface=br-trasp

Il client DHCP sul bridge serve al MikroTik stesso: prende un indirizzo dalla rete del cliente, il gateway e il DNS del router dell’operatore. Così ha internet per risolvere i nomi che non conosce. Ai PC non cambia niente: continuano a prendere l’indirizzo dal router di prima.

⚠️ Attenzione: se ti colleghi al MikroTik da ether1 o ether2, metterle nel bridge ti stacca per qualche secondo. Prepara tutto da un’altra porta, o da WinBox via MAC.

Passo 2: come accendo il DNS del router?

/ip dns set allow-remote-requests=yes

Ora il MikroTik risponde alle richieste DNS che gli arrivano. Se usi il firewall dell’Hardening di base di un router MikroTik, aggiungi il bridge alla lista LAN, altrimenti le richieste vengono scartate in input:

/interface list member add list=LAN interface=br-trasp

Passo 3: perché non basta il NAT normale?

Il primo istinto è la solita regola di redirect:

/ip firewall nat
add chain=dstnat protocol=udp dst-port=53 action=redirect to-ports=53
add chain=dstnat protocol=tcp dst-port=53 action=redirect to-ports=53

Mettila, ci serve. Ma da sola non fa niente: in laboratorio i suoi contatori sono rimasti a zero. Il traffico che attraversa un bridge non sale al livello IP, quindi il firewall IP non lo vede proprio: il bridge è il pezzo di cavo, e il cavo non guarda dentro i pacchetti.

Passo 4: come porto il DNS al router con il bridge NAT?

Il bridge NAT lavora dentro il bridge, sui frame. L’azione redirect fa una cosa sola: invece di far passare il frame da una porta all’altra, lo consegna al router stesso.

/interface bridge nat
add chain=dstnat in-interface=ether2 mac-protocol=ip ip-protocol=udp dst-port=53 action=redirect
add chain=dstnat in-interface=ether2 mac-protocol=ip ip-protocol=tcp dst-port=53 action=redirect

• in-interface=ether2: solo le richieste che arrivano dalla rete del cliente; il traffico dal lato del router dell’operatore passa senza intoppi;
• mac-protocol=ip serve a poter usare ip-protocol e dst-port;
• UDP e TCP: le risposte DNS grandi viaggiano in TCP.

Ora la richiesta arriva al router, il NAT del passo 3 la vede e la gira al DNS del MikroTik. Le due regole fanno una staffetta: il bridge NAT porta il pacchetto al router, il NAT IP lo consegna al DNS. Le azioni del bridge NAT sono elencate nel manuale MikroTik: Bridging and Switching.

E se togli la regola del passo 3? In laboratorio la richiesta arriva al router, ma è indirizzata a 8.8.8.8: il router la inoltra a Google, come farebbe con qualunque altro pacchetto, e risponde Google. Serve proprio la coppia.

Passo 5: come verifico che funzioni?

Aggiungi un nome che esiste solo sul MikroTik:

/ip dns static add name=prova.dojo.lan address=10.9.9.9

Poi, da un PC della rete, chiedilo apposta a un DNS esterno:

host prova.dojo.lan 8.8.8.8
nslookup prova.dojo.lan 1.1.1.1

Google non sa cosa sia prova.dojo.lan. Se la risposta è 10.9.9.9, ha risposto il MikroTik. In laboratorio, prima delle regole: “not found”. Dopo: prova.dojo.lan has address 10.9.9.9, chiedendo a 8.8.8.8, a 1.1.1.1 e a 9.9.9.9, anche in TCP. Sul router i contatori salgono:

/interface bridge nat print stats
/ip firewall nat print stats

Passo 6: e adesso che ci faccio?

Il DNS di tutta la rete passa da te. Per esempio, per bloccare un sito e tutti i suoi sottodomini:

/ip dns static add name=tiktok.com type=NXDOMAIN match-subdomain=yes

Chi chiede www.tiktok.com a qualunque DNS si sente rispondere che non esiste. Provato in laboratorio, sia verso 8.8.8.8 sia verso 1.1.1.1.

Lo stesso schema funziona per altri servizi: cambi la porta nelle due regole e porti al router quello che ti serve.

Cosa controllo prima di metterlo in produzione?

• il DNS cifrato non si intercetta: browser e telefoni che usano DNS over HTTPS (DoH) o DNS over TLS (porta 853) passano lo stesso. Per un filtro serio vanno chiusi anche quelli: come fare è nell’howto su come bloccare DNS over HTTPS e DNS over TLS;
• se il MikroTik si spegne, il bridge si interrompe e la rete resta senza collegamento verso il router: usalo dove lo puoi alimentare bene;
• tutto il traffico DNS passa dalla CPU, il resto no. Per un ufficio è nulla;
• il MikroTik è nella rete del cliente con un suo indirizzo e il DNS aperto: proteggilo con l’Hardening di base di un router MikroTik.

Provato in laboratorio su PNETLab con CHR RouterOS 7.24.5 (stable) in bridge fra un client Debian 12 e un altro router con DHCP: solo NAT IP (contatori a zero), bridge NAT più NAT IP (risposta del MikroTik verso 8.8.8.8, 1.1.1.1 e 9.9.9.9, in UDP e TCP), solo bridge NAT (risposta di Google), blocco di un dominio con type=NXDOMAIN.