RouterOS Mikrotik - configurar servidor DNS y alternativos

NeoDunadan

#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 :confused:

1 4 respuestas
itonny

#31 Esta solución también es muy buena lo que a mi personalmente no me gusta jugar mucho con leases cortos, básicamente por los equipos que se conectan vía wifi y suelen estar conectándose y desconectándose frecuentemente, pero en entornos domésticos no tendría que haber problema.

#30 Te recomiendo a este hombre:

P.D: A todo esto estaría chulo hacer un thread general de Mikrotik para los que se quieran aventurar con ellos xd

1 3 respuestas
NeoDunadan

#32 Yo tampoco soy fan de tenerlo tan bajo, y en entorno empresarial ni de casualidad lo pongo así. La cuestión, yo me lo he dejado en casa a 2 minutos a ver qué tal, más que nada porque si veo que da problemas, escribo de nuevo por aquí para descartar la opción. Por defecto Mikrotik creo recordar que en su configuración inicial te lo planta en 10 minutos, y siempre me pareció demasiado poco, y lo cambio mínimo a 1 hora...

Y por cierto, coincido contigo con Greg, muy buenos tutoriales. La wiki de Mikrotik tampoco está mal para ir picando de aquí y de allá, y a nivel profesional, me gustan los cursos de la UPV, muy buenos para aprender no sólo Mikrotik, también redes.

2 respuestas
morlop

#32 Pues a los que entendéis os animo xD
Voy a ir echando ojos al gregsowell este.
Y esta tarde os pego mi nat.

#33 ¿UPV? ¿Gratis/Precio? ¿Web con info?

morlop

#32 #33 Entonces mejor mantener la configuración de #12, no?
Insisto en la pregunta de, ¿Hay algún problema por hacer ping a google cada 10s? ¿Me pueden banear?

#29itonny:

Por otro lado me puedes pegar un pantallazo del firewall en el apartado NAT? Porque a mi me identifica individualmente las peticiones


Lo azul es lo único que he añadido yo por mi cuenta para redirigir puertos al servidor.
El 1º es el default masquerade para tener internet imagino.
Los de abajo son los tuyos.

#29itonny:

Depende como tengas los rangos IP de la VPN, en las reglas del NAT tendrás que incluirlos si no es la misma subred (en address list añade el rango a LANs)

Claro, creo que el contenedor por defecto usa otra red: 10.8.0.2 cuando mi red es 192.168.0.0/24
Yo pensaba que al conectar por VPN usaba la red del host del vpn.

1 respuesta
itonny

#35 Si te fijas las reglas no se te están aplicando correctamente por el orden. En el contador que hay a la izquierda de tus reglas ves la cantidad de trafico que ha pasado por ella, en la del hairpin no ha pasado trafico en ningun momento.

El Hairpin el primero de todo, luego las 2 reglas blocky y por ultimo tu masquerade. El masquerade con la 192.168.0.0/24 la puedes borrar ya que es una duplicidad de la primera.

Cuando lo tengas en orden prueba a ver si te muestra correctamente en PiHole los origenes de las peticiones

1 respuesta
morlop

#36
Entiendo este orden y el otro masquerade borrado.
Además he reseteado el router.
Ahora el hairpin tiene tráfico, pero veo que el 2º blocky, el tcp no tiene movimiento.

Adguard home sigue diciendo que todo viene del router .1

1 respuesta
itonny

#37 mmm pues de momento la solución más cercana es la que te han comentado antes. Igualmente miraré a ver si puedo replicarlo porque mi entorno de pruebas tiene mil mierdas y routers entre medias que pueden estar influyendo xd

1 respuesta
morlop

#38 Tengo que subir el mangle arriba del todo también?

Da error si quiero subirla:

Y esto mi firewall:

#31 agradezco tu aportación aunque como decís, creo que es mejor la otra opción y la mantendré

1 respuesta
NeoDunadan

#39 Los cursos de la UPV son de pago, yo los hice hace varios años y he buscado y no sé si todavía los mantienen, pero bueno, al final buscando tutoriales y cacharreando es como se aprende. Mikrotik tiene la certificación MTCNA que es el equivalente al CCNA de Cisco, y te dan un repaso por todo RouterOS y teoría básica de redes, es uno de los que hice allí en la UPV.

Las reglas de Mangle que vienen son dinámicas por defecto y no vas poder poner nada delante, pero no te preocupes que está bien. Y las de filter son las por defecto, y tal como están no hace falta tocar nada y estás protegido.

Como he comentado antes mantendré el tema del lease y actualizo en unos días si he tenido algo, por si quieres probar lo de #31

Y bueno, como he comentado, lo mejor es cacharrear, si te gusta el tema de redes, Mikrotik está bien para aprender. Yo ni sé la de veces que habré hecho y rehecho configuraciones probando un poco de todo 😅

1 respuesta
itonny

#40 lo mejor de mikrotik a diferencia de muchos routers es que puedes ver en detalle lo que ocurre, como se comporta el tráfico y aprender de forma practica como funciona el mundillo de las redes.

En los comerciales es más un salto de fe y creer que todo funciona como debería funcionar xd

1 respuesta
morlop

Aún sigo intentando entender #12 (estoy intentando aprender todo el funcionamiento)

No deberíamos exceptuar la IP del servidor de ser redirigida a la IP del servidor?

Al poner LANs en Blocky, incluimos al propio servidor pihole y vamos a redirigir su consulta dns a sí mismo no?

No haría falta en "dst-address-list=LANs" poner "!192.168.3.34" en lugar de "LANs"?

Perdonad que sea cansino pero me gusta entender las cosas bien.

Actualización: Me comentan esto en foro mikrotik como motivo de por qué no veo las IPs de los clientes en PiHole con la configuración de #12. En resumen, el PiHole está en la misma subred que los clientes, y esa subred está enmascarada por Hairpin. Creo que para solucionarlo me dice de mover el servidor a otra subred. ¿Viabilidad de esto?

Curently you're running a thing called "hair-pin NAT" for PiHole DNS service (the src-nat/masquerade is essential part of it). As long as PiHole server is in the same IP subnet as clients, you can not get rid of src-nat/masquerade which obfuscates clien IPs. You could move PiHole to another IP subnet (preferrably not by overlaying your LAN L2 broadcast domain by another IP subnet but rather by using dedicated LAN broadcast fonain - there are many ways of doing it) ... which would allow you to get rid of src-nat/masquerade towards PiHole, dst-nat would be enough.

Entiendo lo de mover el Pihole de subred pero esto no lo entiendo "(preferrably not by overlaying your LAN L2 broadcast domain by another IP subnet but rather by using dedicated LAN broadcast fonain - there are many ways of doing it)"

¿Tendría que hacer una segunda subred en una boca específica del router? Porque si eso es así descartado por mi esquema físico de red doméstica.

morlop

#41 Aprovechando el hilo.. ¿Entre mikrotik y cisco? Y ya puestos, ¿MTCNA o CCNA?

De paso os recuerdo la respuesta que me han dado en #42 que la he dado por válida y entiendo que no puedo hacer nada.

NeoDunadan

Voy a intentar explicar lo que hacen las reglas que tienes actualmente, para que veas lo que ocurre:

El escenario que tienes es que el Mikrotik hace de servidor DHCP, y en su configuración dice que él mismo es el servidor DNS.

Vale, teniendo eso en cuenta, estas dos reglas, dicen algo como lo siguiente:

/ip firewall nat
add action=dst-nat chain=dstnat comment=Blocky dst-address-list=LANs dst-port=53 protocol=tcp src-address-list=LANs to-addresses=192.168.3.34
add action=dst-nat chain=dstnat comment=Blocky dst-address-list=LANs dst-port=53 protocol=udp src-address-list=LANs to-addresses=192.168.3.34

"El tráfico que tenga como destino la red LAN, y que tenga origen la red LAN, y que su protocolo sea el tcp/udp y que el puerto sea el 53, me lo mandas a la IP 192.168.3.34".

Si nos quedamos sólo con esto, lo que ocurre es que por ejemplo, tu PC quiere consultar la IP del DNS mediavida.com, y se lo pregunta a su servidor, que es el Mikrotik. El Mikrotik recibe ese tráfico, y se da cuenta de que tiene una regla que ese tipo de tráfico (udp/tcp 53) lo manda a la IP 192.168.3.34, y eso es lo que hace, se lo manda.

El PiHole entonces recibe ese tráfico, procesa la consulta DNS, averigua la IP de mediavida.com, y entonces lanza la respuesta. ¿A quién? Pues mira el paquete, y ve que la IP de origen de la consulta es tu PC, con la 192.168.3.X, y manda esa respuesta a tu PC directamente, sin pasar por el Mikrotik, porque estás en su mismo rango. ¿Y qué hace tu PC? Pues ve que le mandan un tráfico que él no ha solicitado (porque él se lo ha pedido al Mikrotik, no al PiHole), y descarta ese tráfico.

Para solucionar esto, se crea la regla de Hairpin NAT, que no hace otra cosa que decir: cualquier tráfico en la cadena srcnat con el connection mark de HairPin NAT lo enmascaras (es decir, le pones como IP de origen la mía, la del Mikrotik). Vale, pues con esto, cuando el Mikrotik recibe la consulta y la manda al PiHole, cambia la IP de origen de tu PC por la suya, y se "guarda" que fue tu PC el que hizo esa consulta. El PiHole ahora contesta al Mikrotik, y el Mikrotik, que sabe quién hizo la consulta, lo devuelve a tu PC. Y como tu PC hizo la consulta al Mikrotik, le vale ese tráfico de vuelta, y resuelves mediavida.com.

Bueno, si has llegado hasta aquí, lo que te dicen en el foro está bien, pero faltaría una pieza.

Si metes al PiHole en otra red, el Mikrotik se va a encargar de enrutar el tráfico de una red a otra, por lo que si tú lanzases un ping a la IP del PiHole en otra red, como no está en la tuya, se lo pasa al Mikrotik, que es tu gateway/puerta de enlace. El Mikrotik sabe llegar al PiHole, y le pasa el paquete de ping. PiHole te responde a ti, pero como no estás en su rango, se lo pasa al Mikrotik, y el Mikrotik, que sabe dónde estás tú, te manda el paquete. En esta parte no entran ni reglas de NAT ni nada de nada.

Ahora bien, si volvemos al tema anterior. Las reglas de NAT serían estas, por ejemplo, rango distinto:

/ip firewall nat
add action=dst-nat chain=dstnat comment=Blocky dst-address-list=LANs dst-port=53 protocol=tcp src-address-list=LANs to-addresses=192.168.4.34
add action=dst-nat chain=dstnat comment=Blocky dst-address-list=LANs dst-port=53 protocol=udp src-address-list=LANs to-addresses=192.168.4.34

Lo que ocurre es que cuando consultes DNS, el Mikrotik le va a pasar la consulta al PiHole que está en otra red. Para el PiHole, la IP origen, como antes, es la de tu equipo, y te va a devolver el paquete poniendo en la cabecera la IP destino la tuya, pero como no estás en su red, pasa el tráfico al Mikrotik. El Mikrotik coge ese tráfico, y ve que tú eres el destinatario, y te manda la respuesta. Pero él no hace más que de director de tráfico, él no es el origen del tráfico, en la cabecera de ese tráfico el origen es el PiHole. Así que pasa lo mismo que comentaba antes, tu equipo recibe un tráfico que no espera, pues tiene origen el PiHole, y lo que hace es descartarlo.

Para solucionar esto, haría falta una regla de NAT tal que así:

/ip firewall nat
add action=masquerade chain=srcnat src-address=192.168.4.34 dst-address-list=LANs

Lo que hace esta regla es coger el tráfico que devuelve el PiHole hacia tu equipo, y como el origen del tráfico es el PiHole, y el destino es las IPs de la LAN, el Mikrotik enmascara la IP de origen del PiHole y pone la suya. Con esto, tu equipo, que espera ver una respuesta por parte del Mikrotik, recibe esa respuesta.

Al final, lo que estamos haciendo es engañar a tu equipo para que vea que el tráfico vuelve del sitio que él espera.

Si ves que no vas a cambiar de rango el PiHole y tal, prueba lo que te comenté en #31 , que se acercará más o menos a lo que necesitas sin tener que hacer cambios en la LAN.

1 1 respuesta
morlop
#44NeoDunadan:

mira el paquete, y ve que la IP de origen de la consulta es tu PC, con la 192.168.3.X, y manda esa respuesta a tu PC directamente, sin pasar por el Mikrotik

Muchas gracias por toda la explicación.
¿Creéis que hay algún problema práctico de algún tipo en poner el lease time tan bajo?
Y otra cosa que sigo mosca, ¿puede haber algún problema con google por hacerle tantos pings?
Gracias!

NeoDunadan

Yo llevo desde que escribí #31 con el lease a 2 minutos, y no he notado nada en ningún dispositivo, ni TVs, ni PCs (Windows y Linux), ni en contenedores (Nextcloud, Webtop, Vikunja), ni móviles, ni portátiles, ni IPad, todo funciona como siempre. Al final es probarlo, y si no te convence, a otra cosa.

Por lo que comentas del ping a Google, piensa que no estás haciendo ping, el Mikrotik está preguntando a PiHole si puede resolver www.google.com y decirle la IP que tiene, nada más que eso. Si se cae el PiHole, no vendría la respuesta a la consulta DNS al Mikrotik, daría error el script en la parte de :resolve (on-error), y ejecutaría los cambios pertinentes, y supongo que el PiHole, al tener cacheada la entrada DNS de www.google.com no estaría constantemente preguntando qué IP tiene, quitando las veces que el TTL de la entrada caduque. Al final esos cada 10s que se ejecuta el script es para ver si PiHole está levantado y responde a consultas DNS.

Y aunque fuese un ping, yo he tenido pings al 8.8.8.8 o 4.2.2.2, o google.com, y no te van a hacer nada, están más que acostumbrados a recibir pings xD

Sobre tema certificaciones. Yo ya no me dedico a temas de redes, vaya por delante. Mikrotik está chulo, se usa bastante a nivel Datacenter por tema relación calidad/precio, está bien para montarte muchas cosas, para aprender redes a bajo nivel, pero, pienso que una certificación de Cisco tiene más reputación que Mikrotik, y quien dice Cisco, dice Fortinet, Watchguard, F5, PaloAlto, Arista y alguna marca más que seguro me dejo en el tintero, porque ya te digo, no estoy ya en el mundillo. Si quieres dedicarte de forma profesional a redes, esas marcas siempre van a estar solicitadas en las mejores ofertas de trabajo...

1 1 respuesta
morlop

#46 Pues voy a probar la config de #31 guardando una copia de seguridad primero de esto.

Por cierto, me han dicho que en Files, carpeta que creé backup, si reseteo de fábrica el router, esos archivos se mantienen y por tanto estoy "seguro" de tocar.

1
NeoDunadan

También puedes arrastrar el fichero desde Winbox al PC desde Files, y viceversa, y te quedas más tranquilo.

1
morlop

#31 Estoy probándola... Los equipos con ip estática también renuevan el lease?
Poniendo #31 veo esto en leases:

No sé si es que tarda un tiempo en adaptar todos los tiempos a los nuevos.

Entiendo que tengo que desactivar el allow remote request?

edit: vale, los tiempos de lease van bajando a 2 minutos poco a poco.
He desactivado el remote request porque seguía haciendo las consultas el router. Ahora parece que está todo ok y sí tengo registro de todos los usuarios.

¿Qué "desventajas" puede tener el bajo lease time para una red doméstica? No creo que este tráfico cada 2 minutos colapse nada...
Y la regla de firewall para qué es? No la entiendo.

/ip firewall filter add action=passthrough chain=forward comment=DNS_CHECK protocol=ospf

Tengo esa regla la última al ser la nueva. La subo a la primera? O aquí el orden da igual y no es como nat?

1 respuesta
NeoDunadan

#49 Sí, el lease time poco a poco les irá cambiando, se podría haber forzado la verdad, se me olvidó comentarlo.

Desventajas, a ver, no creo que muchas en una red doméstica. Una vez el cliente tiene que renovar la IP (si has puesto 2 minutos, será entonces cada minuto), enviará una petición al servidor (unicast) para hacer el renew. Si el servidor, en este caso el Mikrotik, contesta, todo bien. En caso de que no conteste, cuando quede aproximadamente unos 20 segundos de lease, enviaría una petición broadcast esperando que cualquier servidor le conteste. Al final lo único que estamos haciendo es aumentar la frecuencia de peticiones unicast y respuestas a cliente desde el Mikrotik. Es tráfico UDP además, por lo que el Mikrotik no tiene que gestionar/mantener conexiones, así que tampoco genera mucha carga a nivel CPU. Para que te hagas una idea, yo tengo un Mikrotik de hace más de 10 años (450G), y ni se entera de esto.

La regla de firewall da igual donde esté, es una regla auxiliar/apoyo para el script. El action passthrough se utiliza normalmente para registrar tráfico antes de otras reglas, como algo visual más que nada, o para lo que estamos haciendo, como apoyo para scripts. Como tampoco es la función que queremos darle, le he metido el protocolo OSPF, que es de enrutamiento y no se usa en redes domésticas para que no registre nada tampoco. La regla dice algo como: El tráfico OSPF que pase a través del Mikrotik (forward) le aplicas la accion passthrough, y su comentario es DNS_CHECK. Tu Mikrotik nunca va a registrar tráfico OSPF pasando por él, y a nosotros lo que nos interesa en el script es el comentario para localizar la regla, da igual si está la primera o la última.

1 respuesta
morlop

#50 Entiendo, gracias, pero a mi entender, el script solo activa la regla firewall o la desactiva, además de cambiar la DNS en IP - DHCP Server - Connections.
Entiendo que esto último es la clave, lease time bajo y alternar la IP del DHCP Server, si quito la regla firewall, ¿En qué cambiaría? A mi entender nada.
Comento esto porque desde mi ignorancia, si hubiera hecho esto yo solo, solo hubiera hecho el script para cambiar la DNS, no hubiera creado una regla firewall y el script solo verificaría el dominio de test desde mi servidor, si no responde desde la DNS pública y voy alternando las DNS, pero jamás hubiera creado la regla firewall.
Por eso quiero entender la función que tiene y qué hubiera pasado si lo hubiera hecho sin esa regla o si la quitara. Por entender las cosas, sé que soy pesado, pero me gusta entender todo xD

1 respuesta
NeoDunadan

#51 Nada, tranquilo. A ver.

El script lo primero que hace es:

  • Recoge el ID de la regla de firewall auxiliar.
  • Defines variables locales del script.

Ahora es donde viene la chicha. En nuestro problema tenemos dos estados/escenarios:

  • El PiHole está OK.
  • El PiHole no está OK.

Para saber si el PiHole está o no OK no nos vale por ejemplo con un ping, o saber si la interfaz web está levantada, lo que nos vale es saber si responde a consultas DNS o no. Por tanto vamos a usar resolve.

Luego, además, tenemos el problema de que en Mikrotik no tenemos una base de datos donde almacenar variables que persistan a reinicios, fallos de corriente, etc., así que nos las tenemos que ingeniar para tener una "variable" que nos de la capacidad de tener un verdadero/falso - OK/NO OK, y en este caso lo podemos hacer con una regla de firewall que no afecta al tráfico, la cual, podemos activar/desactivar (verdadero/falso), y tras un reinicio estará tal cual se quedó.

Como vamos a tener dos estados, usamos un condicional, el if, que al final no es más que decir que si algo es verdadero, me haces esto, y si es falso me haces esto otro. Para el verdadero usamos que la regla esté habilitada (disabled = false), y para el falso, lo contrario (else, o lo que es o mismo, disabled = true).

En el caso de verdadero, que es lo habitual, o el escenario donde todo está bien y el PiHole está levantado, le decimos al Mikrotik que intente resolver la URL mediante el PiHole. Si resuelve bien, no hace nada más, y termina la ejecución del script. En caso de error, cambia la DNS a la alternativa, y cambia el estado/escenario deshabilitando la regla. Esto último es la gracia del asunto, veníamos de estar PiHole levantado, y ahora que ya no lo está, hay que indicarle al Mikrotik que no está bien, ya que en el script tenemos otro estado, el del else, donde tomamos medidas frente esto, así que deshabilitamos la regla y el script sabe que se enfrenta en la próxima ejecución a otro escenario.

En el caso de falso, que es cuando ha fallado el PiHole (lo sabe el script porque la regla de firewall está deshabilitada), volvemos a intentar resolver. Si falla la resolución, da error, y las siguientes dos líneas se las salta, no las ejecuta, y no hacemos nada porque no ha cambiado el estado en que se encuentra el PiHole, que está caido. En caso de que no falle la resolución, significa que el PiHole ha vuelto a estar operativo, y ahora sí, se cambia de nuevo el DNS al PiHole y se habilita la regla de firewall para indicar que todo está bien.

El script podría limitarse a esto, y funcionaría:

##### 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"
############################

:do {
    :resolve $queryDomain server=$piHoleIp
    /ip dhcp-server network set [find address=$ipRange] dns-server=$piHoleIp 
} on-error={
    /ip dhcp-server network set [find address=$ipRange] dns-server=$alternativeDNS
}

El problema que tiene es que siempre estás ejecutando el cambio de IP, ya sea porque resuelve bien y reafirmas la IP del PiHole, o porque resuelve mal y reafirmas la IP alternativa hasta que vuelve a resolver bien.

Con el script con el if, si está todo bien sólo ejecutas el resolve, y si está mal y continúa estando mal, sólo el resolve también. Es decir, sólo ejecutas cambios sobre el Mikrotik cuando es imprescindible: en caso de fallo, o en caso de recuperación.

Espero que se haya entendido!

1 respuesta
morlop

#52 entiendo, estás usando la regla firewall como mera variable para comprobar y para tener persistencia... ahora sí xD

1 respuesta
NeoDunadan

#53 Eso es. Es que claro, al final cuando te has acostumbrado a ver esas cosas por ahí, ya no te parece extraño xD, pero si vienes de nuevas es normal que no te encaje.

En Mikrotik también existen las variables globales (:global), que pueden ser consultadas por cualquier script. Normalmente compartes un valor global porque quieres que otro script lo consulte para otra cosa, o porque quieres que un mismo script consulte la variable en cada ejecución.

El problema es que en tu caso es necesario saber en qué estado está el asunto. Imagina que usas una variable global para esto. Esta variable persiste mientras el Mikrotik esté encendido. Al iniciar el Mikrotik, tienes un script que comprueba el DNS y dice si PiHole está bien o mal (true/false), y lo mete en una variable global.

Luego tienes este otro script, que consulta en vez de la regla de firewall, la variable global. En general, todo el tiempo estaría funcionando bien, cambiando cuando tuviese que cambiar el DNS, etc. El problema viene con que si se te cae el PiHole, se te cambia al DNS alternativo, no restaura, y reinicias el Mikrotik, y mientras reinicias el Mikrotik, el PiHole vuelve a estar operativo, cuando el Mikrotik arranca, comprueba que efectivamente el PiHole está levantado, y pone a true la variable global. Tu script de comprobación y cambio de DNS, se encontraría con que está en true, y no te cambiaría la DNS al PiHole, quedándose la alternativa hasta que se te caiga el PiHole y se te volviese a levantar.

Claro, no es habitual que pase todo eso a la vez, pero es una posibilidad. Si en vez de usar la variable global, utilizas la regla de Firewall, hubiese estado deshabilitada, y el script te hubiese restaurado la configuración DNS. Vamos, que no tiene flecos.

Lo suyo sería que Mikrotik tuviese algo parecido a variables persistentes, pero por lo que he visto, todavía no hay nada. He visto algo que usa también el tema del layer-7 para almacenar variables y valores, aquí se han currado una función que sirve para esto. Sería tener un scheduler on startup con ese código, y luego se podría utilizar en cualquier otro script para escribir y leer variables. No está mal.

Así que nada, espero que te haya servido todo esto para aprender un poco más de Mikrotik xD

1 1 respuesta
morlop

#54 Todo claro, muchas gracias por la clase.

1
16 días después
morlop

@NeoDunadan una pregunta, si en un móvil tengo DNS manuales forzadas, me dice al conectar al wifi que "No se pudo acceder al servidor DNS privado". En cambio si lo desactivo o pongo automático, perfecto.
Es como si la red wifi no deja usar un DNS que no sea el proporcionado por él.
¿Podría ser? En el móvil siempre tengo un DNS de dns.adguard-dns.com o x-hagezi-ultimate.freedns.controld.com para bloquear siempre la publi esté donde esté, pero en el wifi me pasa esto.

Pd: no sé por qué pero ahora parece ir bien