Multivan e enrutamento en Mikrotik RouterOS

Introdución

Asumir o artigo, ademais da vaidade, foi motivado pola frecuencia deprimente de preguntas sobre este tema nos grupos de perfil da comunidade de telegramas de fala rusa. O artigo está dirixido a administradores novatos de Mikrotik RouterOS (en diante ROS). Trata só do multivan, con énfase na ruta. Como extra, hai configuracións mínimamente suficientes para garantir un funcionamento seguro e cómodo. Aqueles que buscan a divulgación dos temas de colas, equilibrio de carga, vlans, pontes, análise profunda en varias etapas do estado da canle e similares, poden non perder tempo e esforzo na lectura.

Datos iniciais

Como tema de proba, seleccionouse un enrutador Mikrotik de cinco portos con versión ROS 6.45.3. Encaminará o tráfico entre dúas redes locais (LAN1 e LAN2) e tres provedores (ISP1, ISP2, ISP3). A canle para ISP1 ten un enderezo "gris" estático, ISP2 - "branco", obtido a través de DHCP, ISP3 - "branco" con autorización PPPoE. O diagrama de conexión móstrase na figura:

Multivan e enrutamento en Mikrotik RouterOS

A tarefa é configurar o router MTK en función do esquema para que:

  1. Proporciona o cambio automático a un provedor de backup. O provedor principal é ISP2, a primeira reserva é ISP1, a segunda reserva é ISP3.
  2. Organice o acceso á rede LAN1 só a través do ISP1.
  3. Proporcione a capacidade de enrutar o tráfico das redes locais a Internet a través do provedor seleccionado en función da lista de enderezos.
  4. Ofrecer a posibilidade de publicar servizos desde a rede local a Internet (DSTNAT)
  5. Configure un filtro de firewall para proporcionar a seguridade mínima suficiente desde Internet.
  6. O router podería emitir o seu propio tráfico a través de calquera dos tres provedores, dependendo do enderezo de orixe seleccionado.
  7. Asegúrese de que os paquetes de resposta se encamiñan á canle da que proviñan (incluída a LAN).

Observación Configuraremos o enrutador “desde cero” para garantir a ausencia de sorpresas nas configuracións de partida “fóra da caixa” que cambien de versión en versión. Elixiuse Winbox como ferramenta de configuración, onde os cambios se mostrarán visualmente. A propia configuración establecerase mediante comandos no terminal Winbox. A conexión física para a configuración realízase mediante unha conexión directa á interface Ether5.

Un pouco de razoamento sobre o que é un multivan, é un problema ou son persoas intelixentes astutas que tecen redes de conspiración

Un administrador curioso e atento, configurando tal ou un esquema por si mesmo, de súpeto dáse conta de que xa funciona normalmente. Si, si, sen as túas táboas de enrutamento personalizadas e outras regras de ruta, das que están cheos a maioría dos artigos sobre este tema. Imos comprobar?

Podemos configurar o enderezo en interfaces e pasarelas predeterminadas? Si:

No ISP1, rexistráronse o enderezo e a pasarela distancia = 2 и check-gateway=ping.
No ISP2, a configuración predeterminada do cliente dhcp; en consecuencia, a distancia será igual a un.
No ISP3 na configuración do cliente pppoe cando add-default-route=si poñer distancia-ruta-predeterminada=3.

Non esquezas rexistrar a NAT na saída:

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

Como resultado, os usuarios de sitios locais divírtense descargando gatos a través do provedor principal ISP2 e hai unha reserva de canles mediante o mecanismo comprobar a pasarela Ver nota 1

Implícase o punto 1 da tarefa. Onde está o multivan coas súas marcas? Non…

Ademais. Debe liberar clientes específicos da LAN a través do ISP1:

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

Implementáronse os puntos 2 e 3 da tarefa. Etiquetas, selos, regras de ruta, onde estás?

Necesitas dar acceso ao teu servidor OpenVPN favorito co enderezo 172.17.17.17 para clientes de Internet? Por favor:

/ip cloud set ddns-enabled=si

Como compañeiro, dámoslle ao cliente o resultado de saída: ":put [IP cloud get dns-name]"

Rexistramos o reenvío de portos desde Internet:

/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=Protocolo WAN=Enderezos-udp=172.17.17.17

O elemento 4 está listo.

Instalamos un cortalumes e outras de seguridade para o punto 5, ao tempo que estamos contentos de que xa todo funcione para os usuarios e cheguemos a un recipiente cunha bebida favorita...
A! Os túneles son esquecidos.

l2tp-client, configurado polo artigo de Google, pasou ao teu VDS holandés favorito? Si.
O servidor l2tp con IPsec aumentou e os clientes por nome DNS de IP Cloud (ver arriba). Si.
Recostados na cadeira, tomando un trago, consideramos con preguiza os puntos 6 e 7 da tarefa. Pensamos que o necesitamos? De todos os xeitos, funciona así (c)... Entón, se aínda non é necesario, xa está. Multivan implementado.

Que é un multivan? Esta é a conexión de varias canles de Internet a un enrutador.

Non tes que ler máis o artigo, porque que pode haber alí ademais de mostrar unha dubidosa aplicabilidade?

Para os que quedan, que estean interesados ​​nos puntos 6 e 7 da tarefa, e tamén sintan a coceira do perfeccionismo, mergullámonos máis.

A tarefa máis importante de implementar unha multivan é a correcta ruta do tráfico. A saber: independentemente de cal (ou cal) Ver. nota 3 a(s) canle(s) do ISP mira a ruta predeterminada do noso enrutador, debería devolver unha resposta á canle exacta da que procedeu o paquete. A tarefa está clara. Onde está o problema? De feito, nunha rede local simple, a tarefa é a mesma, pero ninguén se molesta con configuracións adicionais e non sente problemas. A diferenza é que calquera nodo enrutable en Internet é accesible a través de cada unha das nosas canles, e non a través dun estritamente específico, como nunha simple LAN. E o "problema" é que se nos chegou unha solicitude para o enderezo IP de ISP3, entón no noso caso a resposta pasará pola canle ISP2, xa que a pasarela predeterminada está dirixida alí. Abandona e será descartado polo provedor como incorrecto. Identificouse o problema. Como resolvelo?

A solución divídese en tres etapas:

  1. Predefinición. Nesta fase, estableceranse a configuración básica do router: rede local, firewall, listas de enderezos, NAT de horquilla, etc.
  2. Multivan. Nesta fase, as conexións necesarias marcaranse e ordenaranse en táboas de enrutamento.
  3. Conectando a un ISP. Nesta fase configuraranse as interfaces que proporcionan conexión a Internet, o enrutamento e activarase o mecanismo de reserva de canles de Internet.

1. Preselección

1.1. Borramos a configuración do router co comando:

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

de acordo con "Perigoso! Restablecer de todos os xeitos? [i/N]:” e, despois de reiniciar, conectámonos con Winbox vía MAC. Nesta fase, borraranse a configuración e a base de usuarios.

1.2. Crear un novo usuario:

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

inicia sesión baixo el e elimina o predeterminado:

/user remove admin

Observación É a eliminación e non desactivación do usuario predeterminado o que o autor considera máis seguro e recomenda para o seu uso.

1.3. Creamos listas de interfaces básicas para a comodidade de operar nun firewall, configuracións de descubrimento e outros servidores MAC:

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

Interfaces de sinatura 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"

e enche as 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 Escribir comentarios comprensibles paga a pena o tempo dedicado a isto, ademais de facilitar moito a resolución de problemas e a comprensión da configuración.

O autor considera necesario, por razóns de seguridade, engadir a interface ether3 á lista de interfaces "WAN", a pesar de que o protocolo ip non pasará por ela.

Non esquezas que despois de que a interface PPP se levante en ether3, tamén terá que engadirse á lista de interfaces "WAN"

1.4. Ocultamos o enrutador da detección e control de barrios das redes de provedores 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=LAN

1.5. Creamos o conxunto mínimo suficiente de regras de filtro de firewall para protexer o router:

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

(a regra proporciona permiso para conexións establecidas e relacionadas que se inician tanto desde redes conectadas como desde o propio enrutador)

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

(ping e non só ping. Todos os icmp están permitidos. Moi útil para atopar problemas de MTU)

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

(a regra que pecha a cadea de entrada prohibe todo o que veña de Internet)

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

(a regra permite conexións establecidas e relacionadas que pasan polo router)

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

(a regra restablece as conexións con connection-state=non válido que pasa polo enrutador. É moi recomendable por Mikrotik, pero nalgunhas situacións raras pode bloquear o 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

(a regra prohibe que os paquetes que proveñan de Internet e non pasaron polo procedemento dstnat pasen polo router. Isto protexerá as redes locais dos intrusos que, estando no mesmo dominio de difusión coas nosas redes externas, rexistrarán as nosas IP externas como un pasarela e, así, tentar "explorar" as nosas redes locais).

Observación Supoñamos que as redes LAN1 e LAN2 son de confianza e non se filtra o tráfico entre elas e desde elas.

1.6. Crea unha lista cunha lista de redes non 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 é unha lista de enderezos e redes que non se poden enrutar a Internet e seguiranse en consecuencia.)

Observación A lista está suxeita a cambios, polo que aconsello que comprobe periódicamente a relevancia.

1.7. Configure o DNS para o propio router:

/ip dns set servers=1.1.1.1,8.8.8.8

Observación Na versión actual de ROS, os servidores dinámicos teñen prioridade sobre os estáticos. A solicitude de resolución de nomes envíase ao primeiro servidor por orde na lista. A transición ao seguinte servidor realízase cando o actual non está dispoñible. O tempo de espera é grande: máis de 5 segundos. A volta, cando se retoma o "servidor caído", non se produce automaticamente. Dado este algoritmo e a presenza dunha multivan, o autor recomenda non utilizar servidores proporcionados polos provedores.

1.8. Configurar unha rede local.
1.8.1. Configuramos enderezos IP estáticos en 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 as regras para as rutas ás nosas redes locais a través da táboa de enrutamento 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 é unha das formas rápidas e sinxelas de acceder a enderezos LAN con fontes de enderezos IP externos de interfaces de enrutador que non pasan pola ruta predeterminada.

1.8.3. Activar Hairpin NAT para LAN1 e 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 Isto permítelle acceder aos seus recursos (dstnat) a través dunha IP externa mentres está dentro da rede.

2. En realidade, a implantación do multivan moi correcto

Para resolver o problema de "responder de onde preguntaron", utilizaremos dúas ferramentas ROS: marca de conexión и marca de ruta. marca de conexión permítelle marcar a conexión desexada e logo traballar con esta etiqueta como condición para a solicitude marca de ruta. E xa con marca de ruta posible traballar ruta ip и regras de ruta. Descubrimos as ferramentas, agora tes que decidir que conexións marcar - unha vez, exactamente onde marcar - dúas.

Co primeiro, todo é sinxelo: debemos marcar todas as conexións que chegan ao router desde Internet a través da canle adecuada. No noso caso, serán tres etiquetas (polo número de canles): “conn_isp1”, “conn_isp2” e “conn_isp3”.

O matiz co segundo é que as conexións entrantes serán de dous tipos: de tránsito e as que están destinadas ao propio enrutador. O mecanismo de marca de conexión funciona na táboa mangle. Considere o movemento do paquete nun diagrama simplificado, xentilmente compilado polos especialistas do recurso mikrotik-trainings.com (non publicitario):

Multivan e enrutamento en Mikrotik RouterOS

Seguindo as frechas, vemos que o paquete que chega a "interface de entrada", pasa pola cadea "Enrutamento previo" e só entón divídese en tránsito e local no bloque "Decisión de ruta". Polo tanto, para matar dous paxaros dun tiro, usamos Marca de conexión na táboa Mangle Pre-routing cadeas Enrutamento previo.

Comentario. En ROS, as etiquetas "Routing mark" aparecen como "Táboa" na sección Ip/Routes/Rules, e como "Routing Mark" noutras seccións. Isto pode introducir algunha confusión na comprensión, pero, de feito, isto é o mesmo, e é un análogo de rt_tables en iproute2 en Linux.

2.1. Marcamos as conexións entrantes de cada un dos provedores:

/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 non marcar as conexións xa marcadas, uso a condición connection-mark=no-mark no canto de connection-state=new porque creo que isto é máis correcto, así como o rexeitamento de eliminar conexións non válidas no filtro de entrada.


passthrough=non - porque neste método de implementación, a remarcación está excluída e, para acelerar, pode interromper a enumeración de regras despois da primeira coincidencia.

Hai que ter en conta que aínda non interferimos de ningún xeito co enrutamento. Agora só quedan etapas de preparación. A seguinte fase de implantación será o procesamento do tráfico de tránsito que regrese pola conexión establecida desde o destino na rede local. Eses. eses paquetes que (ver o diagrama) pasaron polo router ao longo do camiño:

"Interface de entrada" => "Enrutamento previo" => "Decisión de enrutamento" => "Reenviar" => "Enrutamento posterior" => "Interface de saída" e chegou ao seu destinatario na rede local.

Importante! En ROS, non hai división lóxica en interfaces externas e internas. Se trazamos o camiño do paquete de resposta segundo o diagrama anterior, seguirá o mesmo camiño lóxico que a solicitude:

"Interface de entrada" => "Enrutamento previo" => "Decisión de enrutamento" => "Reenviar" => "Enrutamento posterior" => "Interface de saída" só por unha petición"interface de entrada” foi a interface do ISP, e para a resposta - LAN

2.2. Diriximos o tráfico de tránsito de resposta ás táboas de enrutamento correspondentes:

/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

Comenta. in-interface-list=!WAN - traballamos só co tráfico da rede local e dst-address-type=!local que non ten o enderezo de destino do enderezo das interfaces do propio router.

O mesmo para os paquetes locais que chegaron ao router no camiño:

"Interface de entrada" => "Enrutamento previo" => "Decisión de enrutamento" => "Entrada" => "Proceso local"

Importante! A resposta será do seguinte xeito:

"Proceso local" => "Decisión de enrutamento" => "Saída" => "Enrutamento posterior" => "Interface de saída"

2.3. Diriximos o tráfico local de resposta ás táboas de enrutamento correspondentes:

/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

Nesta fase pódese considerar resolta a tarefa de preparar o envío dunha resposta á canle de Internet da que procedía a solicitude. Todo está marcado, rotulado e listo para ser enrutado.
Un excelente efecto "colateral" desta configuración é a capacidade de traballar co reenvío de portos DSNAT de ambos provedores (ISP2 e ISP3) ao mesmo tempo. En absoluto, xa que no ISP1 temos un enderezo non enrutable. Este efecto é importante, por exemplo, para un servidor de correo con dous MX que miran diferentes canles de Internet.

Para eliminar os matices do funcionamento das redes locais con enrutadores IP externos, usamos as solucións dos parágrafos. 1.8.2 e 3.1.2.6.

Ademais, podes utilizar unha ferramenta con marcas para resolver o parágrafo 3 do problema. Implementámolo así:

2.4. Diriximos o tráfico dos clientes locais desde as listas de enrutamento ás táboas apropiadas:

/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

Como resultado, parece algo así:

Multivan e enrutamento en Mikrotik RouterOS

3. Configure unha conexión co ISP e active o enrutamento de marca

3.1. Configura unha conexión co ISP1:
3.1.1. Configure un enderezo IP estático:

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

3.1.2. Configurar o enrutamento estático:
3.1.2.1. Engade unha ruta de "emerxencia" predeterminada:

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

Observación Esta ruta permite que o tráfico dos procesos locais pase a fase de decisión de ruta, independentemente do estado das ligazóns de calquera dos provedores. O matiz do tráfico local saínte é que para que o paquete se mova polo menos a algún lugar, a táboa de enrutamento principal debe ter unha ruta activa ata a pasarela predeterminada. Se non, entón o paquete simplemente será destruído.

Como extensión de ferramenta comprobar a pasarela Para unha análise máis profunda do estado da canle, suxiro usar o método de rutas recursivas. A esencia do método é que lle dicimos ao router que busque un camiño para a súa pasarela non directamente, senón a través dunha pasarela intermedia. 4.2.2.1, 4.2.2.2 e 4.2.2.3 elixiranse como pasarelas de "proba" para ISP1, ISP2 e ISP3 respectivamente.

3.1.2.2. Ruta ata o enderezo 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 Reducimos o valor de alcance ao valor predeterminado no ámbito de destino de ROS para poder usar 4.2.2.1 como pasarela recursiva no futuro. Subliño: o alcance da ruta ata o enderezo de "proba" debe ser inferior ou igual ao alcance obxectivo da ruta que se referirá ao de proba.

3.1.2.3. Ruta predeterminada recursiva para o tráfico sen marca de encamiñamento:

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

Observación O valor de distancia=2 úsase porque ISP1 declárase como a primeira copia de seguridade segundo as condicións da tarefa.

3.1.2.4. Ruta predeterminada recursiva para o tráfico coa marca de enrutamento "to_isp1":

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

Observación En realidade, aquí estamos por fin comezando a gozar dos froitos do traballo preparatorio que se levou a cabo no parágrafo 2.


Nesta ruta, todo o tráfico que teña a ruta marcada "to_isp1" dirixirase á pasarela do primeiro provedor, independentemente da pasarela predeterminada que estea activa actualmente para a táboa principal.

3.1.2.5. Primeira ruta predeterminada recursiva alternativa para o 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_isp3

Observación Estas rutas son necesarias, entre outras cousas, para reservar tráfico das redes locais que son membros da lista de enderezos “to_isp*”'

3.1.2.6. Rexistramos a ruta para o tráfico local do router a Internet a través do 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 coas regras do parágrafo 1.8.2, proporciona acceso á canle desexada cunha fonte determinada. Isto é fundamental para construír túneles que especifiquen o enderezo IP local (EoIP, IP-IP, GRE). Dado que as regras das regras de ruta ip execútanse de arriba a abaixo, ata a primeira coincidencia das condicións, esta regra debería estar despois das regras da cláusula 1.8.2.

3.1.3. Rexistramos a regra NAT para o tráfico de saída:

/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 NATim todo o que sae, agás o que entra nas políticas IPsec. Intento non usar action=masquerade a non ser que sexa absolutamente necesario. É máis lento e consume máis recursos que src-nat porque calcula o enderezo NAT para cada conexión nova.

3.1.4. Enviamos os clientes da lista aos que se lles prohibe o acceso a través doutros provedores directamente á pasarela do provedor 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 ten unha prioridade máis alta e aplícase antes que outras regras de enrutamento.


place-before=0 - coloca a nosa regra primeiro na lista.

3.2. Configura unha conexión co ISP2.

Dado que o fornecedor ISP2 ofrécenos a configuración a través de DHCP, é razoable facer os cambios necesarios cun script que se inicia cando se activa o 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

O propio script na xanela de Winbox:

Multivan e enrutamento en Mikrotik RouterOS
Observación A primeira parte do script desenvólvese cando se obtén con éxito o contrato de arrendamento, a segunda, despois de que se libera o arrendamento.Ver nota 2

3.3. Configuramos unha conexión co provedor ISP3.

Dado que o fornecedor de configuración dános dinámica, é razoable facer os cambios necesarios con scripts que se inician despois de que se levantou a interface ppp e despois da caída.

3.3.1. Primeiro configuramos o 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"

O propio script na xanela de Winbox:

Multivan e enrutamento en Mikrotik RouterOS
Observación Liña
/ip firewall mangle set [find comment="Connmark in from ISP3"] in-interface = $"interface";
permite xestionar correctamente o cambio de nome da interface, xa que funciona co seu código e non co nome de visualización.

3.3.2. Agora, usando o perfil, crea unha 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 toque final, imos configurar o reloxo:

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

Para os que len ata o final

A forma proposta de implementar un multivan é a preferencia persoal do autor e non é a única posible. O kit de ferramentas ROS é amplo e flexible, o que, por unha banda, causa dificultades para os principiantes e, por outra banda, é o motivo da súa popularidade. Aprende, proba, descubre novas ferramentas e solucións. Por exemplo, como aplicación dos coñecementos adquiridos, é posible substituír a ferramenta nesta implantación do multivan pasarela de verificación con rutas recursivas para netwatch.

Notas

  1. pasarela de verificación - un mecanismo que permite desactivar a ruta despois de dúas comprobacións consecutivas sen éxito da pasarela para a dispoñibilidade. A comprobación realízase unha vez cada 10 segundos, máis o tempo de espera de resposta. En total, o tempo de conmutación real sitúase no intervalo de 20-30 segundos. Se tal tempo de conmutación non é suficiente, hai unha opción para usar a ferramenta netwatch, onde o temporizador de verificación pódese configurar manualmente. Mecanismo pasarela de verificación non se dispara pola perda intermitente de paquetes na ligazón.

    Importante! A desactivación dunha ruta principal desactivará todas as outras rutas que se refiran a ela. Polo tanto, para que especifiquen check-gateway=ping non é necesario.

  2. Ocorre que se produce un fallo no mecanismo DHCP, que parece un cliente atascado no estado de renovación. Neste caso, a segunda parte do script non funcionará, pero non impedirá que o tráfico camiñe correctamente, xa que o estado rastrexa a ruta recursiva correspondente.
  3. ECMP (multi-ruta de custo igual) - en ROS é posible establecer unha ruta con varias pasarelas e a mesma distancia. Neste caso, as conexións distribuiranse entre canles mediante o algoritmo round robin, en proporción ao número de pasarelas especificadas.

Para o impulso para escribir o artigo, axúdalle a configurar a súa estrutura e colocación de acentos - gratitude persoal a Evgeny @jscar

Fonte: www.habr.com