🥇Multivan e roteamento no Mikrotik RouterOS

Introdução

O desejo de escrever este artigo, além de vaidade, foi provocado pela preocupante frequência de perguntas sobre este tema em grupos especializados da comunidade de Telegram em russo. Este artigo é direcionado a administradores iniciantes do Mikrotik RouterOS (também conhecido como ROS). Ele aborda apenas o Multivan, com foco na roteamento. Como bônus, inclui as configurações mínimas necessárias para garantir um funcionamento seguro e conveniente. Aqueles que buscam aprofundar-se em temas como filas, balanceamento de carga, VLANs, bridges, análises complexas do estado do canal e afins — podem não perder tempo e esforço na leitura.

Dados de origem

Como alvo, escolhemos um roteador Mikrotik de cinco portas com a versão 6.45.3 do ROS. Ele irá rotear o tráfego entre duas redes locais (LAN1 e LAN2) e três provedores (ISP1, ISP2, ISP3). A conexão com o ISP1 tem um endereço 'cinza' estático, o ISP2 tem um 'branco' adquirido via DHCP, e o ISP3 é 'branco' com autenticação PPPoE. O esquema de conexão é apresentado na figura:

A tarefa é configurar o roteador 'MTK' com base no esquema de modo a:

Garantir a comutação automática para o provedor de reserva. O provedor principal é o ISP2, o primeiro de reserva é o ISP1, e o segundo de reserva é o ISP3.
Organizar o acesso da rede LAN1 à Internet somente através do ISP1.
Prever a possibilidade de rotear o tráfego das redes locais para a Internet através do provedor escolhido com base na address-list.
Prever a possibilidade de publicar serviços da rede local na Internet (DSTNAT).
Configurar o filtro de firewall para garantir segurança mínima suficiente do lado da Internet.
O roteador deve ser capaz de emitir seu próprio tráfego através de qualquer um dos três provedores, dependendo do endereço de origem escolhido.
Garantir a roteamento das respostas para o canal de onde elas vieram (incluindo LAN).

Observação. Vamos configurar o roteador 'do zero', para garantir a ausência de surpresas nas configurações iniciais que mudam de versão para versão 'de fábrica'. O Winbox foi escolhido como ferramenta de configuração, onde as mudanças serão exibidas de forma clara. As próprias configurações serão inseridas como comandos no terminal do Winbox. A conexão física para a configuração é realizada por meio de uma conexão direta com a interface Ether5.

Um pouco de reflexão sobre o que é um multipeer, se isso é um problema ou se pessoas astutas estão tecendo redes de conspirações.

Um administrador curioso e atento, ao configurar essa ou uma configuração semelhante, de repente percebe que tudo já funciona bem. Sim, sem essas suas tabelas de roteamento e outras regras de roteamento que abundam na maioria dos artigos sobre o assunto. Vamos verificar?

Podemos configurar a endereçamento nas interfaces e os gateways padrão? Sim:

No ISP1, definimos o endereço e o gateway com distance=2 e check-gateway=ping.
No ISP2, a configuração do cliente DHCP por padrão — portanto, a distância será igual a um.
No ISP3, nas configurações do cliente PPPoE, ao add-default-route=yes definimos como default-route-distance=3.

Não esqueça de configurar o NAT na saída:

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

No final, os usuários das LANs podem acessar normalmente através do provedor principal ISP2 e há redundância de canal utilizando o mecanismo check gateway Veja nota 1.

Tarefa 1 foi implementada. Onde está o multipeer com suas etiquetas? Não...

Avançando. Precisamos liberar clientes específicos da LAN através do 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

As tarefas 2 e 3 foram implementadas. Etiquetas, marcas, regras de roteamento, onde vocês estão?!

Precisamos dar acesso ao nosso amado servidor OpenVPN com o endereço 172.17.17.17 para clientes da Internet? Aqui está:

/ip cloud set ddns-enabled=yes

Damos aos clientes como pares o resultado da saída: “:put [ip cloud get dns-name]”

Configuramos a redireção de porta da 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

Tarefa 4 está concluída.

Vamos configurar o firewall e outras medidas de segurança para a tarefa 5, enquanto nos alegramos que os usuários já estão tudo funcionando e buscamos um recipiente com nossa bebida favorita...
Ah! Esquecemos os túneis.

O cliente L2TP, configurado de acordo com um artigo encontrado, conseguiu se conectar ao nosso amado VDS na Holanda? Sim.
O servidor L2TP com IPsec está em funcionamento e os clientes estão se conectando pelo nome DNS do IP Cloud (veja acima)? Sim.
Reclinado na cadeira, saboreando a bebida, olhamos preguiçosamente as tarefas 6 e 7. Pensamos — será que precisamos disso? Tudo está funcionando bem (c)... Então, se não precisamos, é isso. O multipeer está implementado.

O que é um multipeer? É a conexão de vários canais de Internet a um único roteador.

Depois disso, o artigo pode ser ignorado, pois o que mais pode haver além de exibições de aplicabilidade duvidosa?

Com aqueles que ficaram, que estão interessados nos pontos 6 e 7 da tarefa, e também sentem a necessidade de perfeccionismo, vamos nos aprofundar.

A principal tarefa na implementação do multicanal é a roteação correta do tráfego. Ou seja: independentemente de qual (ou quais) canais do provedor esteja visualizando o caminho padrão no nosso roteador, ele deve retornar a resposta exatamente pelo canal de onde o pacote veio. A tarefa é clara. Onde está o problema? Afinal, em uma simples rede local a tarefa é a mesma, mas ninguém se preocupa com configurações adicionais e não sente dificuldades. A diferença é que qualquer nó roteável na Internet está acessível através de cada um dos nossos canais, e não por um específico, como em uma simples rede local. E o “problema” está no fato de que, se recebemos uma solicitação para o endereço IP ISP3, nossa resposta sairá pelo canal ISP2, uma vez que o gateway padrão está direcionado para lá. Sairá e será descartada pelo provedor, como incorreta. Identificamos o problema. Como resolvê-lo?

Dividiremos a solução em três etapas:

Configuração preliminar. Nesta etapa, serão definidas as configurações básicas do roteador: rede local, firewall, listas de endereços, NAT de hairpin, etc.
Multicanal. Nesta etapa, as conexões necessárias serão marcadas e organizadas nas tabelas de roteamento.
Conexão com o ISP. Nesta etapa, serão configuradas as interfaces que garantem a conexão com a Internet, implementada a roteação e o mecanismo de redundância dos canais da Internet.

1. Configuração preliminar

1.1. Limpar a configuração do roteador com o comando:

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

Aceitaremos “Perigoso! Reiniciar mesmo assim? [y/N]:” e, após a reinicialização, conectaremos pelo Winbox via MAC. Nesta etapa, a configuração e o banco de usuários foram limpos.

1.2. Criar um novo usuário:

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

Fazemos login com ele e removemos o usuário padrão:

/user remove admin

Observação. Remover, em vez de desativar, o usuário padrão é considerado mais seguro pelo autor, que o recomenda.

1.3. Criar listas básicas de interfaces para facilitar a operação no firewall, nas configurações de descoberta e em outros servidores MAC:

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

Assinamos os comentários das 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"

e preenchemos 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"

Observação. Escrever comentários claros vale o tempo gasto, além de facilitar bastante a resolução de problemas e a compreensão da configuração.

O autor considera necessário, por motivos de segurança, adicionar a interface ether3 à lista de interfaces "WAN", apesar de que não haverá tráfego de protocolo IP por ela.

Não nos esquecemos de que, após a ativação da interface PPP em ether3, também será necessário adicioná-la à lista de interfaces "WAN".

1.4. Ocultamos o roteador da detecção de vizinhança e da gestão pelas redes dos provedores utilizando o endereço 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. Criamos o conjunto mínimo necessário de regras de filtragem do firewall para proteger o roteador:

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

(a regra permite conexões estabelecidas e relacionadas, iniciadas tanto a partir das redes conectadas quanto pelo próprio roteador)

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

(ping e não apenas ping. Todo o ICMP de entrada é permitido. Isso é bastante útil para identificar problemas com MTU)

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

(a regra de fechamento da cadeia de entrada proíbe tudo o que chega da Internet)

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

(a regra permite conexões estabelecidas e relacionadas que passam pelo roteador)

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

(a regra descarta conexões com state=invalid que passam pelo roteador. É fortemente recomendada pela Mikrotik, mas em algumas raras situações pode causar o bloqueio de tráfego ú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 proíbe a passagem de pacotes que vêm da Internet e não passaram pelo processo de dstnat. Isso protegerá as redes locais de intrusos que, estando no mesmo domínio de broadcast que nossas redes externas, tentem se infiltrar utilizando nossos IPs externos como gateway e, assim, tentem "explorar" nossas redes locais.)

Observação. Assumimos que as redes LAN1 e LAN2 são confiáveis e o tráfego entre elas não é filtrado.

1.6. Criamos uma lista com a relação de redes não roteáveis:

/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 é uma lista de endereços e redes que não são roteadas para a Internet e, consequentemente, nós também seguiremos isso.)

Observação. A lista pode ser alterada, por isso recomendo verificar periodicamente sua atualidade.

1.7. Configuramos o DNS para o próprio roteador:

/ip dns set servers=1.1.1.1,8.8.8.8

Observação. Na versão atual do ROS, dinâmicas servidores têm prioridade sobre os definidos estaticamente. A solicitação de resolução de nome é enviada ao primeiro servidor na ordem da lista. A transição para o próximo servidor ocorre se o atual estiver inacessível. O timeout é grande — mais de 5 segundos. O retorno automático, ao retomar o funcionamento de um "servidor caído", não ocorre. Com base nesse algoritmo e na presença de múltiplas interfaces, o autor recomenda não utilizar servidores fornecidos pelos provedores.

1.8. Configurando a rede local.
1.8.1. Configurando endereços IP estáticos nas interfaces das redes locais:

/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. Definindo regras de rotas para nossas redes locais através da tabela principal de roteamento:

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

Observação. Este é um dos métodos simples e rápidos para acessar endereços de redes locais usando fontes de endereços IP externos das interfaces do roteador, que não têm rota por padrão.

1.8.3. Ativando 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

Observação. Isso permite acessar seus próprios recursos (dstnat) através do IP externo, estando dentro da rede.

2. De fato, a implementação daquele correto múltiplo

Para resolver a tarefa de "responder de onde perguntaram", usaremos duas ferramentas do ROS: marca de conexão e marca de roteamento. Marca de Conexão permite marcar a conexão necessária e, posteriormente, trabalhar com essa marca como uma condição para aplicação marca de roteamento. E já com marca de roteamento posso trabalhar em ip route e regras de rota. Com as ferramentas entendidas, agora precisamos decidir quais conexões marcar — primeiro, onde exatamente marcar — segundo.

Com o primeiro, é simples — devemos marcar todas as conexões que chegam ao roteador da Internet pela respectiva canal. No nosso caso, serão três marcas (de acordo com o número de canais): "conn_isp1", "conn_isp2" e "conn_isp3".

A nuance com o segundo está no fato de que as conexões de entrada serão de dois tipos: de trânsito e aquelas destinadas ao próprio roteador. O mecanismo de marca de conexão funciona na tabela mangle.Vamos analisar o movimento do pacote em um diagrama simplificado, gentilmente elaborado pelos especialistas do recurso mikrotik-trainings.com (não é publicidade):

Seguindo as setas, vemos que o pacote, chegando na "interface de entrada", passa pela cadeia "Prerouting" e somente depois é dividido entre trânsito e local no bloco "Decisão de Roteamento". Portanto, para matar dois coelhos com uma cajadada só, usaremos Marca de Conexão na tabela Mangle Prerouting cadeias Prerouting.

Observação. No ROS, as marcas de "Routing mark" estão indicadas na seção Ip/Routes/Rules como "Table", e nas outras seções como "Routing Mark". Isso pode causar alguma confusão na compreensão, mas, na essência, trata-se da mesma coisa e é analógico ao rt_tables no iproute2 no Linux.

2.1. Marcando as conexões de entrada de cada um 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

Observação. Para evitar marcar conexões já marcadas, utilizo a condição connection-mark=no-mark em vez de connection-state=new porque considero isso mais correto, assim como a recusa de drop em conexões inválidas no filtro de entrada.

passthrough=no — pois nesse método de implementação a remarcação é excluída e para acelerar, pode-se interromper a verificação das regras após a primeira correspondência.

Deve-se ter em mente que, por enquanto, não estamos interferindo na roteação. Neste momento, estamos apenas nas etapas de preparação. A próxima etapa da implementação será o tratamento do tráfego de passagem que retorna em uma conexão estabelecida do destinatário na rede local. Ou seja, daqueles pacotes que (veja o diagrama) passaram pelo roteador no caminho:

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Forward"=>"Post Routing"=>"Output Interface" e chegaram ao seu destinatário na rede local.

Importante! No ROS não há uma divisão lógica entre interfaces externas e internas. Se seguirmos o caminho do pacote de resposta pelo diagrama fornecido, ele seguirá pelo mesmo caminho lógico que a solicitação:

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Forward"=>"Post Routing"=>"Output Interface" simplesmente para a solicitação "Input Interface" a interface do ISP, enquanto para a resposta — LAN

2.2. Direcionamos o tráfego de passagem de resposta pelas respectivas tabelas de roteação:

/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 — estamos trabalhando apenas com o tráfego da rede local e dst-address-type=!local que não possui um endereço de destino das próprias interfaces do roteador.

O mesmo se aplica aos pacotes locais que chegaram ao roteador pelo caminho:

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

Importante! A resposta seguirá pelo seguinte caminho:

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

2.3. Direcionamos o tráfego local de resposta pelas respectivas tabelas de roteação:

/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

Neste estágio, a tarefa de preparar o envio da resposta no canal de Internet de onde a solicitação veio pode ser considerada resolvida. Tudo está marcado, rotulado e pronto para ser roteado.
Um efeito "colateral" excelente dessa configuração é a possibilidade de operação do redirecionamento de portas DSNAT de ambos os provedores (ISP2, ISP3) simultaneamente. Não em todos, pois no ISP1 temos um endereço não roteável. Esse efeito é importante, por exemplo, para um servidor de e-mail com dois MX, que visualizam diferentes canais de Internet.

Para eliminar as nuances de funcionamento de redes locais com IPs externos do roteador, utilizamos soluções dos itens 1.8.2 e 3.1.2.6.

Além disso, é possível utilizar uma ferramenta com marcações para resolver o item 3 da tarefa. Vamos implementar assim:

2.4. Direcionamos o tráfego dos clientes locais das listas de roteamento para as tabelas correspondentes:

/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

No final, isso se apresenta aproximadamente assim:

3. Configuramos a conexão com o ISP e ativamos o roteamento pelas marcas

3.1. Configuramos a conexão com o ISP1:
3.1.1. Configuramos o endereço IP estático:

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

3.1.2. Configuramos a roteação estática:
3.1.2.1. Adicionamos a rota padrão "de emergência":

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

Observação. Essa rota permite que o tráfego dos processos locais passe pela etapa de Decisão de Roteamento independentemente do estado dos canais de qualquer um dos provedores. A nuance do tráfego local de saída é que, para que um pacote se mova de alguma forma, deve haver uma rota ativa na tabela de roteamento principal até o gateway padrão. Se não houver, o pacote será simplesmente descartado.

Como uma extensão da ferramenta check gateway para uma análise mais aprofundada do estado do canal, sugiro usar o método de rotas recursivas. A essência do método é que indicamos ao roteador procurar o caminho para seu gateway não diretamente, mas através de um gateway intermediário. Como esses "gateways de verificação", escolheremos 4.2.2.1, 4.2.2.2 e 4.2.2.3, respectivamente, para ISP1, ISP2 e ISP3.

3.1.2.2. Rota para o endereço "de verificação":

/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

Observação. Reduzimos o valor da scope para o padrão no ROS target scope, para usar futuramente 4.2.2.1 como gateway recursivo. Enfatizo: a scope da rota para o endereço "de verificação" deve ser menor ou igual à target scope da rota que irá se referir ao verificador.

3.1.2.3. Rota recursiva padrão para tráfego sem roteamento marcado:

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

Observação. O valor distance=2 é usado porque o ISP1, segundo os termos da tarefa, foi declarado como o primeiro de backup.

3.1.2.4. Rota recursiva padrão para tráfego com marcação de roteamento "to_isp1":

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

Observação. Aqui, finalmente começamos a aproveitar os frutos do trabalho preparatório realizado na seção 2.

Por esta rota, todo o tráfego com a marcação de rota “to_isp1” será direcionado ao gateway do primeiro provedor, independentemente de qual seja o gateway padrão ativo no momento para a tabela principal.

3.1.2.5. A primeira rota recursiva de reserva padrão para o tráfego rotulado dos provedores 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

Observação. Essas rotas são necessárias, inclusive, para a reserva de tráfego de redes locais, que são membros da lista de endereços “to_isp*”.

3.1.2.6. Definindo a rota para o tráfego local do roteador para a Internet via ISP1:

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

Observação. Juntamente com as regras da seção 1.8.2, garante-se o acesso ao canal desejado com a fonte especificada. Isso é crítico para a construção de túneis em que se define o endereço IP do lado local (EoIP, IP-IP, GRE). Como as regras em ip route rules são executadas de cima para baixo, até a primeira correspondência de condições, essa regra deve estar após as regras da seção 1.8.2.

3.1.3. Definindo a regra NAT para o tráfego 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

Observação. NAT em todo o tráfego de saída, exceto o que se enquadra nas políticas IPsec. Procuro não usar action=masquerade sem extrema necessidade. Ele funciona mais lentamente e é mais intensivo em recursos do que src-nat, pois calcula o endereço para NAT para cada nova conexão.

3.1.4. Direcionando os clientes da lista, que têm a saída proibida através dos demais provedores, diretamente para o gateway 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

Observação. action=route tem maior prioridade e é aplicado antes das outras regras de roteamento.

place-before=0 — coloca nossa regra em primeiro lugar na lista.

3.2. Configurando a conexão com o ISP2.

Como o provedor ISP2 nos fornece as configurações via DHCP, é razoável realizar as alterações necessárias com um script que é acionado quando o cliente DHCP é ativado:

/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 script em uma janela Winbox:

Observação. A primeira parte do script é acionada ao receber a locação com sucesso, a segunda — após a liberação da locação.Veja a observação 2.

3.3. Configurando a conexão com o provedor ISP3.

Como o provedor nos fornece configurações dinâmicas, é razoável realizar as alterações necessárias com scripts que são ativados após a ativação e após a queda da interface ppp.

3.3.1. Primeiro, configurando 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 script em uma janela Winbox:

Observação. String
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
permite processar corretamente a renomeação da interface, uma vez que trabalha com seu código e não com o nome exibido.

3.3.2. Agora, usando o perfil, criamos a conexão 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 um toque final, configuramos os relógios:

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

Para aqueles que chegaram até aqui

A forma proposta de implementação do multivan é uma preferência pessoal do autor e não é a única possível. O conjunto de ferramentas do ROS é extenso e flexível, o que, por um lado, provoca dificuldades para iniciantes, mas, por outro, é a razão de sua popularidade. Estude, experimente, descubra novas ferramentas e soluções. Por exemplo, como aplicação dos conhecimentos adquiridos, na implementação do multivan, pode-se substituir a ferramenta Check-gateway com rotas recursivas por Netwatch.

Notas

Check-gateway — um mecanismo que desativa a rota após duas verificações de disponibilidade do gateway consecutivas e malsucedidas. A verificação é realizada a cada 10 segundos, mais o tempo limite de resposta. No total, o tempo de comutação real fica entre 20 e 30 segundos. Se esse tempo de comutação não for suficiente, há a opção de usar a ferramenta Netwatch, onde o tempo de verificação pode ser definido manualmente. O mecanismo Check-gateway não é acionado em caso de perdas periódicas de pacotes no canal.
Importante! A desativação da rota principal implica a desativação de todas as outras rotas que dependem dela. Portanto, para elas, não é necessário especificar check-gateway=ping .
Às vezes, ocorre uma falha no funcionamento do DHCP, que se apresenta como se o cliente estivesse preso no estado de renovação. Nesse caso, a segunda parte do script não será executada, mas o tráfego não será afetado, pois o estado é monitorado pela respectiva rota recursiva.
ECMP (Equal Cost Multi-Path) — no ROS, há a possibilidade de definir uma rota com vários gateways e com a mesma distância. Nesse caso, as conexões serão distribuídas pelos canais, usando o algoritmo round robin, proporcional ao número de gateways especificados.

Pela motivação para escrever este artigo, ajuda na formação de sua estrutura e na definição de ênfases — agradecimento pessoal a Evgeny @jscar

Fonte: habr.com