🥇Noções básicas de roteamento estático no Mikrotik RouterOS

Roteamento é o processo de encontrar o melhor caminho para a transmissão de pacotes em redes TCP/IP. Qualquer dispositivo conectado a uma rede IPv4 contém um processo e tabelas de roteamento.

Este artigo não é um COMO FAZER, ele descreve o roteamento estático no RouterOS com exemplos, omiti deliberadamente o restante das configurações (por exemplo, srcnat para acessar a Internet), portanto, entender o material requer um certo nível de conhecimento de redes e RouterOS.

Comutação e roteamento

A comutação é o processo de troca de pacotes dentro de um segmento da camada 2 (Ethernet, ppp, ...). Se o dispositivo perceber que o destinatário do pacote está na mesma sub-rede Ethernet que ele, ele aprenderá o endereço mac usando o protocolo arp e transmitirá o pacote diretamente, ignorando o roteador. Uma conexão ppp (ponto a ponto) pode ter apenas dois participantes e o pacote é sempre enviado para um endereço 0xff.

O roteamento é o processo de transferência de pacotes entre os segmentos da camada 2. Se um dispositivo deseja enviar um pacote cujo destinatário está fora do segmento Ethernet, ele consulta sua tabela de roteamento e passa o pacote para o gateway, que sabe para onde enviar o próximo pacote (ou pode não saber, o remetente original do pacote não sabe disso).

A maneira mais fácil de pensar em um roteador é como um dispositivo conectado a dois ou mais segmentos da camada 2 e capaz de passar pacotes entre eles determinando a melhor rota na tabela de roteamento.

Se você entendeu tudo, ou já sabia, continue lendo. Quanto ao resto, recomendo fortemente que você se familiarize com um pequeno, mas muito espaçoso artigo.

Roteamento no RouterOS e PacketFlow

Quase todas as funcionalidades relacionadas ao roteamento estático estão no pacote .. Saco de plástico roteamento adiciona suporte para algoritmos de roteamento dinâmico (RIP, OSPF, BGP, MME), filtros de roteamento e BFD.

Menu principal para configurar o roteamento: [IP]->[Route]. Esquemas complexos podem exigir que os pacotes sejam pré-rotulados com uma marca de roteamento em: [IP]->[Firewall]->[Mangle] (correntes PREROUTING и OUTPUT).

Existem três locais no PacketFlow onde as decisões de roteamento de pacotes IP são tomadas:

Pacotes de roteamento recebidos pelo roteador. Nesta fase, é decidido se o pacote irá para o processo local ou será enviado posteriormente para a rede. pacotes de trânsito recebem Interface de saída
Roteamento de pacotes de saída locais. Pacotes de saída recebidos Interface de saída
Etapa de roteamento adicional para pacotes de saída, permite que você altere a decisão de roteamento em [Output|Mangle]

O caminho do pacote nos blocos 1, 2 depende das regras em [IP]->[Route]
O caminho do pacote nos pontos 1, 2 e 3 depende das regras em [IP]->[Route]->[Rules]
O caminho do pacote nos blocos 1, 3 pode ser influenciado usando [IP]->[Firewall]->[Mangle]

RIB, FIB, cache de roteamento

Base de Informações de Roteamento
A base na qual as rotas são coletadas de protocolos de roteamento dinâmico, rotas de ppp e dhcp, rotas estáticas e conectadas. Este banco de dados contém todas as rotas, exceto aquelas filtradas pelo administrador.

Condicionalmente, podemos supor que [IP]->[Route] exibe RIB.

Base de Informações de Encaminhamento

A base na qual as melhores rotas do RIB são coletadas. Todas as rotas no FIB estão ativas e são usadas para encaminhar pacotes. Caso a rota fique inativa (desativada pelo administrador (sistema), ou a interface pela qual o pacote deveria ser enviado não está ativa), a rota é removida do FIB.

Para tomar uma decisão de roteamento, a tabela FIB usa as seguintes informações sobre um pacote IP:

Endereço de Origem
Endereço de destino
Interface de origem
marca de roteamento
Termos de Serviço (DSCP)

Entrar no pacote FIB passa pelas seguintes etapas:

O pacote é destinado a um processo de roteador local?
O pacote está sujeito às regras PBR do sistema ou do usuário?
- Se sim, então o pacote é enviado para a tabela de roteamento especificada
O pacote é enviado para a tabela principal

Condicionalmente, podemos supor que [IP]->[Route Active=yes] exibe FIB.

cache de roteamento
Mecanismo de cache de rota. O roteador lembra para onde os pacotes foram enviados e se houver outros semelhantes (presumivelmente da mesma conexão) permite que eles sigam a mesma rota, sem verificar no FIB. O cache da rota é limpo periodicamente.

Para os administradores do RouterOS, eles não criaram ferramentas para visualizar e gerenciar o cache de roteamento, mas quando ele pode ser desativado em [IP]->[Settings].

Este mecanismo foi removido do kernel linux 3.6, mas o RouterOS ainda usa o kernel 3.3.5, talvez o roteamento cahce seja um dos motivos.

Adicionar caixa de diálogo de rota

[IP]->[Route]->[+]

Sub-rede para a qual você deseja criar uma rota (padrão: 0.0.0.0/0)
IP do gateway ou interface para onde o pacote será enviado (pode haver vários, veja ECMP abaixo)
Verificação de disponibilidade do gateway
Tipo de registro
Distância (métrica) para uma rota
Tabela de roteamento
IP para pacotes de saída locais por esta rota
O objetivo do Escopo e do Escopo Alvo está escrito no final do artigo.

Sinalizadores de rota

X - A rota está desabilitada pelo administrador (disabled=yes)
A - A rota é usada para enviar pacotes
D - Rota adicionada dinamicamente (BGP, OSPF, RIP, MME, PPP, DHCP, Conectado)
C - A sub-rede está conectada diretamente ao roteador
S - Rota estática
r,b,o,m - Rota adicionada por um dos protocolos de roteamento dinâmico
B,U,P - Rota de filtragem (descarta pacotes em vez de transmitir)

O que especificar no gateway: endereço IP ou interface?

O sistema permite que você especifique os dois, enquanto não xinga e não dá dicas se você fez algo errado.

Endereço IP
O endereço do gateway deve ser acessível na Camada2. Para Ethernet, isso significa que o roteador deve ter um endereço da mesma sub-rede em uma das interfaces ip ativas, para ppp, que o endereço do gateway é especificado em uma das interfaces ativas como endereço de sub-rede.
Se a condição de acessibilidade para Layer2 não for atendida, a rota é considerada inativa e não se enquadra na FIB.

Interface.
Tudo é mais complicado e o comportamento do roteador depende do tipo de interface:

A conexão PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) assume apenas dois participantes e o pacote sempre será enviado ao gateway para transmissão, se o gateway detectar que o destinatário é ele mesmo, ele transferirá o pacote para seu processo local.
A Ethernet assume a presença de muitos participantes e enviará solicitações para a interface arp com o endereço do destinatário do pacote, isso é esperado e um comportamento bastante normal para rotas conectadas.
Porém, ao tentar usar a interface como uma rota para uma sub-rede remota, você obterá a seguinte situação: a rota está ativa, o ping para o gateway passa, mas não atinge o destinatário da sub-rede especificada. Se você observar a interface por meio de um farejador, verá solicitações arp com endereços de uma sub-rede remota.

Tente especificar o endereço IP como gateway sempre que possível. A exceção são rotas conectadas (criadas automaticamente) e interfaces PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*).

O OpenVPN não contém um cabeçalho PPP, mas você pode usar o nome da interface OpenVPN para criar uma rota.

Rota mais específica

Regra básica de roteamento. A rota que descreve a sub-rede menor (com a maior máscara de sub-rede) tem precedência na decisão de roteamento do pacote. A posição das entradas na tabela de roteamento não é relevante para a escolha - a regra principal é Mais Específica.

Todas as rotas do esquema especificado estão ativas (localizadas em FIB). apontam para diferentes sub-redes e não entram em conflito entre si.

Se um dos gateways ficar indisponível, a rota associada será considerada inativa (retirada do FIB) e os pacotes serão pesquisados nas rotas restantes.

Às vezes, a rota com sub-rede 0.0.0.0/0 recebe um significado especial e é chamada de "Rota padrão" ou "Gateway de último recurso". Na verdade, não há nada de mágico nisso e simplesmente inclui todos os endereços IPv4 possíveis, mas esses nomes descrevem bem sua tarefa - indica o gateway para onde encaminhar pacotes para os quais não há outras rotas mais precisas.

A máscara de sub-rede máxima possível para IPv4 é /32, esta rota aponta para um host específico e pode ser utilizada na tabela de roteamento.

Compreender Rotas Mais Específicas é fundamental para qualquer dispositivo TCP/IP.

Distância

As distâncias (ou métricas) são necessárias para filtragem administrativa de rotas para uma única sub-rede acessível por meio de vários gateways. Uma rota com uma métrica inferior é considerada prioritária e será incluída no FIB. Se uma rota com uma métrica menor deixar de estar ativa, ela será substituída por uma rota com uma métrica maior no FIB.

Se houver várias rotas para a mesma sub-rede com a mesma métrica, o roteador adicionará apenas uma delas à tabela FIB, guiada por sua lógica interna.

A métrica pode assumir um valor de 0 a 255:

0 - Métrica para rotas conectadas. A distância 0 não pode ser definida pelo administrador
1-254 - Métricas disponíveis para o administrador para configuração de rotas. As métricas com um valor mais baixo têm uma prioridade mais alta
255 - Métrica disponível ao administrador para configuração de rotas. Ao contrário de 1-254, uma rota com uma métrica de 255 sempre permanece inativa e não cai no FIB
métricas específicas. As rotas derivadas de protocolos de roteamento dinâmico têm valores de métrica padrão

verifique o gateway

Check gateway é uma extensão MikroTik RoutesOS para verificar a disponibilidade do gateway via icmp ou arp. A cada 10 segundos (não pode ser alterado), uma requisição é enviada ao gateway, caso a resposta não seja recebida duas vezes, a rota é considerada indisponível e é removida do FIB. Se o gateway de verificação foi desabilitado, a rota de verificação continua e a rota se tornará ativa novamente após uma verificação bem-sucedida.

Check gateway desativa a entrada na qual está configurado e todas as outras entradas (em todas as tabelas de roteamento e rotas ecmp) com o gateway especificado.

Em geral, verifique se o gateway funciona bem, desde que não haja problemas com perda de pacotes para o gateway. Check gateway não sabe o que está acontecendo com a comunicação fora do gateway verificado, isso requer ferramentas adicionais: scripts, roteamento recursivo, protocolos de roteamento dinâmico.

A maioria dos protocolos de VPN e túnel contém ferramentas integradas para verificar a atividade da conexão, permitindo que a verificação do gateway para eles seja uma carga adicional (mas muito pequena) na rede e no desempenho do dispositivo.

rotas ECMP

Equal-Cost Multi-Path - envio de pacotes para o destinatário usando vários gateways simultaneamente usando o algoritmo Round Robin.

A rota ECMP é criada pelo administrador especificando vários gateways para a mesma sub-rede (ou automaticamente, se houver duas rotas OSPF equivalentes).

O ECMP é usado para balanceamento de carga entre dois canais, em teoria, se houver dois canais na rota ecmp, então, para cada pacote, o canal de saída deve ser diferente. Mas o mecanismo de cache de roteamento envia pacotes da conexão ao longo da rota que o primeiro pacote percorreu, como resultado, obtemos um tipo de balanceamento baseado em conexões (balanceamento de carga por conexão).

Se você desabilitar o cache de roteamento, os pacotes na rota ECMP serão compartilhados corretamente, mas há um problema com o NAT. A regra NAT processa apenas o primeiro pacote da conexão (o restante é processado automaticamente) e os pacotes com o mesmo endereço de origem saem de interfaces diferentes.

Verifique se o gateway não funciona em rotas ECMP (erro do RouterOS). Mas você pode contornar essa limitação criando rotas de validação adicionais que desabilitarão as entradas no ECMP.

Filtragem por Roteamento

A opção Tipo determina o que fazer com o pacote:

unicast - enviar para o gateway especificado (interface)
buraco negro - descartar um pacote
proibir, inacessível - descartar o pacote e enviar uma mensagem icmp ao remetente

A filtragem geralmente é usada quando é necessário garantir o envio de pacotes pelo caminho errado, é claro, você pode filtrar isso pelo firewall.

Alguns exemplos

Para consolidar as coisas básicas sobre roteamento.

Roteador doméstico típico

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1

Rota estática para 0.0.0.0/0 (rota padrão)
Rota conectada na interface com o provedor
Rota conectada na interface LAN

Roteador doméstico típico com PPPoE

Rota estática para rota padrão, adicionada automaticamente. é especificado nas propriedades da conexão
Rota conectada para conexão PPP
Rota conectada na interface LAN

Roteador doméstico típico com dois provedores e redundância

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

Rota estática para rota padrão através do primeiro provedor com métrica 1 e verificação de disponibilidade de gateway
Rota estática para rota padrão através do segundo provedor com métrica 2
Rotas conectadas

O tráfego para 0.0.0.0/0 passa por 10.10.10.1 enquanto este gateway estiver disponível, caso contrário, ele muda para 10.20.20.1

Tal esquema pode ser considerado uma reserva de canal, mas não é isento de desvantagens. Se ocorrer uma quebra fora do gateway do provedor (por exemplo, dentro da rede da operadora), seu roteador não saberá e continuará considerando a rota como ativa.

Roteador doméstico típico com dois provedores, redundância e ECMP

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

Rotas estáticas para verificar o gateway de chack
rota ECMP
Rotas conectadas

As rotas a serem verificadas são azuis (a cor das rotas inativas), mas isso não interfere no gateway de verificação. A versão atual (6.44) do RoS dá prioridade automática à rota ECMP, mas é melhor adicionar rotas de teste a outras tabelas de roteamento (opção routing-mark)

No Speedtest e outros sites semelhantes, não haverá aumento de velocidade (o ECMP divide o tráfego por conexões, não por pacotes), mas os aplicativos p2p devem baixar mais rapidamente.

Filtragem via Roteamento

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1
add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1
add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole

Rota estática para rota padrão
Rota estática para 192.168.200.0/24 sobre túnel ipip
Proibindo rota estática para 192.168.200.0/24 através do roteador ISP

Uma opção de filtragem na qual o tráfego do túnel não irá para o roteador do provedor quando a interface ipip estiver desativada. Esses esquemas raramente são necessários, porque você pode implementar o bloqueio através do firewall.

Loop de roteamento
Loop de roteamento - uma situação em que um pacote é executado entre roteadores antes que o ttl expire. Geralmente é resultado de um erro de configuração, em grandes redes é tratado pela implementação de protocolos de roteamento dinâmico, em pequenas - com cuidado.

Parece algo como isto:

Um exemplo (mais simples) de como obter um resultado semelhante:

O exemplo do loop de roteamento não tem uso prático, mas mostra que os roteadores não têm ideia sobre a tabela de roteamento de seus vizinhos.

Roteamento Base de Política e Tabelas de Roteamento Adicionais

Ao escolher uma rota, o roteador usa apenas um campo do cabeçalho do pacote (Dst. Address) - este é o roteamento básico. O roteamento baseado em outras condições, como endereço de origem, tipo de tráfego (ToS), balanceamento sem ECMP, pertence ao Policy Base Routing (PBR) e usa tabelas de roteamento adicionais.

Rota mais específica é a principal regra de seleção de rota dentro da tabela de roteamento.

Por padrão, todas as regras de roteamento são adicionadas à tabela principal. O administrador pode criar um número arbitrário de tabelas de roteamento adicionais e rotear pacotes para elas. As regras em tabelas diferentes não entram em conflito umas com as outras. Se o pacote não encontrar uma regra adequada na tabela especificada, irá para a tabela principal.

Exemplo com distribuição via Firewall:

192.168.100.10/8.8.8.8/XNUMX -> XNUMX/XNUMX/XNUMX
1. O tráfego de 192.168.100.10 é rotulado via-isp1 в [Prerouting|Mangle]
2. No estágio de Roteamento na tabela via-isp1 procura uma rota para 8.8.8.8
3. Rota encontrada, o tráfego é enviado para o gateway 10.10.10.1
192.168.200.20/8.8.8.8/XNUMX -> XNUMX/XNUMX/XNUMX
1. O tráfego de 192.168.200.20 é rotulado via-isp2 в [Prerouting|Mangle]
2. No estágio de Roteamento na tabela via-isp2 procura uma rota para 8.8.8.8
3. Rota encontrada, o tráfego é enviado para o gateway 10.20.20.1
Se um dos gateways (10.10.10.1 ou 10.20.20.1) ficar indisponível, o pacote irá para a mesa principal e vai procurar uma rota adequada lá

Problemas de terminologia

RouterOS tem certos problemas de terminologia.
Ao trabalhar com regras em [IP]->[Routes] a tabela de roteamento é indicada, embora esteja escrito que o rótulo:

В [IP]->[Routes]->[Rule] está tudo correto, na condição do label na ação da tabela:

Como enviar um pacote para uma tabela de roteamento específica

O RouterOS fornece várias ferramentas:

Regras em [IP]->[Routes]->[Rules]
Marcadores de rota (action=mark-routing) em [IP]->[Firewall]->[Mangle]
VRF

Regras [IP]->[Route]->[Rules]
As regras são processadas sequencialmente, se o pacote corresponder às condições da regra, ele não passa adiante.

As Regras de Roteamento permitem ampliar as possibilidades de roteamento, contando não apenas com o endereço do destinatário, mas também com o endereço de origem e a interface na qual o pacote foi recebido.

As regras consistem em condições e uma ação:

Condições. Praticamente repita a lista de sinais pelos quais o pacote é verificado no FIB, apenas falta o ToS.
Atividade
- lookup - envia um pacote para uma mesa
- lookup only in table - trava o pacote na tabela, se a rota não for encontrada, o pacote não irá para a tabela principal
- soltar - largar um pacote
- inacessível - descarta o pacote com notificação do remetente

No FIB, o tráfego para processos locais é processado ignorando as regras [IP]->[Route]->[Rules]:

marca [IP]->[Firewall]->[Mangle]
Os rótulos de roteamento permitem que você defina o gateway para um pacote usando quase todas as condições de firewall:

Praticamente, porque nem todos fazem sentido e alguns podem funcionar de forma instável.

Existem duas maneiras de rotular um pacote:

colocar imediatamente marca de roteamento
colocar primeiro marca de conexão, então baseado em marca de conexão pôr marca de roteamento

Em um artigo sobre firewalls, escrevi que a segunda opção é preferível. reduz a carga na cpu, no caso de marcação de rotas - isso não é totalmente verdade. Esses métodos de marcação nem sempre são equivalentes e geralmente são usados para resolver vários problemas.

Exemplos de uso

Vamos aos exemplos de uso do Policy Base Routing, eles são muito mais fáceis de mostrar porque tudo isso é necessário.

MultiWAN e tráfego de saída (saída) de retorno
Um problema comum com uma configuração MultiWAN: o Mikrotik está disponível na Internet apenas por meio de um provedor "ativo".

O roteador não se importa a qual ip veio a requisição, ao gerar uma resposta, ele irá procurar uma rota na tabela de roteamento onde a rota pelo isp1 esteja ativa. Além disso, esse pacote provavelmente será filtrado ao longo do caminho até o destinatário.

Outro ponto interessante. Se um source nat "simples" estiver configurado na interface ether1: /ip fi nat add out-interface=ether1 action=masquerade o pacote ficará online com src. address=10.10.10.100, o que torna as coisas ainda piores.

Existem várias maneiras de corrigir o problema, mas qualquer uma delas exigirá tabelas de roteamento adicionais:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2
add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2

Usar [IP]->[Route]->[Rules]
Especifique a tabela de roteamento que será usada para pacotes com o IP de origem especificado.

/ip route rule
add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1
add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2

Pode usar action=lookup, mas para o tráfego de saída local, esta opção exclui completamente as conexões da interface errada.

O sistema gera um pacote de resposta com Src. Endereço: 10.20.20.200
A etapa de Decisão de Roteamento(2) verifica [IP]->[Routes]->[Rules] e o pacote é enviado para a tabela de roteamento over-isp2
De acordo com a tabela de roteamento, o pacote deve ser enviado para o gateway 10.20.20.1 via interface ether2

Este método não requer um Rastreador de Conexão funcional, ao contrário do uso da tabela Mangle.

Usar [IP]->[Firewall]->[Mangle]
A conexão começa com um pacote recebido, então nós o marcamos (action=mark-connection), para pacotes de saída de uma conexão marcada, defina o rótulo de roteamento (action=mark-routing).

/ip firewall mangle
#Маркировка входящих соединений
add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1
add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2
#Маркировка исходящих пакетов на основе соединений
add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no

Se vários ips estiverem configurados em uma interface, você pode adicionar à condição dst-address para ter certeza.

Um pacote abre a conexão na interface ether2. O pacote entra em [INPUT|Mangle] que diz para marcar todos os pacotes da conexão como de-isp2
O sistema gera um pacote de resposta com Src. Endereço: 10.20.20.200
No estágio Routing Decision(2), o pacote, de acordo com a tabela de roteamento, é enviado para o gateway 10.20.20.1 via interface ether1. Você pode verificar isso registrando os pacotes em [OUTPUT|Filter]
Na fase [OUTPUT|Mangle] rótulo de conexão é verificado de-isp2 e o pacote recebe um rótulo de rota over-isp2
A etapa Routing Adjusment(3) verifica a presença de um rótulo de roteamento e o envia para a tabela de roteamento apropriada
De acordo com a tabela de roteamento, o pacote deve ser enviado para o gateway 10.20.20.1 via interface ether2

MultiWAN e tráfego dst-nat de retorno

Um exemplo é mais complicado, o que fazer se houver um servidor (por exemplo, web) atrás do roteador em uma sub-rede privada e você precisar fornecer acesso a ele por meio de qualquer um dos provedores.

/ip firewall nat
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100

A essência do problema será a mesma, a solução é semelhante à opção Firewall Mangle, apenas outras cadeias serão usadas:

/ip firewall mangle
add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1
add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2
add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no

O diagrama não mostra o NAT, mas acho que está tudo claro.

MultiWAN e conexões de saída

Você pode usar os recursos PBR para criar várias conexões vpn (SSTP no exemplo) de diferentes interfaces de roteador.

Tabelas de roteamento adicionais:

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3

add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3

Marcações da embalagem:

/ip firewall mangle
add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no
add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no
add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no

Regras NAT simples, caso contrário o pacote sairá da interface com o Src errado. endereço:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
add chain=srcnat out-interface=ether2 action=masquerade
add chain=srcnat out-interface=ether3 action=masquerade

Análise:

O roteador cria três processos SSTP
No estágio de Decisão de Roteamento (2), uma rota é selecionada para esses processos com base na tabela de roteamento principal. Da mesma rota, o pacote recebe Src. Endereço vinculado à interface ether1
В [Output|Mangle] pacotes de conexões diferentes recebem rótulos diferentes
Os pacotes entram nas tabelas correspondentes aos rótulos na etapa de Ajuste de Roteamento e recebem uma nova rota para envio de pacotes
Mas os pacotes ainda têm Src. Endereço de ether1, no palco [Nat|Srcnat] o endereço é substituído de acordo com a interface

Curiosamente, no roteador você verá a seguinte tabela de conexão:

Rastreador de conexão funciona mais cedo [Mangle] и [Srcnat], então todas as conexões vêm do mesmo endereço, se você olhar com mais detalhes, então em Replay Dst. Address haverá endereços após o NAT:

No servidor VPN (tenho um no banco de testes), você pode ver que todas as conexões vêm dos endereços corretos:

Segure o caminho
Existe uma maneira mais fácil, você pode simplesmente especificar um gateway específico para cada um dos endereços:

/ip route
add dst-address=10.10.10.100 gateway=192.168.100.1
add dst-address=10.10.10.101 gateway=192.168.200.1
add dst-address=10.10.10.102 gateway=192.168.0.1

Mas essas rotas afetarão não apenas o tráfego de saída, mas também o tráfego de trânsito. Além disso, se você não precisar que o tráfego para o servidor vpn passe por canais de comunicação inadequados, será necessário adicionar mais 6 regras para [IP]->[Routes]с type=blackhole. Na versão anterior - 3 regras em [IP]->[Route]->[Rules].

Distribuição de conexões de usuários por canais de comunicação

Tarefas simples do dia a dia. Novamente, tabelas de roteamento adicionais serão necessárias:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2

Uso [IP]->[Route]->[Rules]

/ip route rules
add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1
add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2

Se usar action=lookup, então quando um dos canais estiver desativado, o tráfego irá para a tabela principal e passará pelo canal de trabalho. Se isso é necessário ou não depende da tarefa.

Usando as marcações em [IP]->[Firewall]->[Mangle]
Um exemplo simples com listas de endereços IP. Em princípio, quase todas as condições podem ser usadas. A única ressalva da camada 7, mesmo quando emparelhado com rótulos de conexão, pode parecer que tudo está funcionando corretamente, mas parte do tráfego ainda seguirá o caminho errado.

/ip firewall mangle
add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1
add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2

Você pode “bloquear” usuários em uma tabela de roteamento através [IP]->[Route]->[Rules]:

/ip route rules
add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1
add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2

Seja através [IP]->[Firewall]->[Filter]:

/ip firewall filter
add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject
add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject

Retiro profissional dst-address-type=!local
Condição adicional dst-address-type=!local é necessário que o tráfego dos usuários chegue aos processos locais do roteador (dns, winbox, ssh, ...). Se várias sub-redes locais estiverem conectadas ao roteador, é necessário garantir que o tráfego entre elas não vá para a Internet, por exemplo, usando dst-address-table.

No exemplo usando [IP]->[Route]->[Rules] não há tais exceções, mas o tráfego chega aos processos locais. O fato é que entrar no pacote FIB marcado em [PREROUTING|Mangle] tem um rótulo de rota e vai para uma tabela de roteamento diferente da principal, onde não há interface local. No caso das Regras de Roteamento, primeiro é verificado se o pacote é destinado a um processo local e somente na etapa User PBR ele vai para a tabela de roteamento especificada.

Uso [IP]->[Firewall]->[Mangle action=route]
Esta ação só funciona em [Prerouting|Mangle] e permite direcionar o tráfego para o gateway especificado sem usar tabelas de roteamento adicionais, especificando o endereço do gateway diretamente:

/ip firewall mangle
add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1
add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1

Ação route tem uma prioridade mais baixa do que as regras de roteamento ([IP]->[Route]->[Rules]). No caso das marcas de rota, tudo depende da posição das réguas, se a régua com action=route vale mais do que action=mark-route, então ele será usado (independentemente do sinalizador passtrough), caso contrário marcação do percurso.
Há muito pouca informação no wiki sobre esta ação e todas as conclusões foram obtidas experimentalmente, em qualquer caso, não encontrei opções quando usar esta opção oferece vantagens sobre outras.

Balanceamento dinâmico baseado em PPC

Classificador por conexão - é um análogo mais flexível do ECMP. Ao contrário do ECMP, ele divide o tráfego por conexões de forma mais estrita (o ECMP não sabe nada sobre conexões, mas quando emparelhado com o Routing Cache, obtém-se algo semelhante).

PCC leva campos especificados do cabeçalho IP, converte-os em um valor de 32 bits e divide por denominador. O restante da divisão é comparado com o especificado restante e se forem correspondentes, a ação especificada será aplicada. Mais. Parece loucura, mas funciona.

Exemplo com três endereços:

192.168.100.10: 192+168+100+10 = 470 % 3 = 2
192.168.100.11: 192+168+100+11 = 471 % 3 = 0
192.168.100.12: 192+168+100+12 = 472 % 3 = 1

Um exemplo de distribuição dinâmica de tráfego por src.address entre três canais:

#Таблица маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3

#Маркировка соединений и маршрутов
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3

add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3

Ao marcar rotas, há uma condição adicional: in-interface=br-lan, sem ele sob action=mark-routing o tráfego de resposta da Internet receberá e, de acordo com as tabelas de roteamento, retornará ao provedor.

Troca de canais de comunicação

Check ping é uma boa ferramenta, mas só verifica a conexão com o par IP mais próximo, redes de provedores geralmente consistem em um grande número de roteadores e uma quebra de conexão pode ocorrer fora do par mais próximo, e então existem operadoras de telecomunicações de backbone que também podem tem problemas, em geral a verificação de ping nem sempre mostra informações atualizadas sobre o acesso à rede global.
Se os provedores e grandes corporações tiverem o protocolo de roteamento dinâmico BGP, os usuários domésticos e de escritório terão que descobrir de forma independente como verificar o acesso à Internet por meio de um canal de comunicação específico.

Normalmente, são utilizados scripts que, por meio de um determinado canal de comunicação, verificam a disponibilidade de um endereço IP na Internet, escolhendo algo confiável, por exemplo, google dns: 8.8.8.8. 8.8.4.4. Mas na comunidade Mikrotik, uma ferramenta mais interessante foi adaptada para isso.

Algumas palavras sobre roteamento recursivo
O roteamento recursivo é necessário ao construir o emparelhamento Multihop BGP e entrou no artigo sobre os fundamentos do roteamento estático apenas devido aos astutos usuários do MikroTik que descobriram como usar rotas recursivas emparelhadas com gateway de verificação para alternar canais de comunicação sem scripts adicionais.

É hora de entender as opções de escopo/alvo em termos gerais e como a rota está vinculada à interface:

A rota procura uma interface para enviar o pacote com base em seu valor de escopo e todas as entradas na tabela principal com valores de escopo de destino menores ou iguais
Das interfaces encontradas, aquela através da qual você pode enviar um pacote para o gateway especificado é selecionada
A interface da entrada conectada encontrada é selecionada para enviar o pacote para o gateway

Na presença de uma rota recursiva, tudo acontece igual, mas em duas etapas:

1-3 Mais uma rota é adicionada às rotas conectadas, através das quais o gateway especificado pode ser alcançado
4-6 Encontrando a rota conectada rota para o gateway "intermediário"

Todas as manipulações com a busca recursiva ocorrem no RIB, e apenas o resultado final é transferido para o FIB: 0.0.0.0/0 via 10.10.10.1 on ether1.

Um exemplo de uso de roteamento recursivo para alternar rotas

Configuração:

/ip route
add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10
add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

Você pode verificar se os pacotes serão enviados para 10.10.10.1:

Check gateway não sabe nada sobre roteamento recursivo e simplesmente envia pings para 8.8.8.8, que (com base na tabela principal) é acessível através do gateway 10.10.10.1.

Se houver perda de comunicação entre 10.10.10.1 e 8.8.8.8, a rota é desconectada, mas os pacotes (incluindo pings de teste) para 8.8.8.8 continuam passando por 10.10.10.1:

Se o link para ether1 for perdido, uma situação desagradável ocorrerá quando os pacotes anteriores a 8.8.8.8 passarem pelo segundo provedor:

Isso é um problema se você estiver usando o NetWatch para executar scripts quando o 8.8.8.8 não estiver disponível. Se o link for interrompido, o NetWatch simplesmente funcionará por meio do canal de comunicação de backup e assumirá que está tudo bem. Resolvido adicionando uma rota de filtro adicional:

/ip route
add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole

há no habré artigo, onde a situação com o NetWatch é considerada com mais detalhes.

E sim, ao usar tal reserva, o endereço 8.8.8.8 será codificado para um dos provedores, então escolhê-lo como uma fonte de DNS não é uma boa ideia.

Algumas palavras sobre Virtual Routing and Forwarding (VRF)

A tecnologia VRF é projetada para criar vários roteadores virtuais dentro de um físico, esta tecnologia é amplamente utilizada por operadoras de telecomunicações (geralmente em conjunto com MPLS) para fornecer serviços L3VPN para clientes com endereços de sub-rede sobrepostos:

Mas o VRF no Mikrotik é organizado com base em tabelas de roteamento e tem várias desvantagens, por exemplo, endereços IP locais do roteador estão disponíveis em todos os VRFs, você pode ler mais по ссылке.

exemplo de configuração vrf:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

Do dispositivo conectado ao ether2, vemos que o ping vai para o endereço do roteador de outro vrf (e isso é um problema), enquanto o ping não vai para a Internet:

Para acessar a Internet, é necessário cadastrar uma rota adicional que acessa a tabela principal (na terminologia vrf, isso é chamado de vazamento de rota):

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

Aqui estão duas maneiras de vazamento de rota: usando a tabela de roteamento: 172.17.0.1@main e usando o nome da interface: 172.17.0.1%wlan1.

E configurar a marcação para o tráfego de retorno em [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no

Sub-redes com o mesmo endereço
Organização de acesso a sub-redes com o mesmo endereçamento no mesmo roteador usando VRF e netmap:

Configuração básica:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
add address=192.168.0.1/24 interface=ether3 network=192.168.0.0

regras de firewall:

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/ip firewall mangle
add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no
add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no

#Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети
/ip firewall nat
add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24

Regras de roteamento para tráfego de retorno:

#Указание имени интерфейса тоже может считаться route leaking, но по сути тут создается аналог connected маршрута
/ip route
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf1
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf2

Adicionando rotas recebidas via dhcp a uma determinada tabela de roteamento
O VRF pode ser interessante se você precisar adicionar automaticamente uma rota dinâmica (por exemplo, de um cliente dhcp) a uma tabela de roteamento específica.

Adicionando interface ao vrf:

/ip route vrf
add interface=ether1 routing-mark=over-isp1

Regras para envio de tráfego (saída e trânsito) pela tabela over-isp1:

/ip firewall mangle
add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no

Rota falsa adicional para o roteamento de saída funcionar:

/interface bridge
add name=bare

/ip route
add dst-address=0.0.0.0/0 gateway=bare

Esta rota é necessária apenas para que os pacotes de saída locais possam passar pela decisão de roteamento (2) antes [OUTPUT|Mangle] e obter o rótulo de roteamento, se houver outras rotas ativas no roteador antes de 0.0.0.0/0 na tabela principal, isso não é necessário.

Correntes `connected-in` и `dynamic-in` в `[Routing] -> [Filters]`

A filtragem de rotas (entrada e saída) é uma ferramenta que geralmente é usada em conjunto com protocolos de roteamento dinâmico (e, portanto, disponível apenas após a instalação do pacote roteamento), mas há duas cadeias interessantes nos filtros de entrada:

conectado — filtrando rotas conectadas
dynamic-in - filtragem de rotas dinâmicas recebidas por PPP e DCHP

A filtragem permite não apenas descartar rotas, mas também alterar várias opções: distância, marca de rota, comentário, escopo, escopo de destino, ...

Esta é uma ferramenta muito precisa e se você pode fazer algo sem filtros de roteamento (mas não scripts), não use filtros de roteamento, não confunda a si mesmo e aqueles que configurarão o roteador depois de você. No contexto do roteamento dinâmico, os filtros de roteamento serão usados com muito mais frequência e produtividade.

Definindo a Marca de Roteamento para Rotas Dinâmicas
Um exemplo de um roteador doméstico. Tenho duas conexões VPN configuradas e o tráfego nelas deve ser encapsulado de acordo com as tabelas de roteamento. Ao mesmo tempo, quero que as rotas sejam criadas automaticamente quando a interface for ativada:

#При создании vpn подключений указываем создание default route и задаем дистанцию
/interface pptp-client
add connect-to=X.X.X.X add-default-route=yes default-route-distance=101 ...
add connect-to=Y.Y.Y.Y  add-default-route=yes default-route-distance=100 ...

#Фильтрами отправляем маршруты в определенные таблицы маршрутизации на основе подсети назначения и дистанции
/routing filter
add chain=dynamic-in distance=100 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn1
add chain=dynamic-in distance=101 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn2

Não sei porque, provavelmente um bug, mas se você criar um vrf para a interface ppp, a rota para 0.0.0.0/0 ainda entrará na tabela principal. Caso contrário, tudo seria ainda mais fácil.

Desabilitando Rotas Conectadas
Às vezes, isso é necessário:

/route filter
add chain=connected-in prefix=192.168.100.0/24 action=reject

Ferramentas de depuração

O RouterOS fornece várias ferramentas para depurar o roteamento:

[Tool]->[Tourch] - permite visualizar pacotes em interfaces
/ip route check - permite ver para qual gateway o pacote será enviado, não funciona com tabelas de roteamento
/ping routing-table=<name> и /tool traceroute routing-table=<name> - ping e rastreamento usando a tabela de roteamento especificada
action=log в [IP]->[Firewall] - uma excelente ferramenta que permite rastrear o caminho de um pacote ao longo do fluxo de pacotes, esta ação está disponível em todas as chains e tabelas

Fonte: habr.com

Noções básicas de roteamento estático no Mikrotik RouterOS