introducción
Retomar el artículo, además de la vanidad, fue motivado por la deprimente frecuencia de preguntas sobre este tema en los grupos de perfil de la comunidad de telegramas de habla rusa. El artículo está dirigido a los administradores novatos de Mikrotik RouterOS (en lo sucesivo, ROS). Se trata solo de la multivan, con énfasis en el enrutamiento. Como beneficio adicional, hay configuraciones mínimas suficientes para garantizar una operación segura y conveniente. Aquellos que buscan la divulgación de los temas de colas, balanceo de carga, vlans, puentes, análisis profundo de múltiples etapas del estado del canal y similares, no pueden perder tiempo y esfuerzo leyendo.
Datos iniciales
Como sujeto de prueba, se seleccionó un enrutador Mikrotik de cinco puertos con ROS versión 6.45.3. Enrutará el tráfico entre dos redes locales (LAN1 y LAN2) y tres proveedores (ISP1, ISP2, ISP3). El canal a ISP1 tiene una dirección "gris" estática, ISP2 - "blanco", obtenido a través de DHCP, ISP3 - "blanco" con autorización PPPoE. El diagrama de conexión se muestra en la figura:
La tarea es configurar el enrutador MTK según el esquema para que:
- Proporcione el cambio automático a un proveedor de respaldo. El proveedor principal es ISP2, la primera reserva es ISP1, la segunda reserva es ISP3.
- Organice el acceso de red LAN1 a Internet solo a través de ISP1.
- Proporcione la capacidad de enrutar el tráfico desde las redes locales a Internet a través del proveedor seleccionado en función de la lista de direcciones.
- Prever la posibilidad de publicar servicios desde la red local a Internet (DSTNAT)
- Configure un filtro de cortafuegos para proporcionar la seguridad mínima suficiente desde Internet.
- El enrutador podría emitir su propio tráfico a través de cualquiera de los tres proveedores, según la dirección de origen seleccionada.
- Asegúrese de que los paquetes de respuesta se enruten al canal del que provienen (incluida la LAN).
Observación Configuraremos el router “desde cero” para garantizar la ausencia de sorpresas en las configuraciones de partida “out of the box” que cambian de versión a versión. Se eligió Winbox como herramienta de configuración, donde los cambios se mostrarán visualmente. La configuración en sí se establecerá mediante comandos en el terminal Winbox. La conexión física para la configuración se realiza mediante una conexión directa a la interfaz Ether5.
Un poco de razonamiento sobre lo que es un multivan, es un problema o son personas inteligentes y astutas que tejen redes de conspiración.
Un administrador inquisitivo y atento, que configura un esquema tal o similar por su cuenta, de repente se da cuenta de que ya está funcionando normalmente. Sí, sí, sin sus tablas de enrutamiento personalizadas y otras reglas de ruta, de las que están llenos la mayoría de los artículos sobre este tema. ¿Vamos a revisar?
¿Podemos configurar el direccionamiento en las interfaces y las puertas de enlace predeterminadas? Sí:
En ISP1, la dirección y la puerta de enlace se registraron con distancia = 2 и comprobar-puerta de enlace = ping.
En ISP2, la configuración predeterminada del cliente dhcp; en consecuencia, la distancia será igual a uno.
En ISP3 en la configuración del cliente pppoe cuando agregar-default-route=sí poner ruta-distancia-predeterminada=3.
No olvides registrar NAT a la salida:
/ip firewall nat agregar acción=cadena de mascarada=srcnat out-interface-list=WAN
Como resultado, los usuarios de sitios locales se divierten descargando gatos a través del proveedor principal de ISP2 y hay una reserva de canal usando el mecanismo. comprobar la puerta de enlace Ver nota 1
Se implementa el punto 1 de la tarea. ¿Dónde está el multivan con sus marcas? No…
Más. Debe liberar clientes específicos de la LAN a través de ISP1:
/ip firewall mangle agregar acción=cadena de ruta=preenrutamiento dst-address-list=!BOGONS
paso a través = sí ruta-dst = 100.66.66.1 src-address-list = Via_ISP1
/ip firewall mangle agregar acción=cadena de ruta=preenrutamiento dst-address-list=!BOGONS
paso a través = sin ruta-dst = 100.66.66.1 dirección-src = 192.168.88.0/24
Se han implementado los elementos 2 y 3 de la tarea. Etiquetas, sellos, reglas de ruta, ¿dónde estás?
¿Necesita dar acceso a su servidor OpenVPN favorito con la dirección 172.17.17.17 para clientes de Internet? Por favor:
/IP nube establecida ddns-enabled=sí
Como pares, le damos al cliente el resultado de salida: “:poner [nube de ip obtener nombre-dns]"
Registramos el reenvío de puertos desde Internet:
/ip firewall nat agregar acción = dst-nat cadena = dstnat dst-port = 1194
en-interface-list=WAN protocol=udp to-addresses=172.17.17.17
El artículo 4 está listo.
Configuramos un firewall y otra seguridad para el punto 5, al mismo tiempo nos alegramos de que todo ya esté funcionando para los usuarios y busquemos un recipiente con una bebida favorita...
¡A! Los túneles se olvidan.
l2tp-client, configurado por el artículo de Google, se ha convertido en su VDS holandés favorito. Sí.
¿El servidor l2tp con IPsec ha aumentado y los clientes por nombre DNS de IP Cloud (ver arriba) se aferran? Sí.
Reclinados en nuestra silla, tomando un trago, consideramos perezosamente los puntos 6 y 7 de la tarea. Pensamos: ¿lo necesitamos? De todos modos, funciona así (c) ... Entonces, si todavía no es necesario, eso es todo. Multivan implementado.
¿Qué es una multifurgoneta? Esta es la conexión de varios canales de Internet a un enrutador.
No tiene que seguir leyendo el artículo, porque ¿qué puede haber allí además de un alarde de aplicabilidad dudosa?
Para aquellos que se quedan, que están interesados en los puntos 6 y 7 de la tarea, y también sienten la comezón del perfeccionismo, profundizamos más.
La tarea más importante de implementar un multivan es el enrutamiento correcto del tráfico. A saber: independientemente de cuál (o cuál) Ver. nota 3 los canales del ISP miran la ruta predeterminada en nuestro enrutador, debe devolver una respuesta al canal exacto del que proviene el paquete. La tarea es clara. ¿Dónde está el problema? De hecho, en una red local simple, la tarea es la misma, pero nadie se molesta con configuraciones adicionales y no siente problemas. La diferencia es que cualquier nodo enrutable de Internet es accesible a través de cada uno de nuestros canales, y no a través de uno estrictamente específico, como en una simple LAN. Y el "problema" es que si recibimos una solicitud de la dirección IP de ISP3, en nuestro caso la respuesta pasará por el canal ISP2, ya que la puerta de enlace predeterminada se dirige allí. Sale y será descartado por el proveedor como incorrecto. El problema ha sido identificado. ¿Cómo resolverlo?
La solución se divide en tres etapas:
- Preajuste. En esta etapa, se establecerán las configuraciones básicas del enrutador: red local, firewall, listas de direcciones, NAT de horquilla, etc.
- Multivan. En esta etapa, las conexiones necesarias se marcarán y clasificarán en tablas de enrutamiento.
- Conexión a un ISP. En esta etapa se configurarán las interfaces que brindan conexión a Internet, se activará el enrutamiento y el mecanismo de reserva de canales de Internet.
1. Preajuste
1.1. Limpiamos la configuración del router con el comando:
/system reset-configuration skip-backup=yes no-defaults=yesde acuerdo con "¡Peligroso! ¿Reiniciar de todos modos? [t/n]:” y, tras reiniciar, nos conectamos con Winbox vía MAC. En esta etapa, se borran la configuración y la base de usuarios.
1.2. Crear un nuevo usuario:
/user add group=full name=knight password=ultrasecret comment=”Not horse”inicie sesión debajo de él y elimine el predeterminado:
/user remove adminObservación Es la eliminación y no deshabilitación del usuario predeterminado lo que el autor considera más seguro y recomienda para su uso.
1.3. Creamos listas de interfaces básicas para la conveniencia de operar en un 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"Firmar interfaces con comentarios
/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 complete las listas de interfaz:
/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 Escribir comentarios comprensibles vale la pena el tiempo dedicado a esto, además de que facilita enormemente la resolución de problemas y la comprensión de la configuración.
El autor considera necesario, por razones de seguridad, agregar la interfaz ether3 a la lista de interfaces “WAN”, a pesar de que el protocolo ip no la atravesará.
No olvide que después de que se eleve la interfaz PPP en ether3, también deberá agregarse a la lista de interfaces "WAN"
1.4. Ocultamos el enrutador de la detección y el control de la vecindad de las redes de proveedores a través de 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=LAN1.5. Creamos el conjunto mínimo suficiente de reglas de filtro de firewall para proteger el enrutador:
/ip firewall filter add action=accept chain=input comment="Related Established Untracked Allow"
connection-state=established,related,untracked(la regla proporciona permiso para conexiones establecidas y relacionadas que se inician tanto desde las redes conectadas como desde el propio enrutador)
/ip firewall filter add action=accept chain=input comment="ICMP from ALL" protocol=icmp(ping y no solo ping. Todo icmp está permitido. Muy útil para encontrar problemas de MTU)
/ip firewall filter add action=drop chain=input comment="All other WAN Drop" in-interface-list=WAN(la regla que cierra la cadena de entrada prohíbe todo lo demás que venga 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 por el enrutador)
/ip firewall filter add action=drop chain=forward comment="Invalid drop" connection-state=invalid(la regla restablece las conexiones con connection-state=invalid pasando por el enrutador. Mikrotik lo recomienda encarecidamente, pero en algunas situaciones excepcionales puede bloquear el 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 que los paquetes que vienen de Internet y no hayan pasado el procedimiento dstnat pasen por el enrutador. Esto protegerá las redes locales de intrusos que, estando en el mismo dominio de transmisión con nuestras redes externas, registrarán nuestras IP externas como un puerta de enlace y, así, intentar “explorar” nuestras redes locales.)
Observación Supongamos que las redes LAN1 y LAN2 son de confianza y que el tráfico entre ellas y desde ellas no se filtra.
1.6. Cree una lista con una lista de redes no enrutables:
/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 pueden enrutar a Internet y se seguirán en consecuencia).
Observación La lista está sujeta a cambios, por lo que le aconsejo que verifique periódicamente la relevancia.
1.7. Configure el DNS para el propio enrutador:
/ip dns set servers=1.1.1.1,8.8.8.8Observación En la versión actual de ROS, los servidores dinámicos tienen prioridad sobre los estáticos. La solicitud de resolución de nombres se envía al primer servidor en orden en la lista. La transición al siguiente servidor se realiza cuando el actual no está disponible. El tiempo de espera es grande: más de 5 segundos. Volver atrás, cuando se reanuda el "servidor caído", no ocurre automáticamente. Dado este algoritmo y la presencia de una multivan, el autor recomienda no utilizar servidores proporcionados por proveedores.
1.8. Configura una red local.
1.8.1. Configuramos direcciones IP estáticas en las interfaces LAN:
/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 para las rutas a 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 rápidas y fáciles de acceder a las direcciones LAN con fuentes de direcciones IP externas de las interfaces del enrutador que no pasan por la ruta predeterminada.
1.8.3. Habilite 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.0Observación Esto le permite acceder a sus recursos (dstnat) a través de una IP externa mientras está dentro de la red.
2. En realidad, la implementación del multivan muy correcto.
Para solucionar el problema de “responder desde donde preguntan”, utilizaremos dos herramientas ROS: marca de conexión и marca de enrutamiento. marca de conexión le permite marcar la conexión deseada y luego trabajar con esta marca como condición para aplicar marca de enrutamiento. y ya con marca de enrutamiento posible trabajar en ruta ip и reglas de ruta. Descubrimos las herramientas, ahora debe decidir qué conexiones marcar, una vez, exactamente dónde marcar, dos.
Con el primero, todo es simple: debemos marcar todas las conexiones que llegan al enrutador desde Internet a través del canal apropiado. En nuestro caso, serán tres etiquetas (por el número de canales): “conn_isp1”, “conn_isp2” y “conn_isp3”.
El matiz con el segundo es que las conexiones entrantes serán de dos tipos: las de tránsito y las que están destinadas al propio router. El mecanismo de marca de conexión funciona en la mesa. desaparecido. Considere el movimiento del paquete en un diagrama simplificado, compilado amablemente por los especialistas del recurso mikrotik-trainings.com (no publicidad):
Siguiendo las flechas, vemos que el paquete que llega a “entrada interfaz”, pasa por la cadena “Enrutamiento previo” y solo entonces se divide en tránsito y local en el bloque “Decisión de enrutamiento". Por lo tanto, para matar dos pájaros de un tiro, usamos Marca de conexión en la mesa Enrutamiento previo de Mangle cadenas Enrutamiento previo.
Nota. En ROS, las etiquetas de "Marca de enrutamiento" aparecen como "Tabla" en la sección Ip/Routes/Reglas y como "Marca de enrutamiento" en otras secciones. Esto puede introducir cierta confusión en la comprensión, pero, de hecho, esto es lo mismo y es un análogo de 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=noObservación Para no marcar conexiones ya marcadas, utilizo la condición connection-mark=no-mark en lugar de connection-state=new porque creo que esto es más correcto, así como el rechazo de descartar conexiones no válidas en el filtro de entrada.
passthrough=no - porque en este método de implementación, se excluye el remarcado y, para acelerar, puede interrumpir la enumeración de reglas después de la primera coincidencia.
Debe tenerse en cuenta que todavía no interferimos de ninguna manera con el enrutamiento. Ahora solo quedan etapas de preparación. La próxima etapa de implementación será el procesamiento del tráfico de tránsito que regresa sobre la conexión establecida desde el destino en la red local. Aquellos. aquellos paquetes que (ver el diagrama) pasaron a través del enrutador en el camino:
“Interfaz de entrada”=>”Enrutamiento previo”=>”Decisión de enrutamiento”=>”Adelante”=>”Enrutamiento posterior”=>”Interfaz de salida” y llegó a su destinatario en la red local.
¡Importante! En ROS, no existe una división lógica en interfaces externas e internas. Si rastreamos la ruta del paquete de respuesta de acuerdo con el diagrama anterior, seguirá la misma ruta lógica que la solicitud:
“Interfaz de entrada”=>”Enrutamiento previo”=>”Decisión de enrutamiento”=>”Adelante”=>”Enrutamiento posterior”=>”Interfaz de salida” solo por un pedido"Interfaz de entrada” fue la interfaz ISP, y como respuesta - LAN
2.2. Dirigimos el tráfico de tránsito de respuesta a 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=noComentario. in-interface-list=!WAN: trabajamos solo con tráfico de la red local y dst-address-type=!local que no tiene la dirección de destino de la dirección de las interfaces del enrutador.
Lo mismo para los paquetes locales que llegaron al enrutador en el camino:
“Interfaz de entrada”=>”Preenrutamiento”=>”Decisión de enrutamiento”=>”Entrada”=>”Proceso local”
¡Importante! La respuesta irá de la siguiente manera:
”Proceso local”=>”Decisión de enrutamiento”=>”Salida”=>”Enrutamiento posterior”=>”Interfaz de salida”
2.3. Dirigimos el tráfico local de respuesta a 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=noEn esta etapa, la tarea de prepararse para enviar una respuesta al canal de Internet de donde provino la solicitud puede considerarse resuelta. Todo está marcado, etiquetado y listo para ser enrutado.
Un excelente efecto "secundario" de esta configuración es la capacidad de trabajar con el reenvío de puertos DSNAT de ambos proveedores (ISP2, ISP3) al mismo tiempo. En absoluto, ya que en ISP1 tenemos una dirección no enrutable. Este efecto es importante, por ejemplo, para un servidor de correo con dos MX que buscan diferentes canales de Internet.
Para eliminar los matices del funcionamiento de las redes locales con enrutadores IP externos, utilizamos las soluciones de los párrafos. 1.8.2 y 3.1.2.6.
Además, puede usar una herramienta con marcas para resolver el párrafo 3 del problema. Lo implementamos así:
2.4. Dirigimos 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_ISP3Como resultado, se ve algo como esto:
3. Configure una conexión con el ISP y habilite el enrutamiento personalizado
3.1. Configure una conexión a ISP1:
3.1.1. Configure una dirección IP estática:
/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"3.1.2. Configure el enrutamiento estático:
3.1.2.1. Agregue una ruta de "emergencia" predeterminada:
/ip route add comment="Emergency route" distance=254 type=blackholeObservación Esta ruta permite que el tráfico de los procesos locales pase la etapa de Decisión de Ruta, independientemente del estado de los enlaces de cualquiera de los proveedores. El matiz del tráfico local saliente es que para que el paquete se mueva al menos a alguna parte, la tabla de enrutamiento principal debe tener una ruta activa a la puerta de enlace predeterminada. De lo contrario, el paquete simplemente será destruido.
Como extensión de la herramienta comprobar la puerta de enlace Para un análisis más profundo del estado del canal, sugiero usar el método de ruta recursiva. La esencia del método es que le decimos al enrutador que busque una ruta a su puerta de enlace no directamente, sino a través de una puerta de enlace intermedia. 4.2.2.1, 4.2.2.2 y 4.2.2.3 se elegirán como pasarelas de "prueba" para ISP1, ISP2 e ISP3 respectivamente.
3.1.2.2. Ruta a 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=10Observación Bajamos el valor del alcance al valor predeterminado en el alcance de destino de ROS para usar 4.2.2.1 como una puerta de enlace recursiva en el futuro. Recalco: el alcance de la ruta a la dirección de “prueba” debe ser menor o igual al alcance objetivo de la ruta que hará referencia a la de prueba.
3.1.2.3. Ruta predeterminada recursiva para el tráfico sin marca de enrutamiento:
/ip route add comment="Unmarked via ISP1" distance=2 gateway=4.2.2.1Observación El valor de distancia = 2 se usa porque ISP1 se declara como la primera copia de seguridad de acuerdo con las condiciones de la tarea.
3.1.2.4. Ruta predeterminada recursiva para el tráfico con marca de enrutamiento "to_isp1":
/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1
routing-mark=to_isp1Observación En realidad, aquí estamos finalmente comenzando a disfrutar los frutos del trabajo preparatorio que se llevó a cabo en el párrafo 2.
En esta ruta, todo el tráfico que tenga la marca ruta "to_isp1" se dirigirá a la puerta de enlace del primer proveedor, independientemente de qué puerta de enlace predeterminada esté actualmente activa para la tabla principal.
3.1.2.5. Primera ruta predeterminada recursiva alternativa para el tráfico etiquetado ISP2 e 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_isp3Observación Estas rutas son necesarias, entre otras cosas, para reservar tráfico de redes locales que son miembros de la lista de direcciones "to_isp*"'
3.1.2.6. Registramos 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_isp1Observación En combinación con las reglas del párrafo 1.8.2, proporciona acceso al canal deseado con una fuente determinada. Esto es fundamental para construir túneles que especifiquen la dirección IP del lado local (EoIP, IP-IP, GRE). Dado que las reglas en las reglas de ruta IP se ejecutan de arriba a abajo, hasta la primera coincidencia de las condiciones, entonces esta regla debe ser posterior a las reglas de la cláusula 1.8.2.
3.1.3. Registramos 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.2Observación NATim todo lo que sale, excepto lo que entra en las políticas IPsec. Trato de no usar action=masquerade a menos que sea absolutamente necesario. Es más lento y consume más recursos que src-nat porque calcula la dirección NAT para cada nueva conexión.
3.1.4. Enviamos a los clientes de la lista que tienen prohibido acceder a través de otros proveedores directamente a la puerta de enlace 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=0Observación action=route tiene una prioridad más alta y se aplica antes que otras reglas de enrutamiento.
place-before=0 - coloca nuestra regla primero en la lista.
3.2. Configure una conexión a ISP2.
Dado que el proveedor ISP2 nos proporciona la configuración a través de DHCP, es razonable realizar los cambios necesarios con un script que se inicia cuando se activa 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=noEl script en sí mismo en la ventana de Winbox:
Observación La primera parte de la secuencia de comandos se activa cuando se obtiene con éxito el contrato de arrendamiento, la segunda, después de que se libera el contrato de arrendamiento.Ver nota 2
3.3. Configuramos una conexión con el proveedor ISP3.
Dado que el proveedor de configuración nos brinda dinámica, es razonable realizar los cambios necesarios con scripts que se inician después de que se haya levantado la interfaz ppp y después de la caída.
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 sí mismo en la ventana de Winbox:
Observación Cadena
/ip firewall mangle set [find comment="Connmark in from ISP3"] in-interface=$"interface";
le permite manejar correctamente el cambio de nombre de la interfaz, ya que funciona con su código y no con el nombre para mostrar.
3.3.2. Ahora, usando el perfil, crea 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_clientComo toque final, configuremos el reloj:
/system ntp client set enabled=yes server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.orgPara los que leen hasta el final.
La forma propuesta de implementar un multivan es la preferencia personal del autor y no es la única posible. El conjunto de herramientas de ROS es extenso y flexible, lo que, por un lado, causa dificultades para los principiantes y, por otro lado, es la razón de su popularidad. Aprende, prueba, descubre nuevas herramientas y soluciones. Por ejemplo, como aplicación de los conocimientos adquiridos, es posible sustituir la herramienta en esta implementación del multivan verificar-puerta de enlace con rutas recursivas a netwatch.
Notas
- comprobar puerta de enlace - un mecanismo que le permite desactivar la ruta después de dos comprobaciones fallidas consecutivas de disponibilidad de la puerta de enlace. La comprobación se realiza una vez cada 10 segundos, más el tiempo de espera de respuesta. En total, el tiempo de conmutación real se encuentra en el rango de 20 a 30 segundos. Si dicho tiempo de cambio no es suficiente, hay una opción para usar la herramienta netwatch, donde el temporizador de verificación se puede configurar manualmente. comprobar puerta de enlace no se activa ante la pérdida intermitente de paquetes en el enlace.
¡Importante! Al desactivar una ruta principal, se desactivarán todas las demás rutas que hacen referencia a ella. Por lo tanto, para que indiquen comprobar-puerta de enlace = ping no es necesario.
- Sucede que ocurre una falla en el mecanismo DHCP, que parece un cliente atascado en el estado de renovación. En este caso, la segunda parte del script no funcionará, pero no impedirá que el tráfico camine correctamente, ya que el estado rastrea la ruta recursiva correspondiente.
- ECMP (ruta múltiple de igual costo) - en ROS es posible establecer una ruta con varias pasarelas y la misma distancia. En este caso, las conexiones se distribuirán a través de los canales utilizando el algoritmo round robin, en proporción al número de puertas de enlace especificadas.
Por el ímpetu para escribir el artículo, ayudar a dar forma a su estructura y colocación de acentos: agradecimiento personal a Evgeny
Fuente: habr.com