#22 Por eso comentaba en #4 el tema de que no sabía si las consultas debían ser directamente de los clientes a PiHole. Una alternativa sería que en la configuración de Networks de DHCP pusieras como DNS el PiHole, y cambiar el lease time del servidor DHCP a unos pocos minutos (00:02:00 por ejemplo, o menos incluso). La idea de esto es:
- Si está funcionando PiHole, los equipos van a consultar PiHole, que es lo que le dice el servidor DHCP a los clientes.
- Si PiHole cae, el Mikrotik lo detecta, cambia el servidor DNS en el Networks a la IP que quieras, y los equipos conforme vayan lanzando consulta al servidor DHCP para renovar la IP deberían coger el cambio DNS. Piensa que por protocolo, los equipos a la mitad del tiempo de lease, van a consultar al servidor DHCP, si no contesta, al cuarto de finalizar el lease vuelven a preguntar, etc. Bueno, pues siendo eso así, si pones dos minutos, como máximo un equipo va a tardar un minuto en recoger el cambio de DNS.
- Una vez que el Mikrotik detecta que el PiHole ya está funcionando de nuevo, se vuelve a dejar todo como estaba.
Básicamente, la idea es la misma que el script que ya tienes, sólo que ahora tocamos otras cosas. La "contrapartida", que va a haber mucho más tráfico DHCP por tu red local, pero no va a afectar prácticamente nada.
Entonces, si quisieras probar, recopilando:
Haz un backup antes de tocar.
Deshabilita el anterior scheduler en System - Scheduler.
Deshabilita las reglas de NAT y de Mangle creadas anteriormente.
En IP - DHCP Server - Networks cambia el DNS al PiHole
En IP - DHCP Server - DHCP cambia el Lease Time a un valor bajo.
Te hace falta esta regla de Firewall, no hace absolutamente nada, existir para el script.
/ip firewall filter add action=passthrough chain=forward comment=DNS_CHECK protocol=ospf
- En System - Scheduler crea un nuevo scheduler con este código (o modificas el anterior y lo habilitas de nuevo), cambiando los valores a los tuyos:
# Get Passthrough ID
:local passthroughRuleId [/ip firewall filter find comment="DNS_CHECK"]
##### SET your values #####
:local queryDomain "www.google.com"
:local ipRange "192.168.3.0/24"
:local piHoleIp "192.168.3.34"
:local alternativeDNS "8.8.8.8"
############################
:if ([/ip firewall filter get $passthroughRuleId disabled] = false) do={
:do {
:resolve $queryDomain server=$piHoleIp
} on-error={
/ip dhcp-server network set [find address=$ipRange] dns-server=$alternativeDNS
/ip firewall filter set $passthroughRuleId disabled=yes
}
} else={
:do {
:resolve $queryDomain server=$piHoleIp
/ip dhcp-server network set [find address=$ipRange] dns-server=$piHoleIp
/ip firewall filter set $passthroughRuleId disabled=no
} on-error={}
}
#29 A mí me da que la regla de HairpinNAT en el fondo lo que hace es enmascarar los paquetes poniendo como IP origen la IP del Mikrotik al llegar al PiHole, pero vamos, como comentas, sería que pegase un export de la parte de Firewall, y ya que a ti te funciona, compares a ver por dónde pueden ir los tiros. Yo esto de HairpinNAT lo he usado alguna vez para meter un Mikrotik en la red de algún cliente, pero que no fuese la puerta de enlace de los equipos, y conectado mediante VPN a ese Mikrotik, llegar a servidores internos con la IP del Mikrotik en la VPN:puerto_servidor (reglas dst-nat y regla hairpin-nat). Al final lo que conseguía era que de cara a los servidores la conexión viniese de un equipo de la red interna, que era el Mikrotik. Yo no tengo PiHole y no puedo aportar mucho más al respecto 
