👊🏻 🐹 👈🏿 Multivan e roteamento no Mikrotik RouterOS 🐲 🎌 📮

Com correções e adições de 11/02/2020

1. Introdução

Além da vaidade, a frequência deprimente de perguntas sobre esse tópico nos grupos relevantes da comunidade de telegramas de língua russa me levou a aceitar o artigo. Este artigo é destinado a administradores iniciantes do Mikrotik RouterOS (daqui em diante ROS). Considera apenas uma multivan, com ênfase no roteamento. O bônus inclui configurações minimamente suficientes para garantir uma operação segura e conveniente. Aqueles que buscam a divulgação dessas filas, balanceamento de carga, vlan, pontes, análises detalhadas em várias etapas da condição do canal e similares - não podem perder tempo e esforço lendo.

Dados de origem

Como assunto de teste, um roteador Mikrotik de cinco portas com o ROS versão 6.45+ foi selecionado. Ele encaminhará o tráfego entre duas redes locais (LAN1 e LAN2) e três provedores (ISP1, ISP2, ISP3). O canal para o ISP1 possui um endereço estático "cinza", o ISP2 é "branco" recebido via DHCP, o ISP3 é "branco" com autenticação PPPoE. O diagrama de conexão é mostrado na figura:

A tarefa é configurar o roteador MTK com base no esquema para que:

Forneça comutação automática para o provedor de backup. O principal provedor é o ISP2, a primeira reserva é o ISP1, a segunda reserva é o ISP3.
Para organizar o acesso LAN1 à Internet apenas através do ISP1.
Ofereça a capacidade de rotear o tráfego das redes locais para a Internet através do provedor selecionado com base na lista de endereços.
Fornecer a possibilidade de publicar serviços de uma rede local na Internet (DSTNAT)
Configure um filtro de firewall para fornecer a segurança mínima suficiente da Internet.
O roteador pode emitir seu próprio tráfego através de qualquer um dos três provedores, dependendo do endereço de origem selecionado.
Forneça roteamento de pacotes de resposta para o canal de onde eles vieram (incluindo LAN).

Observação. Vamos configurar o roteador "do zero" para garantir que não haja surpresas ao iniciar as configurações "prontas para uso", mudando de versão para versão. O Winbox foi escolhido como a ferramenta de configuração, onde as alterações serão exibidas visualmente. As próprias configurações serão definidas por comandos no terminal Winbox. A conexão física para configuração é feita através de uma conexão direta com a interface Ether5.

Uma pequena discussão sobre o que é uma multivan, se é um problema ou se as pessoas espertas e astutas tecem redes de conspirações ao redor

Um administrador curioso e atencioso, montando esse ou aquele esquema por conta própria, de repente percebe que está funcionando normalmente. Sim, sim, sem essas tabelas de roteamento personalizadas e outras regras de rota, que estão cheias da maioria dos artigos sobre este tópico. Confira?

Podemos configurar o endereçamento em interfaces e gateways padrão? Sim:

O endereço e o gateway com a distância = 2 e o gateway de verificação = ping foram registrados no ISP1 .
No ISP2, a configuração dhcp padrão para o cliente é, portanto, a distância será igual a um.
No ISP3, nas configurações pppoe do cliente com add-default-route = yes, defina default-route-distance = 3 .

Não se esqueça de registrar o NAT para a saída:

/ ip firewall nat add action = cadeia de disfarce = srcnat out-interface-list = WAN

Como resultado, os usuários de LANs divertem os selos carregados através do provedor principal do ISP2 e há uma reserva do canal usando o mecanismo de gateway de verificação ^.

O ponto 1 da tarefa é implementado. Onde está a multivan com suas etiquetas? Não ...

Mais longe. Você precisa liberar clientes específicos da LAN através do ISP1:

/ ip firewall mangle add action = cadeia de rotas = pré-roteamento dst-address-list =! BOGONS \
passthrough = yes route-dst = 100.66.66.1 src-address-list = Via_ISP1
/ ip firewall mangle add action = cadeia de rotas = pré-roteamento dst-address-list =! BOGONS \
passagem = nenhuma rota-dst = 100.66.66.1 src-address = 192.168.88.0 / 24

Os itens 2 e 3 da tarefa são implementados. Etiquetas, carimbos, regras de rota, onde você está ?!

Precisa dar acesso ao seu servidor OpenVPN favorito com o endereço 172.17.17.17 para clientes da Internet? Por favor:

/ ip cloud set ddns-enabled = yes

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

Registramos o encaminhamento de porta da Internet:

/ ip firewall nat add action = cadeia dst-nat = dstnat dst-port = 1194 \
in-interface-list = protocolo WAN = endereços udp = 172.17.17.17

O ponto 4 está pronto.

Configuramos um firewall e outra segurança para o ponto 5. Ao mesmo tempo, estamos felizes por tudo estar funcionando para os usuários e chegar a um contêiner com uma bebida favorita ...
Ah! Os túneis ainda estão esquecidos.

O cliente l2tp configurado de acordo com o artigo pesquisado subiu para o amado VDS holandês? Sim
O servidor l2tp com IPsec aumentou e os clientes pelo nome DNS da nuvem IP (veja acima.) se apegam? Sim
Recostando-nos, tomando um gole da bebida, examinamos à toa os itens 6 e 7 do problema. Nós pensamos - precisamos disso? Tudo está funcionando assim. Então, se não for necessário, é tudo. Multivan implementado.

O que é uma multivan? Esta é a conexão de vários canais da Internet a um roteador.

Você não pode ler mais o artigo, porque o que pode haver além de uma demonstração de aplicabilidade duvidosa?

Com aqueles que permanecem interessados nos pontos 6 e 7 da tarefa e também sentem a coceira do perfeccionismo, mergulhamos mais fundo.

A tarefa mais importante da implementação de multivans é o roteamento correto do tráfego. Nomeadamente: independentemente de qual (ou qual) ^{Veja a Nota 3,} o (s) canal (s) do provedor olha para a rota padrão em nosso roteador, ele deve retornar a resposta exatamente ao canal de onde o pacote veio. A tarefa é clara. Onde está o problema? De fato, em uma rede local simples, a tarefa é a mesma, mas ninguém se incomoda com configurações adicionais e não sente problemas. A diferença é que qualquer nó roteado na Internet é acessível por cada um de nossos canais, e não por um estritamente específico, como em uma LAN simples. Mas o "problema" é que, se recebemos uma solicitação para o endereço IP do ISP3, no nosso caso, a resposta passará pelo canal ISP2, pois o gateway padrão é direcionado para lá. Ele sairá e será descartado pelo provedor como incorreto. Decidimos sobre o problema. Como resolver isso?

A solução é dividida em três etapas:

Pré-configuração Nesse estágio, as configurações básicas do roteador serão definidas: rede local, firewall, lista de endereços, NAT hairpin, etc.
Multivan. Nesse estágio, as conexões necessárias serão marcadas e classificadas de acordo com as tabelas de roteamento.
Conexão com o ISP. Nesta fase, as interfaces que fornecem conexão à Internet serão configuradas, o roteamento e o mecanismo de reserva de canais da Internet serão envolvidos.

Observação. Três tipos diferentes de conexão com o ISP foram escolhidos especificamente para mostrar que não há nada insolúvel na configuração de multivans com endereços dinâmicos e demonstrar uma das opções da solução.
Importante! Para mudar de canal de acordo com o algoritmo especificado usando o custo das rotas de distância , é usado o mecanismo de gateway de verificação. ^{Ver nota 1}
Os scripts fornecidos no artigo não têm nada a ver com reserva de canal.

1. Predefinição

1.1 Limpamos a configuração do roteador com o comando:

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

concordo com “ Perigoso! Redefinir mesmo assim? [y / N]: ”e, após a reinicialização, nos conectamos ao Winbox via MAC. Nesta fase, a configuração e a base de usuários são limpas.

1.2 Crie um novo usuário:

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

faça login e exclua o padrão:

 /user remove admin

Observação. É a remoção e não a desconexão do usuário padrão que o autor considera mais seguro e recomenda o uso.

1.3 Criamos listas básicas de interface para a conveniência de operar em um firewall, configurações de descoberta e outros servidores MAC:

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

Assinamos interfaces com comentários

 /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 preencha as listas de interface:

 /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 com isso e facilita muito a solução de problemas e a compreensão da configuração.

O autor considera necessário, por razões de segurança, adicionar a interface ether3 à lista de interfaces "WAN", apesar do protocolo IP não passar por ela.

Não esqueça que após a interface PPP ter sido criada no ether3, ela também precisará ser adicionada à lista de interfaces "WAN"

1.4 Escondemos o roteador da detecção e controle de proximidade das redes dos provedores pelo 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 um conjunto mínimo suficiente de regras de filtro de 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 fornece permissão para conexões estabelecidas e relacionadas que são iniciadas a partir de redes conectadas e pelo próprio roteador)

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

(ping e não apenas ping. É permitido entrar todo o icmp. É muito útil para encontrar problemas com o MTU)

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

(a regra que fecha a 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 connection-state = invalid, passando pelo roteador. É altamente recomendado pelo Mikrotik, mas em algumas situações raras pode bloquear o 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 pacotes que saem da Internet e não passaram pelo procedimento dstnat pelo roteador. Isso protegerá as redes locais contra invasores que, estando no mesmo domínio de broadcast com nossas redes externas, registrem nossos IPs externos como gateway e, assim, tentam "Explore" nossas redes de área local.)

Observação. Vamos supor que LAN1 e LAN2 sejam redes confiáveis e o tráfego entre elas e a partir delas não seja filtrado.

1.6 Crie uma lista com uma lista 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 roteados para a Internet e, consequentemente, também a seguiremos.)

Observação. A lista pode mudar, por isso aconselho que você verifique periodicamente a relevância.

1.7 Configure 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, os servidores dinâmicos têm precedência sobre os definidos estaticamente. Uma solicitação de resolução de nome é enviada ao primeiro servidor na ordem da lista. A transição para o próximo servidor ocorre quando o atual não está disponível. Grande tempo limite - mais de 5 segundos. Retornar quando o “servidor caído” é retomado não acontece automaticamente. Dado esse algoritmo e a presença de uma multivan, o autor recomenda não usar servidores emitidos por provedores.

1.8 Configure a rede local.
1.8.1 Configure endereços IP estáticos nas interfaces da 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 Definimos as regras para rotas para nossas redes locais através da tabela de roteamento 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"

Observação. Essa é uma das maneiras mais fáceis e rápidas de acessar endereços de rede local com endereços IP externos de interfaces de roteador pelas quais a rota padrão não passa.

1.8.3 Se necessário, ative o 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 que os usuários da LAN1 e LAN2 acessem através de um IP externo (dstnat) a servidores localizados com usuários no mesmo segmento de rede.

2. Na verdade, a implementação das multivans corretas

Para resolver o problema de “responder de onde eles pediram”, usaremos duas ferramentas ROS: marca de conexão e marca de roteamento . A marca de conexão permite marcar a conexão desejada e continuar a trabalhar com esta etiqueta como condição para a aplicação da marca de roteamento . E já com a marca de roteamento é possível trabalhar nas regras de rota e rota IP . Nós descobrimos as ferramentas, agora precisamos decidir quais conexões marcar - uma, onde exatamente marcar - duas.

Com o primeiro, tudo é simples - precisamos marcar todas as conexões que chegam ao roteador da Internet através do canal apropriado. No nosso caso, serão três rótulos (de acordo com o número de canais): “conn_isp1”, “conn_isp2” e “conn_isp3”.

A nuance da segunda é que as conexões de entrada serão de dois tipos: trânsito e aquelas destinadas ao próprio roteador. O mecanismo da marca de conexão funciona na tabela mangle . Considere o movimento do pacote em um diagrama simplificado, gentilmente coletado pelos especialistas do recurso mikrotik-trainings.com (sem publicidade):

Seguindo as setas, vemos que o pacote que chega à “ interface de entrada ” passa pela cadeia “ Pré-roteamento ” e só então é dividido em trânsito e local no bloco “ Decisão de Roteamento ”. Portanto, para matar dois coelhos com uma cajadada, use a marca de conexão na tabela de pré-roteamento Mangle da cadeia de pré - roteamento .

Observação . No ROS, as marcas “Routing mark” são indicadas na seção Ip / Routes / Rules como “Table” e nas demais seções como “Routing Mark”. Isso pode causar alguma confusão no entendimento, mas, de fato, é o mesmo e é o análogo de rt_tables no iproute2 no linux.

2.1 Marcamos 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.
Os leitores que tentarem literalmente e na ordem de leitura repetir a configuração sugerida no artigo, ao inserir o terceiro comando, encontrarão o erro: "a entrada não corresponde a nenhum valor da interface". Isso ocorre devido à ausência da interface "pppoe-isp3", que será configurada na Seção 3.3.2. Neste ponto, você pode inserir "ether3" em vez de "pppoe-isp3". Depois de concluir o parágrafo 3.3.2, você deve voltar e colocar o nome atual da interface.

Para não marcar conexões já marcadas, eu uso a condição connection-mark = no-mark em vez de connection-state = new.

passthrough = no - porque neste método de implementação, a marcação é excluída e, para acelerar, você pode interromper a enumeração de regras após a primeira correspondência.

Deve-se ter em mente que ainda não interferimos no roteamento. Agora, existem apenas estágios de preparação. O próximo estágio da implementação será o processamento do tráfego de trânsito, retornado por meio de uma conexão estável do destinatário na rede local. I.e. os pacotes que (veja o diagrama) passaram pelo roteador ao longo do caminho:

"Interface de entrada" => "Pré-roteamento" => "Decisão de roteamento" => "Encaminhar" => "Pós-roteamento" => "Interface de saída" e chegaram ao seu destino na rede local.

Importante! No ROS, não há divisão lógica em interfaces externas e internas. Se rastrearmos o caminho do pacote de resposta no diagrama abaixo, ele seguirá o mesmo caminho lógico da solicitação:

“Interface de entrada” => ”Pré-roteamento” => ”Decisão de roteamento” => ”Encaminhar” => ”Pós-roteamento” => ”Interface de saída” apenas para a solicitação “ Interface de entrada ” havia uma interface ISP e para a resposta - LAN

2.2 Direcionamos o tráfego de trânsito de retorno para as tabelas de roteamento 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

Observação. in-interface-list =! WAN - trabalhamos apenas com tráfego da rede local e dst-address-type =! local sem o endereço de destino dos endereços de interface do próprio roteador.

O mesmo para pacotes locais que chegaram ao roteador ao longo do caminho:

"Interface de entrada" => "Pré-roteamento" => "Decisão de roteamento" => "Entrada" => "Processo local"

Importante! A resposta seguirá o seguinte caminho:

"Processo local" => "Decisão de roteamento" => "Saída" => "Pós-roteamento" => "Interface de saída"

2.3 Dirigimos o tráfego local de resposta para as tabelas de roteamento 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

Nesse estágio, a tarefa de preparar o envio de uma resposta ao canal da Internet a partir do qual a solicitação veio pode ser considerada resolvida. Tudo está marcado, marcado e pronto para rotear.
Um excelente efeito "colateral" dessa configuração é a capacidade de encaminhar portas DSNAT de ambos os provedores (ISP2, ISP3) ao mesmo tempo. De maneira alguma, porque no ISP1 não temos um endereço roteável. Esse efeito é importante, por exemplo, para um servidor de correio com dois MXs que analisam diferentes canais da Internet.

Para eliminar as nuances das redes locais de trabalho com roteadores IP externos, usamos as soluções dos parágrafos. 1.8.2 e 3.1.2.6.

Além disso, você pode usar a ferramenta com marcações e resolver o parágrafo 3 do problema. Nós o implementamos assim:

2.4 Direcionamos o tráfego de 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

Como resultado, é algo parecido com isto (a imagem é clicável):

3. Configure a conectividade do ISP e ative o roteamento baseado em marca

3.1 Configure a conexão com o ISP1:
3.1.1 Configure um endereço IP estático:

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

3.1.2 Configure o roteamento estático:
3.1.2.1 Adicione uma rota de emergência padrão:

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

Observação. Essa rota permite que o tráfego de processos locais passe pelo estágio Decisão de Rota, independentemente do estado dos canais de qualquer um dos provedores. A nuance do tráfego local de saída é que, para que o pacote se mova pelo menos em algum lugar, o roteamento ativo para o gateway padrão deve estar presente na tabela de roteamento principal. Caso contrário, o pacote será simplesmente destruído.

Como uma extensão da ferramenta de gateway de verificação para uma análise mais profunda do status do canal, proponho o uso do método de rota recursiva. A essência do método é que dizemos ao roteador para procurar o caminho para o gateway não diretamente, mas através de um gateway intermediário. Como tais gateways de "teste", 4.2.2.1, 4.2.2.2 e 4.2.2.3 serão selecionados para ISP1, ISP2 e ISP3, respectivamente.

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. O valor do escopo é reduzido para o padrão no escopo de destino do ROS, a fim de usar 4.2.2.1 adicional como um gateway recursivo. Enfatizo: o escopo da rota para o endereço de "verificação" deve ser menor ou igual ao escopo de destino da rota que fará referência à verificação.

3.1.2.3 A rota recursiva padrão para tráfego sem uma marca de roteamento:

 /ip route add check-gateway=ping comment="Unmarked via ISP1" \ distance=2 gateway=4.2.2.1

Observação. O valor da distância = 2 é usado porque o ISP1 é declarado como o primeiro em espera nos termos da tarefa.

3.1.2.4 A rota recursiva padrão para o tráfego com a marca 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. Na verdade, aqui estamos finalmente começando a usar os frutos do trabalho preparatório realizado no parágrafo 2.

Nesta rota, todo o tráfego que marcar a rota "to_isp1" será direcionado para o gateway do primeiro provedor, independentemente de qual gateway padrão da tabela principal esteja ativo no momento.

3.1.2.5 A primeira rota recursiva padrão de fallback 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 também são necessárias para reservar tráfego de redes locais, que são membros da lista de endereços “to_isp *” '

3.1.2.6 Escrevemos a rota para o tráfego do roteador local para a Internet através do ISP1:

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

Observação. Em combinação com as regras da cláusula 1.8.2, é fornecida uma saída para o canal desejado com uma determinada fonte. Isso é crítico para a construção de túneis nos quais o endereço IP do lado local (EoIP, IP-IP, GRE) é especificado. Como as regras nas regras de rota IP são executadas de cima para baixo, até que as condições correspondam pela primeira vez, essa regra deve seguir as regras da cláusula 1.8.2.

3.1.3 Escrevemos 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. O NAT é tudo que existe, exceto pelo fato de cair nas políticas IPsec. Tento não usar action = masquerade, a menos que seja absolutamente necessário. É mais lento e consome mais recursos do que o src-nat porque calcula um endereço para o NAT para cada nova conexão.

3.1.4 Enviamos clientes da lista que estão proibidos de sair através de outros 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 uma prioridade mais alta e é aplicada antes de outras regras de roteamento.

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

3.2 Nós configuramos a conexão com o ISP2.

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

 /ip dhcp-client add add-default-route=no disabled=no interface=ether2 script=":if (\$bound=1) do={\r\ \n /ip route remove [ find gateway=\"4.2.2.2\" ]; /ip route remove \ [ find where dst-address ~\"4.2.2.2\" ]\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=10\r\ \n /ip route add check-gateway=ping 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\"\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 remove [ find gateway=\"4.2.2.2\" ]; /ip route remove \ [ find where dst-address ~\"4.2.2.2\" ]\r\ \n /ip firewall nat remove [find comment=\"NAT via ISP2\"]\r\ \n /ip route rule remove [find comment=\"From ISP2 IP to Inet\"]\r\ \n}\r\ \n" use-peer-dns=no use-peer-ntp=no

O script em si na janela Winbox (clicável):

Observação. A primeira parte do script é acionada quando a concessão é recebida com êxito, a segunda - após a liberação da concessão. ^{Ver nota 2}

3.3 Nós configuramos a conexão com o provedor ISP3.

Como o provedor de configuração nos dá dinamismo, é razoável fazer as alterações necessárias com scripts que iniciam após o aumento e após a queda da interface ppp.

Observação. A interface ppp pode ser especificada como um gateway em vez de um endereço IP. No entanto, neste caso, a rota recursiva não pode ser ativada. Portanto, obtemos o endereço IP do lado do provedor na variável e o usamos mais da mesma maneira que para os outros provedores

3.3.1 Primeiro, configure o perfil:

 /ppp profile add comment="for PPPoE to ISP3" interface-list=WAN name=isp3_client \ on-down="/ip route remove [ find gateway=\"4.2.2.3\" ]\r\ \n/ip route remove [ find where dst-address ~\"4.2.2.3\" ]\r\ \n/ip firewall nat remove [find comment=\"NAT via ISP3\"]\r\ \n/ip route rule remove [find comment=\"From ISP3 IP to Inet\"]" \ on-up="/ip route remove [ find gateway=\"4.2.2.3\" ]; /ip route remove \ [ find where dst-address ~\"4.2.2.3\" ]\r\ \n/ip route add check-gateway=ping comment=\"For recursion via ISP3\" distance=1 \ dst-address=4.2.2.3/32 gateway=\$\"remote-address\" scope=10\r\ \n/ip route add check-gateway=ping 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\"\r\ \n/ip route rule add comment=\"From ISP3 IP to Inet\" \ src-address=\$\"local-address\" table=to_isp3 "

O script em si na janela Winbox (clicável):

Observação. String
/ ip firewall mangle set [find comment = "Connmark in from ISP3"] na interface = $ "interface";
Permite processar corretamente a renomeação da interface, porque ela trabalha com seu código e não com o nome de exibição.

3.3.2 Agora, usando o perfil, crie uma 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

Observação. Alguns provedores "esquecem" de fornecer o parâmetro "endereço remoto". Nesse caso, quando conectado, o script de configuração não funcionará corretamente e, no log, você verá o seguinte erro:
pppoe, ppp, info pppoe-isp3: não foi possível determinar o endereço remoto usando xxx.xxx.xxx.xxx
Para resolver esse problema, você precisa definir manualmente o endereço no perfil ppp (qualquer modelo):

 /ppp profile set isp3_client remote-address=169.254.69.96

String
/ ip firewall mangle set [find comment = "Connmark in from ISP3"] na interface = $ "interface";
Permite processar corretamente a renomeação da interface, porque ela trabalha com seu código e não com o nome de exibição.

Como toque final, acerte o relógio:

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

Para quem lê até o fim

O método proposto para implementar multivans é a preferência pessoal do autor e não é o único possível. O kit de ferramentas ROS é extenso e flexível, o que, por um lado, causa dificuldades para iniciantes, por outro - o motivo da popularidade. Explore, tente, descubra novas ferramentas e soluções. Por exemplo, como uma aplicação do conhecimento adquirido, nesta implementação da multivan é possível substituir a ferramenta de gateway de verificação por rotas recursivas com o Netwatch .

Anotações

Check-gateway — , . 10 , . , 20-30 . — Netwatch , .
Check-gateway .

! , . check-gateway=ping .
Ocorre que ocorre uma falha no mecanismo de operação DHP, que parece um cliente pendurado em um estado de renovação. Nesse caso, a segunda parte do script não funcionará, mas não prejudicará o tráfego de andar corretamente, pois o estado monitora a rota recursiva correspondente.
ECMP (Caminho múltiplo de custo igual) - O ROS pode especificar uma rota com vários gateways e a mesma distância. Nesse caso, as conexões serão distribuídas pelos canais usando o algoritmo round robin, proporcionalmente ao número de gateways especificados.

Para que o ímpeto escreva o artigo, ajude a moldar sua estrutura e colocando ênfase - agradecimentos pessoais a Eugene @jscar

Multivan e roteamento no Mikrotik RouterOS