BandaAncha

  • 🔍 en 📰 artículos ⏎
  • 🔍 en 💬 foros ⏎
  • 🔍 en 👇 este 💬 foro ⏎
  • 🔍 en 👇 este 💬 tema ⏎
Regístrate Regístrate Identifícate Identifícate

Marcado de tráfico del propio router en RouterOS 7

dnight

Tengo el siguiente escenario:

  • Un router Mikrotik con RouterOS 7.10 y 2 interfaces WAN. La primaria tiene NAT, por lo que no es accesible desde fuera y la segunda tiene IP pública.
  • Utilizo el servicio DDNS de Mikrotik para acceder desde fuera al equipo.

Necesito que la actualización de la IP del DDNS siempre salga por la WAN 2, porque de lo contrario no será accesible (wan1 tiene IP privada como comento arriba).

Leyendo el foro de Mikrotik, entiendo que debe ser tan simple como crear una tabla de rutas que tenga como default gateway wan2, marcar el tráfico en chain output para que se le aplique la tabla de rutas que hemos creado y esto sería suficiente para hacer que las peticiones al servicio cloud salgan por WAN 2.

Lo he probado de todas las formas posibles (creando una regla de SNAT para obligar a que el tráfico destinado al cloud se enmascare con la IP de wan2, creando una regla de enrutamiento para que se obligue a que las conexiones que tengan la marca de enrutamiento del cloud solo vayan a esta tabla de rutas pero no funciona.

Haciendo un log de la regla de mangle que aplico para poner el routing mark, veo que el paquete ya viene con la IP de WAN 1 por lo que en teoría ya sería muy tarde para hacer alguna modificación en la dirección e interfaz origen pero si trato de hacer el cambio desde el chain prerouting el paquete no hace match, por lo que no logro entender cómo determina el router cuál es la ruta que debe usar para el tráfico generado por si mismo, si es obligatorio usar la tabla de rutas principal o si tengo alguna forma de aplicar marcas a estas conexiones para hacer que salgan por la interfaz que necesito.

albertd

Siempre soy partidario de solucionar a nivel de enrutado lo que se pueda evitando la manipulación de paquetes.

Este es un claro caso: solo tienes que crear una ruta al servidor de actualización que utilice la interfaz oportuna. Rutas específicas tienen prevalencia sobre rutas más globales, a igualdad de métrica.

🗨️ 2
dnight

Hola,

Gracias por responder.

Pienso de la misma forma. El tema es que el servicio de ddns apunta a un nombre de dominio (cloud2.mikrotik.com) y no tengo control sobre a qué IP apunta este nombre.

Saludos.

🗨️ 1
albertd

No se dedican a jugar con la IP, así que puedes usar 159.148.147.201 pero si te quieres curar en salud, mete todo ese bloque que Mikrotik tiene asignado 159.148.147.0/24

pky
1

Mangle. Primero, en prerouting, marcas la conexión a “cloud2.mikrotik.com”. Y luego en output marcas el routing de ese connection mark. Y, para resolver la IP del dominio, la metes en una lista.

No me pillas en casa, pero si no te sale dime, y te mando luego un ejemplo de cómo quedaría.

Saludos!

🗨️ 6
dnight

Hola,

Gracias por responder.

Si marco el tráfico desde prerouting la regla no hace match, es como si para el tráfico que origina el propio router no se aplicara esta cadena si no que se fuera directo por la tabla de rutas por defecto.

Saludos.

🗨️ 5
pky
1

Correcto, no necesitas las de prerouting, porque el destino no es el router, sólo necesitas output. Algo así sería, siendo 1.2.3.4 la IP del gateway de tu ISPX:

/routing table
add fib name=toISPX
/ip firewall address-list
add address=cloud.mikrotik.com list=ddns-mikrotik
add address=cloud2.mikrotik.com list=ddns-mikrotik
/ip firewall mangle
add chain=output dst-address-list=ddns-mikrotik action=mark-routing new-routing-mark=toISPX
/ip route
add gateway=1.2.3.4 routing-table=toISPX

Saludos!

🗨️ 4
dnight

Hola,

Sí, esto hago pero la conexión sigue saliendo por WAN1. Es como si el routing mark no funcionara.

Cuando hago log al paquete veo que ya viene con la IP de WAN1 (como si la interfaz por la que se va a enrutar ya estuviera definida).

Incluso he puesto una regla de masquerade con src-address-type=local que dicen en el foro que así se obliga a modificar la dirección de origen del paquete a la de WAN2 pero no aumentan los contadores por lo que veo que el tráfico originado por el router no pasa por la parte de NAT al parecer.

Saludos.

🗨️ 3
pky
pky
🗨️ 2
dnight
dnight
🗨️ 1
pky
pky
dukez

Una idea por probar y te ahorras liarte a marcar paquetes,

Haz una regla de Output en el firewall a la IP del cloud con Deny o Drop hacia la interface WAN1 la que tienes tras NAT

Ahi te la respetara al 100% ya que las reglas output son las conexiones salientes del mismo router.

🗨️ 1
dnight

Hola,

Gracias por responder.

Al hacer esto en efecto bloquea la conexión por WAN1 pero no hace que salga por el otro ISP. simplemente se rechaza el paquete.

Saludos.

vukits

Necesito que la actualización de la IP del DDNS siempre salga por la WAN 2

Estás resolviendo algo por capa de IP cuando se puede resolver por capa de aplicación. (lo he dicho de manera formal, pero básicamente te doy la bienvenida a mi mundo de chapucillas y apaños ). DyNDNS por ejemplo, permite actualizar la IP mediante curl. (procura usar una contraseña dedicada a la actualización, y no a la administración)

Pasos del script: (ojo, no tengo ni idea de scripts de RouterOs: lo he sacado de aqui y de aqui): que los compañeros lo corrijan, por favor.

El siguiente script lo puedes ejecutar cada 5 minutos p.e, Como no es la ruta por defecto (infiero por lo que dices), no usaremos un servicio de descubrimiento externo sino obtendremos la IP a mano .

ether1 es es el nombre de tu interfaz WAN2 … vas a tener que cambiarlo según el nombre de tu interfaz wan2. (este script es del 2009, no tengo ni idea si sigue funcionando… pero la idea es más o menos esa)

# Define User Variables
:global ddnsuser "DYNDNSUSER"
:global ddnspass "DYNDNSPASS"
:global ddnshost "DYNDNSHOST"
 
# Define Global Variables
:global ddnsip
:global ddnslastip
:if ([ :typeof $ddnslastip ] = nil ) do={ :global ddnslastip "0" }
 
:global ddnsinterface
:global ddnssystem ("mt-" . [/system package get system version] )
 
##ether1 is the WAN interface you want to get public IP
# Grab the current IP address on that interface.
:global ddnsip [ /ip address get [/ip address find interface="ether1" ] address ]
 
# Did we get an IP address to compare?
:if ([ :typeof $ddnsip ] = nil ) do={
   :log info ("DynDNS: No ip address present on " . $ddnsinterface . ", please check.")
} else={
  :if ($ddnsip != $ddnslastip) do={
	 :log info "DynDNS: Sending UPDATE!"
	 :local str "/nic/update?hostname=$ddnshost&myip=$ddnsip&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG"
	 /tool fetch address=members.dyndns.org src-path=$str mode=http user=$ddnsuser password=$ddnspass dst-path=("/DynDNS.".$ddnshost)
	 :delay 1
	 :local str [/file find name="DynDNS.$ddnshost"];
	 /file remove $str
	 :global ddnslastip $ddnsip
  }
}
🗨️ 3
albertd

Esto ya es rizar el rizo. Mikrotik tiene su propio servicio DDNS gratuito incluido en la licencia del SO. Con que cree una ruta para la IP del servidor, que es conocida y nunca ha cambiado, lo tiene solucionado. Son 30 segundos, muchos menos que revisar un script de 2009.

dnight

Hola,

Creo que por sencillez voy a usar el DDNS de Mikrotik.

El script está muy bien y seguro siga funcionando. Cuando vaya a usar dyndns lo tendré en cuenta.

Muchas gracias.

🗨️ 1
vukits

Creo que no me estoy explicando bien, dnight.

Igual que hay un script para DynDns, hay uno para el DNS Dinámico de Mikrotik, y para noip, y para cualquier servicio de DNS dinámico que tenga API.

Ahora bien, si puedes solventar el tema con lo de la ruta estática pues maravilloso.

Pero lo que yo comento es menos invasivo ya que trabaja en capa de aplicación.

wilcoxlte

Y más sencillo, si no encuentras solución. ¿Por qué no haces que la WAN1 sea la que tiene la IP pública (es la que el router usa por defecto) y la WAN2 la privada?

🗨️ 2
albertd

Porque no querrá que el tráfico por defecto le salga por ahí, en base a lo que explica en el mensaje inicial. O no sabrá hacerlo para que use las dos.

Yo tengo montado un sistema de balanceo y failover con ECMP (dos rutas de salida con misma métrica y monitorizadas con ping a servidor en Internet) y si algo quiero que se vaya por algún lado (como por ejemplo las IPs a las que hago ping) le pongo una ruta específica. Me pregunto si @dnight sabe (y si le interesa) que se puede montar una cosa así, tener una conexión a internet de backup está bien pero se le puede sacar más provecho por lo general.

🗨️ 1
dnight

Hola,

En efecto, tengo el check-gateway=ping para hacer que el router detecte cuando la conexión caiga y pase al otro enlace.

La persona responsable del equipo no quiere usar WAN2 de momento para su tráfico diario, solo en caso de que WAN1 caiga ya que tiene mejor enrutamiento por este enlace. Está muy bien el ECMP. Voy a probarlo en un futuro.

Ya tengo una ruta estática a la IP que resuelve cloud2.mikrotik.com y funciona perfectamente pero me gustaría entender la razón por la que no se aplica la marca de enrutamiento en el chain output.

Saludos.