Forzar redirección a Pi-hole de las peticiones DNS a servidores "hardcodeados"

Bramante 27 enero 2020 13:32 ✎

⋮

Escenario:

HGU (acting as DHCP server) ↔ Punto de acceso inalámbrico (Archer C7 - ddwrt) ↔ Pi-hole (servidor DNS de la red) ↔ Clientes

El HGU es el que asigna las IP's a los clientes, el Archer solo hace de punto de acceso Wi-Fi y la Raspberry es quien sirve las peticiones DNS (usa Cloudflare con DoH).

Todo funciona como debe y Pi-hole bloquea la publicidad en la red doméstica, pero con esta configuración, se le están escapando las peticiones DNS a servidores que algún dispositivo pueda tener hardcodeados en el firm.

No sé bien cómo hacer que todo el tráfico DNS, al menos el dirigido al puerto 53 TCP/UDP, pase forzado por la Raspberry. ddwrt sí que ofrece esa opción, pero como no lo uso como servidor DHCP, no me sirve.

¿Quizá vía el firewall del HGU? Así lo tengo ahora (será mejor o peor, pero es mi configuración personal, adaptada a mis necesidades actuales):

Y estas son las opciones para crear una nueva regla:

Agradecido de antemano!

BocaDePez 27 enero 2020 13:39

⋮

Regla de iptables en el ddwrt supongo

✖

Bramante 27 enero 2020 13:42

⋮

Regla de iptables en el ddwrt supongo

Para los clientes inalámbricos entiendo que sería una opción sí. Voy a pegar un vistazo a cómo quedaría la regla.

Pero, ¿los clientes cableados?

Gracias BdP.

✖

BocaDePez 27 enero 2020 14:12

⋮

Conecta los cables al AP...

Dudo que el HGU te permita hacer lo que quieres. Como bien te dicen abajo, el firewall es muy limitado.

Bramante 27 enero 2020 13:50

⋮

¿Esto funcionaría o es una tontería?

✖

BocaDePez 27 enero 2020 14:58

⋮

No os estáis complicando mucho la vida?

La solución es bloquear en el HGU. No tengo uno a mano, pero yo probaría a crear dos reglas:

Una primera que permita el tráfico DNS (53 UDP/TPC) solo con origen la IP de la Pi-hole.

Una segunda que haga un Deny de todo el tráfico DNS de la subred interna a cualquier otra.

El orden es importante.

Lo que no tengo claro, es si te afectará a la tele y/o VoIP ya que creo recordar que entregan unos DNSs distintos.

✖

BocaDePez 27 enero 2020 15:20

⋮

Entonces las aplicaciones que resuelvan directamente fallarán, a no ser que reintenten con las DNS del router, cosa que es improbable.

✖

Bramante 27 enero 2020 16:46

⋮

Claro, pero en parte me vendría bien porque podría detectar aquellos cacharros que me hacen el lio y me circunvalan la Raspberry por obra y gracia de su creador.

✖

BocaDePez 27 enero 2020 18:44

⋮

✖

Bramante 27 enero 2020 18:48

⋮

Bramante 27 enero 2020 16:49

⋮

La solución es bloquear en el HGU.

Por ahora, es lo primero que voy a hacer.

Primero tengo que darme de ostias con el NAS porque aún no sé por qué, pero se niega en rotundo a conectarse si le digo que obtenga la IP usando el servidor DHCP, se queda sin conexión si no le pongo la IP y servidor DNS (que ha de ser directamente 1.0.0.1) a mano.

NetVicious 27 enero 2020 13:50

⋮

Tienes que meter una DNAT en todas las peticiones que salgan a internet en el que el puerto destino sea el 53 (udp y tcp), redirigiendo el paquete a la IP de la Raspberry. Ojo que tienes que decirle que no haga ese DNAT si el origen del paquete es la Raspberry, en ese caso montarás un loop guapo.

Lo suyo es meter dicha regla en el router de salida a internet, pero si ese no te da dicha opción tendrás que meterla en otro router anterior. ¿Tienes algún dispositivo conectado directamente al HGU además del Archer que sí que te dará dicha opción seguramente?

✖

Bramante 27 enero 2020 13:55

⋮

Hola @NetVicious, vayan por delante las gracias.

Lo suyo es meter dicha regla en el router de salida a internet

Sí, el HGU. ¿Cómo ves la última regla que he creado en su firewall?

¿Tienes algún dispositivo conectado directamente al HGU además del Archer que sí que te dará dicha opción seguramente?

Sí, varios sobremesas, el NAS, el HTPC, el brige de HUE, un HDHomeRun y suma y sigue... ;-)

Ojo que tienes que decirle que no haga ese DNAT si el origen del paquete es la Raspberry, en ese caso montarás un loop guapo

Ostias, en eso no había caído!! Entonces, el ingenio de la última regla que he añadido al HGU, no me serviría.

Gracias!!

✖

NetVicious 27 enero 2020 14:03

⋮

No te sirve porque esa pantalla es más un firewall de lo que se permite y lo que no (permit o reject). Y siendo un HGU tiene pinta de estar pensado más bien para tráfico que viene de fuera a dentro (aka abrir puertos) y no de dentro a fuera.

Para tener el control total de tu conexión te va a tocar poner otro router entre el HGU y todos los equipos de tu red. Hace mucho que no uso dd-wrt y no te sabría decir si tiene el tipo de regla que tienes que poner, diría que sí, pero ..... Yo esas cosas las hago con Mikrotik, donde puedes hacer de todo sin ninguna limitación.

Prueba a poner una regla similar en el Archer haciendo DNAT y por lo menos los dispositivos que tienes conectados a el pasarán por el DNS de la Pi.

✖

Bramante 27 enero 2020 16:53

⋮

Hace mucho que no uso DD-WRT y no te sabría decir si tiene el tipo de regla que tienes que poner, diría que sí, pero …

Sí, DD-WRT te permite hacerlo incluso vía GUI:

Pero como tengo el servidor DHCP deshabilitado y esa opción depende de Dnsmasq para funcionar, no me sirve.

Prueba a poner una regla similar en el Archer haciendo DNAT y por lo menos los dispositivos que tienes conectados a el pasarán por el DNS de la Pi.

Voy a ver si me aclaro con eso.

Gracias!!

✖

NetVicious 27 enero 2020 18:07

⋮

✖

Bramante 27 enero 2020 18:50

⋮

Bramante 27 enero 2020 19:52

⋮

Después de unas pruebas y otras otras, así ha quedado la cosa:

Ahora es Pi-hole quien mueve el servidor DHCP y DNS.

Como tengo configurado Pi-hole con Cloudflared y DoH usa el puerto 443, puedo cerrar totalmente la salida en el puerto 53 TCP/UDP desde el firewall del HGU. Ahora mismo, las peticiones a servidores DNS hardcodeados (que se hagan a través de FQDNs:53, a IP directa, me las como, obviamente) deberían morir en la orilla y no salir de casa.

Ahora, a esperar a ver si algún cacharro da problemas.

Bramante 28 enero 2020 13:08

⋮

Cosillas interesantes extraídas desde ayer:

Los altavoces de Google Home, no respetan el servidor DNS que les pasa DHCP, van por libre. Solo bloqueando las peticiones a UDP 53 se consigue que haga fallback al indicado en el DHCP.

El HGU hace sus llamaditas a casa (a McAfee cada minuto, a Quantenna cada 5 minutos y a Google al arrancar):

✖

BocaDePez 28 enero 2020 13:20

⋮

Eso de Google es bien conocido.

mailarchive.ietf.org/arch/msg/dnsop/WCVv…RQNP84fBclI0

✖

Bramante 28 enero 2020 13:21

⋮

Sí, lo he encontrado esta mañana en Reddit buscando acerca del tema.

Feo comportamiento de Google.