Introdução
A aceitação do artigo, além da vaidade, foi motivada pela frequência deprimente de perguntas sobre o assunto nos grupos de perfis da comunidade de telegramas de língua russa. O artigo é destinado a administradores novatos do Mikrotik RouterOS (doravante denominado ROS). Trata apenas da multivan, com ênfase no roteamento. Como bônus, existem configurações minimamente suficientes para garantir uma operação segura e conveniente. Aqueles que procuram a divulgação dos tópicos de filas, balanceamento de carga, vlans, pontes, análise profunda em vários estágios do estado do canal e afins - não podem perder tempo e esforço lendo.
Dados iniciais
Como objeto de teste, foi selecionado um roteador Mikrotik de cinco portas com ROS versão 6.45.3. Ele roteará o tráfego entre duas redes locais (LAN1 e LAN2) e três provedores (ISP1, ISP2, ISP3). O canal para ISP1 possui um endereço estático "cinza", ISP2 - "branco", obtido via DHCP, ISP3 - "branco" com autorizaçã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 um provedor de backup. O provedor principal é ISP2, a primeira reserva é ISP1, a segunda reserva é ISP3.
- Organize o acesso da rede LAN1 à Internet somente por meio do ISP1.
- Forneça a capacidade de rotear o tráfego de redes locais para a Internet por meio do provedor selecionado com base na lista de endereços.
- Prever a possibilidade de publicação de serviços da rede local para a Internet (DSTNAT)
- Configure um filtro de firewall para fornecer o mínimo de segurança suficiente da Internet.
- O roteador pode emitir seu próprio tráfego por meio de qualquer um dos três provedores, dependendo do endereço de origem selecionado.
- Certifique-se de que os pacotes de resposta sejam roteados para o canal de onde vieram (incluindo LAN).
Observação Vamos configurar o roteador “do zero” para garantir a ausência de surpresas nas configurações iniciais “fora da caixa” que mudam de versão para versão. O Winbox foi escolhido como uma 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 por uma conexão direta com a interface Ether5.
Um pouco de raciocínio sobre o que é uma multivan, é um problema ou são pessoas espertas e espertas em tecer redes de conspiração
Um administrador curioso e atento, montando tal ou outro esquema por conta própria, de repente percebe que já está funcionando normalmente. Sim, sim, sem suas tabelas de roteamento personalizadas e outras regras de roteamento, das quais a maioria dos artigos sobre esse tópico está repleta. Vamos checar?
Podemos configurar o endereçamento em interfaces e gateways padrão? Sim:
No ISP1, o endereço e o gateway foram registrados com distância = 2 и verifique-gateway = ping.
No ISP2, a configuração padrão do cliente dhcp - portanto, a distância será igual a um.
No ISP3 nas configurações do cliente pppoe quando add-default-route=sim стР° РІРёРј distância-da-rota-padrão=3.
Não esqueça de registrar o NAT na saída:
/ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN
Como resultado, os usuários de sites locais se divertem baixando gatos por meio do provedor ISP2 principal e há uma reserva de canal usando o mecanismo verifique o gateway Ver nota 1
O ponto 1 da tarefa é implementado. Onde está a multivan com suas marcas? Não…
Avançar. Você precisa liberar clientes específicos da LAN via ISP1:
/ip firewall mangle add action=route chain=pré-roteamento dst-address-list=!BOGONS
passthrough=sim route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip firewall mangle add action=route chain=pré-roteamento dst-address-list=!BOGONS
passthrough=no route-dst=100.66.66.1 endereço-src=192.168.88.0/24
Os itens 2 e 3 da tarefa foram implementados. Etiquetas, carimbos, regras de rota, cadê você?!
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=sim
Como peer, damos ao cliente o resultado de saída: “:put [ip cloud obtém nome dns]"
Registramos o encaminhamento de porta da Internet:
/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=protocolo WAN=udp to-addresses=172.17.17.17
O item 4 está pronto.
Montamos um firewall e outras seguranças para o ponto 5, ao mesmo tempo que ficamos felizes que tudo já esteja funcionando para os usuários e pegamos um recipiente com uma bebida preferida ...
A! Os túneis são esquecidos.
O l2tp-client, configurado pelo artigo do google, subiu para o seu VDS holandês favorito? Sim.
O servidor l2tp com IPsec aumentou e os clientes por nome DNS do IP Cloud (veja acima.) se apegam? Sim.
Recostados em nossa cadeira, tomando um gole de bebida, consideramos preguiçosamente os pontos 6 e 7 da tarefa. Pensamos - precisamos disso? Mesmo assim, funciona assim (c) ... Então, se ainda não for necessário, é isso. Multivan implementado.
O que é uma multivan? Esta é a conexão de vários canais da Internet a um roteador.
Você não precisa ler mais o artigo, porque o que pode haver além de uma demonstração de aplicabilidade duvidosa?
Para os que ficam, que se interessam pelos pontos 6 e 7 da tarefa, e também sentem a coceira do perfeccionismo, mergulhamos mais fundo.
A tarefa mais importante de implementar uma multivan é o roteamento correto do tráfego. A saber: independentemente de qual (ou qual) Veja. nota 3 o(s) canal(is) do ISP olhar para a rota padrão em nosso roteador, ele deve retornar uma resposta para o canal exato de onde veio o pacote. A tarefa é clara. Onde está o problema? De fato, em uma rede local simples, a tarefa é a mesma, mas ninguém se preocupa com configurações adicionais e não sente problemas. A diferença é que qualquer nó roteável na Internet é acessível por meio de cada um de nossos canais, e não por um estritamente específico, como em uma LAN simples. E o “problema” é que se recebemos uma solicitação do endereço IP do ISP3, no nosso caso a resposta passará pelo canal ISP2, já que o gateway padrão é direcionado para lá. Deixa e será descartado pelo provedor como incorreto. O problema foi identificado. Como resolver isso?
A solução é dividida em três etapas:
- Predefinição. Nesta fase, serão definidas as configurações básicas do roteador: rede local, firewall, lista de endereços, hairpin NAT, etc.
- Multivan. Nesta fase, as conexões necessárias serão marcadas e classificadas em tabelas de roteamento.
- Conectando-se a um ISP. Nesta etapa, serão configuradas as interfaces que fornecem a conexão com a Internet, ativado o roteamento e o mecanismo de reserva de canais da Internet.
1. Predefinição
1.1. Limpamos a configuração do roteador com o comando:
/system reset-configuration skip-backup=yes no-defaults=yesconcordar com "Perigoso! Reiniciar mesmo assim? [s/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 apagadas.
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 adminObservação É a remoção e não desabilitação do usuário padrão que o autor considera mais seguro e recomenda para uso.
1.3. Criamos listas de interface básicas 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"Interfaces de assinatura 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 compreensíveis vale o tempo gasto nisso, além de facilitar muito a solução de problemas e a compreensão da configuração.
O autor considera necessário, por questões de segurança, adicionar a interface ether3 à lista de interfaces “WAN”, apesar de o protocolo ip não passar por ela.
Não se esqueça que depois que a interface PPP for levantada em ether3, ela também precisará ser adicionada à lista de interfaces “WAN”
1.4. Ocultamos o roteador da detecção e controle da vizinhança das redes do provedor via MAC:
/ip neighbor discovery-settings set discover-interface-list=!WAN
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN1.5. Criamos o 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 nas redes conectadas e no próprio roteador)
/ip firewall filter add action=accept chain=input comment="ICMP from ALL" protocol=icmp(ping e não apenas ping. Todo icmp é permitido. Muito útil para encontrar problemas de 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 insumos proíbe tudo o mais que vier 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 redefine conexões com connection-state=invalid passando pelo roteador. É fortemente recomendado pelo Mikrotik, mas em algumas raras situações 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 vêm da Internet e não passaram pelo procedimento dstnat de passar pelo roteador. Isso protegerá as redes locais de invasores que, estando no mesmo domínio de broadcast de nossas redes externas, registrarão nossos IPs externos como um gateway e, assim, tentar “explorar” nossas redes locais.)
Observação Vamos assumir que as redes LAN1 e LAN2 são confiáveis e o tráfego entre elas e delas não é 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 roteáveis para a Internet e serão seguidas de acordo.)
Observação A lista está sujeita a alterações, por isso aconselho você a verificar 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.8Observação Na versão atual do ROS, os servidores dinâmicos têm precedência sobre os estáticos. A solicitação de resolução de nome é enviada ao primeiro servidor na ordem da lista. A transição para o próximo servidor é realizada quando o atual está indisponível. O tempo limite é grande - mais de 5 segundos. O retorno, quando o “servidor caído” é retomado, não ocorre automaticamente. Dado esse algoritmo e a presença de uma multivan, o autor recomenda não usar servidores fornecidos pelos provedores.
1.8. Configure uma rede local.
1.8.1. Configuramos endereços IP estáticos em 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. Definimos as regras para rotas para nossas redes locais por meio 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 Esta é uma das maneiras rápidas e fáceis de acessar endereços LAN com fontes de endereços IP externos de interfaces de roteador que não passam pela rota padrão.
1.8.3. Habilite 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.0Observação Isso permite que você acesse seus recursos (dstnat) por meio de um IP externo enquanto estiver dentro da rede.
2. Na verdade, a implementação do multivan muito correto
Para resolver o problema de “responder de onde pediram”, usaremos duas ferramentas ROS: marca de conexão и marca de roteamento. marca de conexão permite marcar a conexão desejada e depois trabalhar com essa marca como condição para aplicação marca de roteamento. E já com marca de roteamento possível trabalhar em rota ip и regras de rota. Descobrimos as ferramentas, agora você precisa decidir quais conexões marcar - uma vez, exatamente onde marcar - duas.
Com o primeiro, tudo é simples - devemos marcar todas as conexões que chegam ao roteador da Internet pelo canal apropriado. No nosso caso, serão três rótulos (pelo número de canais): “conn_isp1”, “conn_isp2” e “conn_isp3”.
A nuance do segundo é que as conexões de entrada serão de dois tipos: trânsito e aquelas destinadas ao próprio roteador. O mecanismo de marca de conexão funciona na tabela mangle. Considere o movimento do pacote em um diagrama simplificado, gentilmente compilado pelos especialistas do recurso mikrotik-trainings.com (não publicitário):
Seguindo as setas, vemos que o pacote chegando em “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, usamos Marca de conexão na mesa Mangle Pré-roteamento correntes Pré-roteamento.
Nota. No ROS, os rótulos “Marca de roteamento” são listados como “Tabela” na seção Ip/Rotas/Regras e como “Marca de roteamento” em outras seções. Isso pode causar alguma confusão no entendimento, mas, na verdade, é a mesma coisa e é um análogo de rt_tables em 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=noObservação Para não marcar conexões já marcadas, utilizo a condição connection-mark=no-mark em vez de connection-state=new porque acho que isso é mais correto, bem como a rejeição de descartar conexões inválidas no filtro de entrada.
passthrough=no - porque neste método de implementação, a remarcação é excluída e, para agilizar, você pode interromper a enumeração de regras após a primeira correspondência.
Deve-se ter em mente que ainda não interferimos de forma alguma no roteamento. Agora existem apenas etapas de preparação. A próxima etapa de implementação será o processamento do tráfego de trânsito que retorna pela conexão estabelecida do destino na rede local. Aqueles. aqueles pacotes que (veja o diagrama) passaram pelo roteador ao longo do caminho:
“Interface de entrada”=>”Pré-roteamento”=>”Decisão de roteamento”=>”Forward”=>”Pós-roteamento”=>”Interface de saída” e chegou ao seu destinatário 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 de acordo com o diagrama acima, ele seguirá o mesmo caminho lógico da solicitação:
“Interface de entrada”=>”Pré-roteamento”=>”Decisão de roteamento”=>”Forward”=>”Pós-roteamento”=>”Interface de saída” apenas para um pedido"interface de entrada” era a interface do ISP e, para a resposta - LAN
2.2. Direcionamos o tráfego de trânsito de resposta 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=noComente. in-interface-list=!WAN - trabalhamos apenas com tráfego da rede local e dst-address-type=!local que não possui o endereço de destino do endereço das interfaces 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”=>”Post Routing”=>”Interface de saída”
2.3. Direcionamos 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=noNesta fase, pode considerar-se resolvida a tarefa de preparar o envio de uma resposta para o canal de Internet de onde partiu o pedido. Tudo está marcado, rotulado e pronto para ser encaminhado.
Um excelente efeito “colateral” dessa configuração é a capacidade de trabalhar com encaminhamento de porta DSNAT de ambos os provedores (ISP2, ISP3) ao mesmo tempo. De jeito nenhum, já que no ISP1 temos um endereço não roteável. Este efeito é importante, por exemplo, para um servidor de correio com dois MXs que olham para diferentes canais de Internet.
Para eliminar as nuances da operação de redes locais 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 uma ferramenta com marcações para resolver o parágrafo 3 do problema. Implementamos assim:
2.4. Direcionamos o tráfego de clientes locais das listas de roteamento para as tabelas apropriadas:
/ip firewall mangle add action=mark-routing chain=prerouting
comment="Address List via ISP1" dst-address-list=!BOGONS new-routing-mark=to_isp1
passthrough=no src-address-list=Via_ISP1
/ip firewall mangle add action=mark-routing chain=prerouting
comment="Address List via ISP2" dst-address-list=!BOGONS new-routing-mark=to_isp2
passthrough=no src-address-list=Via_ISP2
/ip firewall mangle add action=mark-routing chain=prerouting
comment="Address List via ISP3" dst-address-list=!BOGONS new-routing-mark=to_isp3
passthrough=no src-address-list=Via_ISP3Como resultado, parece algo assim:
3. Configure uma conexão com o ISP e ative o roteamento de marca
3.1. Configure uma conexão com 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 padrão de "emergência":
/ip route add comment="Emergency route" distance=254 type=blackholeObservação Essa rota permite que o tráfego de processos locais passe pelo estágio de Decisão de Rota, independentemente do estado dos links de qualquer um dos provedores. A nuance do tráfego local de saída é que, para que o pacote se mova pelo menos para algum lugar, a tabela de roteamento principal deve ter uma rota ativa para o gateway padrão. Caso contrário, o pacote será simplesmente destruído.
Como uma extensão da ferramenta verifique o gateway Para uma análise mais profunda do estado do canal, sugiro usar o método de rota recursiva. A essência do método é que dizemos ao roteador para procurar um caminho para seu gateway não diretamente, mas por meio de um gateway intermediário. 4.2.2.1, 4.2.2.2 e 4.2.2.3 serão escolhidos como gateways de “teste” para ISP1, ISP2 e ISP3, respectivamente.
3.1.2.2. Encaminhe 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=10Observação Reduzimos o valor do escopo para o padrão no escopo de destino do ROS para usar 4.2.2.1 como um gateway recursivo no futuro. Ressalto: o escopo da rota para o endereço “teste” deve ser menor ou igual ao escopo alvo da rota que se referirá ao endereço de teste.
3.1.2.3. Rota padrão recursiva para tráfego sem marca de roteamento:
/ip route add comment="Unmarked via ISP1" distance=2 gateway=4.2.2.1Observação O valor distance=2 é usado porque ISP1 é declarado como o primeiro backup de acordo com as condições da tarefa.
3.1.2.4. Rota padrão recursiva para tráfego com marca de roteamento “to_isp1”:
/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1
routing-mark=to_isp1Observação Na verdade, aqui estamos finalmente começando a colher os frutos do trabalho preparatório realizado no parágrafo 2.
Nesta rota, todo o tráfego que tiver a rota marcada “to_isp1” será direcionado para o gateway do primeiro provedor, independente de qual gateway padrão esteja ativo no momento para a tabela principal.
3.1.2.5. Primeira rota padrão recursiva de fallback para tráfego marcado 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_isp3Observação Essas rotas são necessárias, entre outras coisas, para reservar tráfego de redes locais que são membros da lista de endereços “to_isp*”'
3.1.2.6. Registramos a rota para o tráfego local do roteador 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_isp1Observação Em combinação com as regras do parágrafo 1.8.2, fornece acesso ao canal desejado com uma determinada fonte. Isso é crítico para construir túneis que especificam o endereço IP do lado local (EoIP, IP-IP, GRE). Como as regras nas regras de rota ip são executadas de cima para baixo, até a primeira correspondência das condições, essa regra deve ser posterior às regras da cláusula 1.8.2.
3.1.3. Registramos 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.2Observação NATim tudo o que sai, exceto o que entra nas políticas IPsec. Eu tento não usar action=masquerade a menos que seja absolutamente necessário. É mais lento e consome mais recursos do que src-nat porque calcula o endereço NAT para cada nova conexão.
3.1.4. Enviamos os clientes da lista que estão proibidos de acessar por 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=0Observaçã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. Configure uma conexão com ISP2.
Como o provedor ISP2 nos fornece as configurações via DHCP, é razoável fazer as alterações necessárias com um script que inicia 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 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=noO próprio script na janela do Winbox:
Observação A primeira parte do script é acionada quando o aluguel é obtido com sucesso, a segunda - após a liberação do aluguel.Ver nota 2
3.3. Configuramos uma conexão com o provedor ISP3.
Como o provedor de configurações nos fornece dinâmica, é razoável fazer as alterações necessárias com scripts que iniciam após o aumento da interface ppp e após a queda.
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 próprio script na janela do Winbox:
Observação Linha
/ip firewall mangle set [find comment="Connmark in from ISP3"] in-interface=$"interface";
permite manipular corretamente a renomeação da interface, pois 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_clientComo toque final, vamos acertar o relógio:
/system ntp client set enabled=yes server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.orgPara quem leu até o fim
A forma proposta de implementar uma multivan é a preferência pessoal do autor e não é a única possível. O kit de ferramentas ROS é extenso e flexível, o que, por um lado, causa dificuldades para iniciantes e, por outro, é o motivo de sua popularidade. Aprenda, experimente, descubra novas ferramentas e soluções. Por exemplo, como aplicação dos conhecimentos adquiridos, é possível substituir a ferramenta nesta implementação da multivan check-gateway com rotas recursivas para netwatch.
Notas
- check-gateway - um mecanismo que permite desativar a rota após duas verificações consecutivas sem sucesso do gateway quanto à disponibilidade. A verificação é executada uma vez a cada 10 segundos, mais o tempo limite de resposta. No total, o tempo de comutação real está na faixa de 20 a 30 segundos. Se esse tempo de comutação não for suficiente, existe a opção de usar a ferramenta netwatch, onde o temporizador de verificação pode ser definido manualmente. check-gateway não dispara na perda de pacote intermitente no link.
Importante! Desativar uma rota primária desativará todas as outras rotas que se referem a ela. Portanto, para que indiquem verificar-gateway = ping não precisa.
- Acontece que ocorre uma falha no mecanismo DHCP, que se parece com um cliente preso no estado de renovação. Nesse caso, a segunda parte do script não funcionará, mas não impedirá que o tráfego caminhe corretamente, pois o estado rastreia a rota recursiva correspondente.
- ECMP (Caminho Múltiplo de Custo Igual) - no ROS é possível definir 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.
Pelo ímpeto de escrever o artigo, ajude a moldar sua estrutura e colocação de acentos - gratidão pessoal a Evgeny
Fonte: habr.com