🥇Multipath y enrutamiento en Mikrotik RouterOS

Introducción

La necesidad de abordar este artículo, más allá de la vanidad, fue impulsada por la preocupante frecuencia de preguntas sobre este tema en los grupos especializados de la comunidad de Telegram de habla rusa. Este artículo está dirigido a administradores principiantes de Mikrotik RouterOS (en adelante ROS). Solo se abordará el enrutamiento multi-WAN, con un enfoque específico en esta área. Como bonificación, se presentarán configuraciones mínimas necesarias para garantizar un trabajo seguro y conveniente. Aquellos que busquen un análisis detallado de colas, balanceo de carga, VLAN, puentes, análisis profundo del estado del canal y temas similares — pueden no perder tiempo y esfuerzo leyendo.

Datos de entrada

Como sujeto de prueba, se eligió un enrutador Mikrotik de cinco puertos con ROS versión 6.45.3. Este enrutador dirigirá el tráfico entre dos redes locales (LAN1 y LAN2) y tres proveedores (ISP1, ISP2, ISP3). El canal hacia ISP1 tiene una dirección “gris” estática, ISP2 tiene una dirección “blanca” obtenida a través de DHCP, e ISP3 tiene una dirección “blanca” con autorización PPPoE. El esquema de conexión se presenta en la figura:

La tarea es configurar el enrutador “MTK” según el esquema de forma que:

Asegurar el conmutador automático al proveedor de reserva. El proveedor principal será ISP2, el primer respaldo será ISP1, y el segundo ISP3.
Organizar la salida de la red LAN1 a Internet únicamente a través de ISP1.
Prever la posibilidad de enrutear tráfico de las redes locales a Internet a través del proveedor elegido basado en address-list.
Prever la posibilidad de publicar servicios desde la red local hacia Internet (DSTNAT).
Configurar un filtro de firewall para garantizar una seguridad mínima desde Internet.
El enrutador podrá enviar su propio tráfico a través de cualquiera de los tres proveedores en función de la dirección de origen seleccionada.
Asegurar el enrutamiento de los paquetes de respuesta al canal desde el que llegaron (incluyendo LAN).

Observación. Configuraremos el enrutador 'desde cero' para garantizar la ausencia de sorpresas en las configuraciones iniciales 'de fábrica' que cambian de versión a versión. Como herramienta de configuración se ha elegido Winbox, donde se mostrarán visualmente los cambios. Las configuraciones se introducirán mediante comandos en el terminal de Winbox. La conexión física para la configuración se realizará mediante una conexión directa a la interfaz Ether5.

Algunas reflexiones sobre qué es un multivan, si es un problema o si hay astutos que tejen redes de conspiraciones a su alrededor.

Un administrador curioso y atento, al configurar esta o una esquema similar, de repente se da cuenta de que ya funciona correctamente. Sí, sin esas tablas de enrutamiento personalizadas y otras reglas de enrutamiento que abundan en la mayoría de los artículos sobre este tema. ¿Comprobamos?

¿Podemos configurar la direccionamiento en las interfaces y las puertas de enlace por defecto? Sí:

En ISP1 asignamos la dirección y la puerta de enlace con distance=2 y check-gateway=ping.
En ISP2, la configuración del cliente dhcp por defecto, en consecuencia, la distancia será igual a uno.
En ISP3 en los ajustes del cliente pppoe al add-default-route=yes colocamos default-route-distance=3.

No olvidemos configurar el NAT de salida:

/ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN

Como resultado, los usuarios de las LAN pueden cargar alegremente a través del proveedor principal ISP2 y hay una reserva de canal mediante el mecanismo de check gateway Ver nota 1

El punto 1 de la tarea ha sido realizado. ¿Dónde está el multivan con sus etiquetas? No...

Continuamos. Necesitamos permitir que clientes específicos salgan de la LAN a través de ISP1:

/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=yes route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=no route-dst=100.66.66.1 src-address=192.168.88.0/24

Los puntos 2 y 3 de la tarea han sido realizados. ¿Dónde están las etiquetas, marcas y reglas de enrutamiento?

¿Es necesario dar acceso a nuestro servidor OpenVPN con la dirección 172.17.17.17 para clientes de Internet? Por supuesto:

/ip cloud set ddns-enabled=yes

Proporcionamos a los clientes como par el resultado de la salida: “:put [ip cloud get dns-name]”

Configuramos el reenvío de puerto desde Internet:

/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=WAN protocol=udp to-addresses=172.17.17.17

El punto 4 está listo.

Configuramos el firewall y otras medidas de seguridad para el punto 5, mientras nos alegramos de que todo ya funciona para los usuarios y nos acercamos al recipiente con nuestra bebida favorita...
Ah, ¡también olvidamos los túneles!

¿El cliente l2tp, configurado según un artículo encontrado, se conecta al querido VDS holandés? Sí.
¿El servidor l2tp con IPsec se levantó y los clientes se conectan por nombre DNS desde IP Cloud (ver arriba)? Sí.
Reclinados en la silla, sorbiendo nuestra bebida, examinamos perezosamente los puntos 6 y 7 de la tarea. Pensamos, ¿realmente lo necesitamos? Todo ya funciona (s)... Así que si realmente no es necesario, entonces aquí termina todo. El multivan ha sido implementado.

¿Qué es un multivan? Es la conexión de múltiples canales de Internet a un solo enrutador.

Más allá de este punto, no es necesario seguir leyendo el artículo, ya que ¿qué más podría haber aparte de una exhibición de dudosa aplicabilidad?

Con aquellos que quedaron, quienes están interesados en los puntos 6 y 7 de la tarea, y que también sienten el picor del perfeccionismo, nos sumergimos más a fondo.

La tarea más importante de implementar un multicanal es la correcta ruta del tráfico. Es decir: independientemente de en qué (o en qué) canal(es) de proveedor se mire la ruta por defecto en nuestro enrutador, debe devolver la respuesta precisamente al canal desde el cual llegó el paquete. La tarea está clara. ¿Pero dónde está el problema? Porque en una red local simple, la tarea es la misma, pero nadie se complica con configuraciones adicionales y no siente la dificultad. La diferencia es que cualquier nodo en Internet es accesible a través de cada uno de nuestros canales, y no a través de uno específico, como en una red local simple. Y el “problema” radica en que si recibimos una solicitud a la dirección IP de ISP3, en nuestro caso la respuesta saldrá a través del canal de ISP2, ya que ahí está dirigida la puerta de enlace por defecto. Saldrá y será descartada por el proveedor, como incorrecta. Hemos identificado el problema. ¿Cómo lo resolveremos?

Dividiremos la solución en tres etapas:

Configuración preliminar. En esta etapa se establecerán las configuraciones básicas del enrutador: red local, firewall, listas de direcciones, NAT de hairpin, etc.
Multicanal. En esta etapa se marcarán y clasificarán las conexiones necesarias en las tablas de enrutamiento.
Conexión a ISP. En esta etapa se configurarán las interfaces que permiten la conexión a Internet, se activará el enrutamiento y el mecanismo de reserva de canales de Internet.

1. Configuración preliminar

1.1. Limpia la configuración del enrutador con el comando:

/system reset-configuration skip-backup=yes no-defaults=yes

aceptamos el “¡Peligroso! ¿Restablecer de todos modos? [y/N]:” y, tras reiniciar, nos conectamos con Winbox por MAC. En esta etapa, la configuración y la base de usuarios están limpias.

1.2. Creamos un nuevo usuario:

/user add group=full name=knight password=ultrasecret comment=”Not horse”

iniciamos sesión con él y eliminamos el predeterminado:

/user remove admin

Observación. La eliminación en lugar de la desconexión del usuario predeterminado es considerada por el autor como más segura y se recomienda su uso.

1.3. Creamos listas de interfaces básicas para facilitar la operación en el firewall, configuraciones de descubrimiento y otros servidores MAC:

/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"

Comentar las interfaces

/interface ethernet set ether1 comment="to ISP1"
/interface ethernet set ether2 comment="to ISP2"
/interface ethernet set ether3 comment="to ISP3"
/interface ethernet set ether4 comment="to LAN1"
/interface ethernet set ether5 comment="to LAN2"

y llenar las listas de interfaces:

/interface list member add interface=ether1 list=WAN comment=ISP1
/interface list member add interface=ether2 list=WAN comment=ISP2 
/interface list member add interface=ether3 list=WAN comment="to ISP3"
/interface list member add interface=ether4 list=LAN  comment="LAN1"
/interface list member add interface=ether5 list=LAN  comment="LAN2"

Observación. Es útil dedicar tiempo a escribir comentarios claros, ya que facilita mucho la resolución de problemas y la comprensión de la configuración.

El autor considera necesario, por razones de seguridad, añadir la interfaz ether3 a la lista de interfaces 'WAN', a pesar de que no se usará el protocolo IP a través de ella.

No olvidemos que, una vez que se levante la interfaz PPP en ether3, también será necesario añadirla a la lista de interfaces 'WAN'.

1.4. Ocultamos el router de la detección y gestión desde las redes de los proveedores mediante MAC:

/ip neighbor discovery-settings set discover-interface-list=!WAN
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN

1.5. Creamos un conjunto mínimo de reglas de filtrado del firewall para proteger el router:

/ip firewall filter add action=accept chain=input comment="Related Established Untracked Allow" 
connection-state=established,related,untracked

(la regla permite conexiones establecidas y relacionadas, que son iniciadas tanto desde las redes conectadas como desde el propio router)

/ip firewall filter add action=accept chain=input comment="ICMP from ALL" protocol=icmp

(ping y no solo ping. Se permite todo el ICMP entrante. Muy útil para identificar problemas con MTU)

/ip firewall filter add action=drop chain=input comment="All other WAN Drop" in-interface-list=WAN

(la regla de cierre de la cadena de entrada prohíbe todo lo demás que provenga de Internet)

/ip firewall filter add action=accept chain=forward 
comment="Established, Related, Untracked allow" 
connection-state=established,related,untracked

(la regla permite conexiones establecidas y relacionadas que pasan a través del router)

/ip firewall filter add action=drop chain=forward comment="Invalid drop" connection-state=invalid

(la regla elimina conexiones con connection-state=invalid que pasan a través del router. Se recomienda encarecidamente por Mikrotik, pero en algunas situaciones raras puede bloquear tráfico útil)

/ip firewall filter add action=drop chain=forward comment="Drop all from WAN not DSTNATed"  
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

(la regla prohíbe el paso de paquetes a través del router que provienen de Internet y no han pasado por el procedimiento de dstnat. Esto protegerá las redes locales de atacantes que, estando en el mismo dominio de difusión que nuestras redes externas, intentarían usar nuestras IP externas como puerta de enlace y, así, intentar 'explorar' nuestras redes locales.)

Observación. Asumimos que las redes LAN1 y LAN2 son de confianza y el tráfico entre ellas y desde ellas no se filtra.

1.6. Creamos una lista con las redes no enrutable:

/ip firewall address-list
add address=0.0.0.0/8 comment=""This" Network" list=BOGONS
add address=10.0.0.0/8 comment="Private-Use Networks" list=BOGONS
add address=100.64.0.0/10 comment="Shared Address Space. RFC 6598" list=BOGONS
add address=127.0.0.0/8 comment=Loopback list=BOGONS
add address=169.254.0.0/16 comment="Link Local" list=BOGONS
add address=172.16.0.0/12 comment="Private-Use Networks" list=BOGONS
add address=192.0.0.0/24 comment="IETF Protocol Assignments" list=BOGONS
add address=192.0.2.0/24 comment=TEST-NET-1 list=BOGONS
add address=192.168.0.0/16 comment="Private-Use Networks" list=BOGONS
add address=198.18.0.0/15 comment="Network Interconnect Device Benchmark Testing"
 list=BOGONS
add address=198.51.100.0/24 comment=TEST-NET-2 list=BOGONS
add address=203.0.113.0/24 comment=TEST-NET-3 list=BOGONS
add address=224.0.0.0/4 comment=Multicast list=BOGONS
add address=192.88.99.0/24 comment="6to4 Relay Anycast" list=BOGONS
add address=240.0.0.0/4 comment="Reserved for Future Use" list=BOGONS
add address=255.255.255.255 comment="Limited Broadcast" list=BOGONS

(Esta es una lista de direcciones y redes que no se enrutan a Internet y, por lo tanto, también seguiremos esto.)

Observación. La lista puede cambiar, por lo que recomiendo verificar la actualidad periódicamente.

1.7. Configuramos DNS para el propio router:

/ip dns set servers=1.1.1.1,8.8.8.8

Observación. En la versión actual de ROS, los dinámicos servidores tienen prioridad sobre los asignados estáticamente. La solicitud de resolución de nombre se envía al primer servidor en el orden que aparece en la lista. Se pasa al siguiente servidor en caso de que el actual no esté disponible. El tiempo de espera es alto, más de 5 segundos. No se devuelve automáticamente al reiniciar un 'servidor caído'. Teniendo en cuenta este algoritmo y la disponibilidad de múltiples WAN, el autor recomienda no utilizar los servidores proporcionados por los proveedores.

1.8. Configuramos la red local.
1.8.1. Configuramos direcciones IP estáticas en las interfaces de las redes locales:

/ip address add interface=ether4 address=192.168.88.254/24 comment="LAN1 IP"
/ip address add interface=ether5 address=172.16.1.0/23 comment="LAN2 IP"

1.8.2. Establecemos las reglas de rutas hacia nuestras redes locales a través de la tabla de enrutamiento principal:

/ip route rule add dst-address=192.168.88.0/24 table=main comment=”to LAN1”
/ip route rule add dst-address=172.16.0.0/23 table=main comment="to LAN2"

Observación. Esta es una de las formas simples y rápidas de acceder a las direcciones de las redes locales desde fuentes de direcciones IP externas de las interfaces del enrutador, a través de las cuales no hay ruta por defecto.

1.8.3. Activamos Hairpin NAT para LAN1 y LAN2:

/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN1" 
out-interface=ether4 src-address=192.168.88.0/24 to-addresses=192.168.88.254
/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN2" 
out-interface=ether5 src-address=172.16.0.0/23 to-addresses=172.16.1.0

Observación. Esto permite acceder a nuestros recursos (dstnat) a través de la IP externa, mientras estamos dentro de la red.

2. En realidad, la implementación de ese multitarea correcta.

Para abordar la tarea de 'responder desde donde se preguntó', utilizaremos dos herramientas de ROS: marca de conexión y marca de enrutamiento. La marca de conexión permite marcar la conexión deseada y posteriormente trabajar con esta etiqueta como una condición para aplicar marca de enrutamiento. Y ya con marca de enrutamiento se puede trabajar en ip route y reglas de ruta. Con las herramientas claras, ahora debemos resolver qué conexiones marcar: primero, dónde marcarlas: segundo.

Con el primero es sencillo: debemos marcar todas las conexiones que llegan al enrutador desde Internet a través del canal correspondiente. En nuestro caso, habrá tres etiquetas (según la cantidad de canales): 'conn_isp1', 'conn_isp2' y 'conn_isp3'.

El matiz con el segundo consiste en que las conexiones entrantes serán de dos tipos: de tránsito y aquellas destinadas al propio enrutador. El mecanismo de marca de conexión funciona en la tabla mangle. Consideremos el movimiento del paquete en un diagrama simplificado, amablemente elaborado por especialistas del recurso mikrotik-trainings.com (no es publicidad):

Siguiendo las flechas, vemos que el paquete que llega a 'input interface', pasa por la cadena 'Prerouting' y solo luego se divide en tránsito y local en el bloque 'Routing Decision'. Por lo tanto, para matar dos pájaros de un tiro, utilizamos Connection Mark en la tabla Mangle Prerouting de la cadena Prerouting.

Nota. En ROS, las etiquetas "Routing mark" se indican en la sección Ip/Routes/Rules como "Table", y en otras secciones como "Routing Mark". Esto puede causar cierta confusión en la comprensión, pero en esencia, es lo mismo y es análogo a rt_tables en iproute2 en Linux.

2.1. Marcamos las conexiones entrantes de cada uno de los proveedores:

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP1" connection-mark=no-mark in-interface=ether1  new-connection-mark=conn_isp1 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP2" connection-mark=no-mark in-interface=ether2  new-connection-mark=conn_isp2 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP3" connection-mark=no-mark in-interface=pppoe-isp3  new-connection-mark=conn_isp3 passthrough=no

Observación. Para no marcar conexiones ya marcadas, utilizo la condición connection-mark=no-mark en lugar de connection-state=new, porque creo que es más correcto, al igual que la exclusión de conexiones drop invalid en el filtro input.

passthrough=no — porque en este método de implementación, la remarcación está excluida y para agilizar se puede interrumpir la búsqueda de reglas después de la primera coincidencia.

Se debe tener en cuenta que por ahora no intervenimos en la routificación. En este momento solo se están llevando a cabo las etapas de preparación. La siguiente etapa de implementación será el procesamiento del tráfico de tránsito, que regresa a través de una conexión establecida desde el destinatario en la red local. Es decir, de aquellos paquetes que (ver diagrama) pasaron por el enrutador en el camino:

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Forward"=>"Post Routing"=>"Output Interface" y llegaron a su destinatario en la red local.

¡Importante! En ROS no hay una división lógica entre interfaces externas e internas. Si seguimos el camino del paquete de respuesta en el diagrama proporcionado, pasará por la misma ruta lógica que la solicitud:

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Forward"=>"Post Routing"=>"Output Interface" simplemente, para la solicitud "Input Interface" la interfaz ISP fue, mientras que para la respuesta fue LAN.

2.2. Direccionamos el tráfico de tránsito de respuesta a través de las tablas de enrutamiento correspondientes:

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP1" connection-mark=conn_isp1 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP2" connection-mark=conn_isp2 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP3" connection-mark=conn_isp3 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp3 passthrough=no

Nota. in-interface-list=!WAN — solo trabajamos con tráfico de la red local y dst-address-type=!local que no tiene como destino las direcciones de los interfaces del enrutador.

Lo mismo para los paquetes locales que llegaron al enrutador en el camino:

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Input"=>"Local Process"

¡Importante! La respuesta seguirá el siguiente camino:

"Local Process"=>"Routing Decision"=>"Output"=>"Post Routing"=>"Output Interface"

2.3. Direccionamos el tráfico local de respuesta a través de las tablas de enrutamiento correspondientes:

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP1" connection-mark=conn_isp1 dst-address-type=!local 
new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP2" connection-mark=conn_isp2 dst-address-type=!local 
new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP3" connection-mark=conn_isp3 dst-address-type=!local 
new-routing-mark=to_isp3 passthrough=no

En esta etapa, la tarea de preparación para enviar la respuesta al canal de Internet desde el cual llegó la solicitud se puede considerar resuelta. Todo está marcado, etiquetado y listo para ser enrutado.
Un "efecto secundario" excelente de esta configuración es la posibilidad de realizar el reenvío de puertos DSNAT desde ambos proveedores (ISP2, ISP3) simultáneamente. No en todos, ya que en ISP1 tenemos una dirección no enrutada. Este efecto es importante, por ejemplo, para un servidor de correo con dos MX que miran en diferentes canales de Internet.

Para resolver los matices del funcionamiento de redes locales con IP externas del enrutador, utilizamos soluciones de los puntos 1.8.2 y 3.1.2.6.

Además, se puede emplear una herramienta con etiquetas para abordar el punto 3 de la tarea. Lo implementamos así:

2.4. Enviamos el tráfico de los clientes locales desde las listas de enrutamiento a las tablas correspondientes:

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP1" dst-address-list=!BOGONS new-routing-mark=to_isp1 
passthrough=no src-address-list=Via_ISP1

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP2" dst-address-list=!BOGONS new-routing-mark=to_isp2 
passthrough=no src-address-list=Via_ISP2

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP3" dst-address-list=!BOGONS new-routing-mark=to_isp3 
passthrough=no src-address-list=Via_ISP3

Al final, se ve aproximadamente así:

3. Configuramos la conexión a ISP y utilizamos el enrutamiento basado en marcas.

3.1. Configuramos la conexión a ISP1:
3.1.1. Configuramos la dirección IP estática:

/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"

3.1.2. Configuramos el enrutamiento estático:
3.1.2.1. Agregamos una ruta de "emergencia" por defecto:

/ip route add comment="Emergency route" distance=254 type=blackhole

Observación. Esta ruta permite que el tráfico de los procesos locales pase por la etapa de Decisión de Ruta independientemente del estado de los canales de cualquiera de los proveedores. El matiz del tráfico local saliente es que para que un paquete se mueva a algún lugar, debe haber una ruta activa hacia la puerta de enlace predeterminada en la tabla de enrutamiento principal. Si no hay, el paquete simplemente será destruido.

Como extensión de la herramienta check gateway para un análisis más profundo del estado del canal, sugiero utilizar el método de rutas recursivas. La esencia del método es que indicamos al enrutador que busque un camino hacia su puerta de enlace no directamente, sino a través de una puerta de enlace intermedia. Como tales "puertas de enlace de verificación" se elegirán 4.2.2.1, 4.2.2.2 y 4.2.2.3 respectivamente para ISP1, ISP2 e ISP3.

3.1.2.2. Ruta hacia la dirección "de verificación":

/ip route add check-gateway=ping comment="For recursion via ISP1"  
distance=1 dst-address=4.2.2.1 gateway=100.66.66.1 scope=10

Observación. Bajamos el valor del scope al predeterminado en ROS target scope, para usar más adelante 4.2.2.1 como puerta de enlace recursiva. Subrayo: el scope de la ruta hacia la dirección "de verificación" debe ser menor o igual que el target scope de la ruta que referenciará al verificador.

3.1.2.3. Ruta recursiva por defecto para tráfico sin marca de enrutamiento:

/ip route add comment="Unmarked via ISP1" distance=2 gateway=4.2.2.1

Observación. El valor distance=2 se utiliza porque ISP1, según las condiciones de la tarea, se declara como el primer respaldo.

3.1.2.4. Ruta recursiva por defecto para tráfico con la marca de enrutamiento "to_isp1":

/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1 
routing-mark=to_isp1

Observación. Aquí es donde finalmente comenzamos a aprovechar los frutos del trabajo preparatorio realizado en el punto 2.

Por esta ruta, todo el tráfico que tenga la marca de ruta “to_isp1” será dirigido al gateway del primer proveedor, independientemente de cuál sea actualmente el gateway por defecto para la tabla main.

3.1.2.5. Primera ruta de respaldo recursiva por defecto para el tráfico marcado de los proveedores ISP2 y ISP3:

/ip route add comment="Marked via ISP2 Backup1" distance=2 gateway=4.2.2.1 
routing-mark=to_isp2
/ip route add comment="Marked via ISP3 Backup1" distance=2 gateway=4.2.2.1 
routing-mark=to_isp3

Observación. Estas rutas son necesarias, entre otras cosas, para reservar el tráfico de las redes locales, que son miembros de la lista de direcciones “to_isp*”.

3.1.2.6. Especificamos la ruta para el tráfico local del enrutador a Internet a través de ISP1:

/ip route rule add comment="From ISP1 IP to Inet" src-address=100.66.66.2 table=to_isp1

Observación. En combinación con las reglas del punto 1.8.2, se garantiza la salida al canal deseado con el origen especificado. Esto es crítico para construir túneles, en los cuales se establece la dirección IP del lado local (EoIP, IP-IP, GRE). Dado que las reglas en las políticas de enrutamiento se ejecutan de arriba hacia abajo, hasta que haya una coincidencia de condiciones, esta regla debe estar después de las reglas del punto 1.8.2.

3.1.3. Especificamos la regla NAT para el tráfico saliente:

/ip firewall nat add action=src-nat chain=srcnat comment="NAT via ISP1"  
ipsec-policy=out,none out-interface=ether1 to-addresses=100.66.66.2

Observación. NAT para todo lo saliente, excepto lo que cae bajo las políticas IPsec. Intento no usar action=masquerade a menos que sea absolutamente necesario. Funciona más lento y consume más recursos que src-nat, ya que calcula la dirección para NAT para cada nueva conexión.

3.1.4. Enviamos a los clientes de la lista a los que se les prohíbe salir a través de otros proveedores directamente al gateway del proveedor ISP1.

/ip firewall mangle add action=route chain=prerouting comment="Address List via ISP1 only" 
dst-address-list=!BOGONS passthrough=no route-dst=100.66.66.1 
src-address-list=Via_only_ISP1 place-before=0

Observación. action=route tiene una prioridad más alta y se aplica antes que las demás reglas de enrutamiento.

place-before=0 — coloca nuestra regla primero en la lista.

3.2. Configuramos la conexión a ISP2.

Dado que el proveedor ISP2 nos proporciona configuraciones por DHCP, es razonable hacer los cambios necesarios mediante un script que se active al iniciar el cliente DHCP:

/ip dhcp-client
add add-default-route=no disabled=no interface=ether2 script=":if ($bound=1) do={r
    n    /ip route add check-gateway=ping comment="For recursion via ISP2" distance=1 
           dst-address=4.2.2.2/32 gateway=$"gateway-address" scope=10r
    n    /ip route add comment="Unmarked via ISP2" distance=1 gateway=4.2.2.2;r
    n    /ip route add comment="Marked via ISP2 Main" distance=1 gateway=4.2.2.2 
           routing-mark=to_isp2;r
    n    /ip route add comment="Marked via ISP1 Backup1" distance=2 gateway=4.2.2.2 
           routing-mark=to_isp1;r
    n    /ip route add comment="Marked via ISP3 Backup2" distance=3 gateway=4.2.2.2 
           routing-mark=to_isp3;r
    n    /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none 
           out-interface=$"interface" to-addresses=$"lease-address" comment="NAT via ISP2" 
           place-before=1;r
    n    if ([/ip route rule find comment="From ISP2 IP to Inet"] ="") do={r
    n        /ip route rule add comment="From ISP2 IP to Inet" 
               src-address=$"lease-address" table=to_isp2 r
    n    } else={r
    n       /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=no 
              src-address=$"lease-address"r
    n    }      r
    n} else={r
    n   /ip firewall nat remove  [find comment="NAT via ISP2"];r
    n   /ip route remove [find comment="For recursion via ISP2"];r
    n   /ip route remove [find comment="Unmarked via ISP2"];r
    n   /ip route remove [find comment="Marked via ISP2 Main"];r
    n   /ip route remove [find comment="Marked via ISP1 Backup1"];r
    n   /ip route remove [find comment="Marked via ISP3 Backup2"];r
    n   /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=yesr
    n}r
    n" use-peer-dns=no use-peer-ntp=no

El script en la ventana de Winbox:

Observación. La primera parte del script se ejecuta al recibir correctamente el arrendamiento, la segunda — después de liberar el arrendamiento.Ver nota 2

3.3. Configuramos la conexión al proveedor ISP3.

Dado que el proveedor nos proporciona configuraciones dinámicas, es razonable hacer los cambios necesarios mediante scripts que se inicien después de subir y después de bajar la interfaz ppp.

3.3.1. Primero configuramos el perfil:

/ppp profile
add comment="for PPPoE to ISP3" interface-list=WAN name=isp3_client 
on-down="/ip firewall nat remove  [find comment="NAT via ISP3"];r
    n/ip route remove [find comment="For recursion via ISP3"];r
    n/ip route remove [find comment="Unmarked via ISP3"];r
    n/ip route remove [find comment="Marked via ISP3 Main"];r
    n/ip route remove [find comment="Marked via ISP1 Backup2"];r
    n/ip route remove [find comment="Marked via ISP2 Backup2"];r
    n/ip route rule set [find comment="From ISP3 IP to Inet"] disabled=yes;" 
on-up="/ip route add check-gateway=ping comment="For recursion via ISP3" distance=1 
    dst-address=4.2.2.3/32 gateway=$"remote-address" scope=10r
    n/ip route add comment="Unmarked via ISP3" distance=3 gateway=4.2.2.3;r
    n/ip route add comment="Marked via ISP3 Main" distance=1 gateway=4.2.2.3 
    routing-mark=to_isp3;r
    n/ip route add comment="Marked via ISP1 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp1;r
    n/ip route add comment="Marked via ISP2 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp2;r
    n/ip firewall mangle set [find comment="Connmark in from ISP3"] 
    in-interface=$"interface";r
    n/ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none 
    out-interface=$"interface" to-addresses=$"local-address" comment="NAT via ISP3" 
    place-before=1;r
    nif ([/ip route rule find comment="From ISP3 IP to Inet"] ="") do={r
    n   /ip route rule add comment="From ISP3 IP to Inet" src-address=$"local-address" 
    table=to_isp3 r
    n} else={r
    n   /ip route rule set [find comment="From ISP3 IP to Inet"] disabled=no 
    src-address=$"local-address"r
    n};r
    n"

El script en la ventana de Winbox:

Observación. Cadena
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
permite manejar correctamente el cambio de nombre de la interfaz, ya que trabaja con su código y no con el nombre mostrado.

3.3.2. Ahora, utilizando el perfil, creamos una conexión ppp:

/interface pppoe-client add allow=mschap2 comment="to ISP3" disabled=no 
interface=ether3 name=pppoe-isp3 password=isp3_pass profile=isp3_client user=isp3_client

Como último detalle, configuramos el reloj:

/system ntp client set enabled=yes server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

Para aquellos que han llegado hasta aquí

La forma propuesta de implementar el multipath es una preferencia personal del autor y no es la única opción posible. Las herramientas de ROS son extensas y flexibles, lo que, por un lado, genera complicaciones para los principiantes, pero por otro lado, es la razón de su popularidad. Estudien, prueben, descubran nuevas herramientas y soluciones. Por ejemplo, en esta implementación de multipath, se puede reemplazar la herramienta Check-gateway con rutas recursivas por Netwatch.

Notas

Check-gateway es un mecanismo que permite desactivar una ruta después de dos comprobaciones consecutivas fallidas del acceso al gateway. La verificación se realiza cada 10 segundos, más el tiempo de respuesta. En total, el tiempo real de conmutación está en el rango de 20-30 segundos. Si este tiempo de conmutación no es suficiente, hay una opción de utilizar la herramienta Netwatch, donde el temporizador de verificación se puede establecer manualmente. El mecanismo Check-gateway no se activa ante pérdidas periódicas de paquetes en el canal.
¡Importante! La desactivación de la ruta principal conlleva a la desactivación de todas las demás rutas que dependen de ella. Por lo tanto, para ellas, no es necesario especificar check-gateway=ping .
En ocasiones, el mecanismo DHCP puede fallar, lo que se manifiesta como un cliente atascado en estado de renew. En tal caso, la segunda parte del script no se ejecutará, pero el tráfico seguirá funcionando correctamente, ya que el estado es monitoreado por la ruta recursiva correspondiente.
ECMP (Equal Cost Multi-Path) en ROS permite establecer una ruta con múltiples gateways y la misma distancia. En este caso, las conexiones se distribuirán a través de los canales utilizando un algoritmo de round robin, de manera proporcional al número de gateways especificados.

Agradecimientos por el impulso para escribir este artículo, la ayuda en la formación de su estructura y la distribución de los acentos — agradecimientos personales a Evgeny @jscar

Fuente: habr.com