Eu tenho um problema. Todas as minhas máquinas estão atrás de um roteador conectado a uma porta ETH do modem. Essa porta é muito limitada para download/upload. Então, tentei conectar dois cabos do roteador ao modem em duas portas. Tenho trabalhado muito em como resolver isso, não sei mais o que tentar.
Meu roteador tem 4 interfaces:
enp1s0f0 172.16.0.3
enp4s0f1 10.0.0.6
enp1s0f1 192.168.0.3
enp4s0f0 192.168.0.6
Como você pode ver, eth3 e eth4 estão na mesma rede, o que é estranho. Tinha que ser assim se eu quisesse me conectar ao modem (192.168.0.1) usando duas portas ETH.
Então, aqui está o que eu tentei:
echo "1 myorg" >> /etc/iproute2/rt_tables #added a custom routing table myorg
sudo ip route add 192.168.0.1 scope link dev enp4s0f0 #don't know if it is really necessary
sudo ip rule add from 192.168.0.6 table myorg
sudo ip route add default via 192.168.0.1 dev enp4s0f0 table myorg #second default gateway through myorg table
Eu recebo essas rotas como resultado:
$ ip -4 route show table main
default via 192.168.0.1 dev enp1s0f1 onlink
10.0.0.0/24 dev enp4s0f1 proto kernel scope link src 10.0.0.6
172.16.0.0/24 dev enp1s0f0 proto kernel scope link src 172.16.0.3
192.168.0.0/24 dev enp1s0f1 proto kernel scope link src 192.168.0.3
192.168.0.0/24 dev enp4s0f0 proto kernel scope link src 192.168.0.6
192.168.0.1 dev enp4s0f0 scope link
$ ip -4 route show table myorg
default via 192.168.0.1 dev enp4s0f0
$ sudo route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 0 0 0 enp1s0f1
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0f1
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0f0
192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 enp4s0f0
Eu uso o ufw como firewall NAT. Eu adicionei na seção *nat:
:POSTROUTING ACCEPT - [0:0]
-A POSTROUTING -s 172.16.0.0/24 -o enp1s0f1 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/24 -o enp4s0f0 -j MASQUERADE
O problema é que, alternativamente, ou as máquinas da rede 10.0.0.0 recebem resposta de ping do modem (gateway 192.168.0.1), ou as máquinas da rede 172.16.0.0. Pode ser o contrário dependendo do momento, não sei porquê.
Meu modem vê os clientes 192.168.0.3 e 192.168.0.6 em duas portas ETH.
Então é possível ter acesso WAN em todas as máquinas e todas as redes com esta topologia (roteador com duas interfaces na mesma rede)?
Responder1
Embora não esteja escrito explicitamente, acho que o objetivo é dividir o tráfego de forma que:
- O tráfego 172.16.0.0/24 flui através de enp1s0f1
- O tráfego 10.0.0.0/24 flui através de enp4s0f0
Como o OP escreveu, isso precisa de roteamento baseado em política/fonte.tabelas de ipefiltro de rederaramente são úteis (pelo menos sozinhos):
- de um modo geraltabelas de ipefiltro de redenão faça rotas e não se importe com rotas. A pilha de roteamento de rede roteia. Algunstabelas de ip'as ações ainda causarão alterações na decisão de roteamento (conforme descrito nesteesquemático)
- qualquer ação feita emPÓS-TROU, como o nome diz, acontecedepoisdecisões de rota foram tomadas: é tarde demais para alterar a rota. Aqui enquanto onat/POSTROUTINGsão necessárias, elas não alterarão a rota.
Em qualquer momentotabelas de ippode ser evitado para resolver um problema de roteamento, é melhor evitá-lo. Às vezes não pode ser evitado (e geralmentetabelas de ipé usado para adicionar uma marca aos pacotes e esta marca é usada em uma ip ruleentrada).
Rotas
vou assumir querp_filter=1está definido em todas as interfaces, já que é o padrão para a maioria das distribuições, para permitirEncaminhamento estrito de caminho reverso.
O endereço de origem é selecionado por regra, o destino por tabela de roteamento. As tabelas de roteamento adicionais devem ter informações suficientes para substituir (sem ambiguidade) rotas quando apenas uma entre múltiplas deve ser escolhida (então apenas esta é adicionada à tabela). Freqüentemente, rotas adicionais da tabela principal também devem ser copiadas ou coisas ruins podem acontecer.
Na minha resposta não darei preferência a uma rede ou outra: cada uma terá sua própria tabela de roteamento. Vou esquecer a tabela 1 e usar as tabelas 10 para LAN 10.0.0.0/24 e 172 para LAN 172.16.0.0/24. Mantenha as regras NAT, remova as regras e tabelas de roteamento adicionais, bem como 192.168.0.1 dev enp4s0f0 scope linkdo principal.
Rotas para 10.0.0.0/24 <--> 10.0.0.6 enp4s0f0 | enp4s0f1 192.168.0.6 <--> 192.168.0.1/padrão:
ip rule add from 10.0.0.0/24 lookup 10 ip route add table 10 10.0.0.0/24 dev enp4s0f1 ip route add table 10 192.168.0.0/24 dev enp4s0f0 src 192.168.0.6 ip route add table 10 default via 192.168.0.1
Acima, sem também a entrada de rota duplicada para 10.0.0.0/24, o sistema não seria capaz de acessar esta LAN: resolveria a rota como tendo que passar pelo gateway padrão, apenas paraEncaminhamento estrito de caminho reverso(SRPF) dificultando a depuração. Esse é um exemplo de coisa ruim se não for adicionado. Na dúvida, basta duplicar as rotas.
Uma outra opção equivalente poderia ter sido, em vez da rota adicional, alterar a regra acima para:
ip rule add from 10.0.0.0/24 iif enp4s0f1 lookup 10
portanto, não corresponderia ao tráfego local (não roteado) e apenas a tabela principal seria usada.
Rotas para 172.16.0.0/24 <--> 172.16.0.3 enp1s0f0 | enp1s0f1 192.168.0.3 <--> 192.168.0.1/padrão:
ip rule add from 172.16.0.0/24 lookup 172 ip route add table 172 172.16.0.0/24 dev enp1s0f0 ip route add table 172 192.168.0.0/24 dev enp1s0f1 src 192.168.0.3 ip route add table 172 default via 192.168.0.1Alterar também a rota (o link) para o tráfego de saída iniciado localmente ao alterar o endereço IP de origem de saída no sistema Linux. Isso deveria ser opcional, mas a próxima parte sobre o fluxo ARP torna-o obrigatório:
ip rule add from 192.168.0.6 lookup 10 ip rule add from 192.168.0.3 lookup 172Qualquer caso não especial envolvendo as rotas substituídas pelas regras também deve ser duplicado
Aqui as únicas rotas que faltam estão entre as duas LANs especiais:
na tabela 10 para chegar a 172.16.0.0/24
na tabela 172 para chegar a 10.0.0.0/24
como cada tabela adicional ainda não possui uma rota para esse outro lado, ela usaria a rota padrão (mas seria bloqueada novamente pelo SRPF) impedindo que cada uma das duas redes especiais se comunicassem mais entre si. Então apenas duplique a rota que falta para cada tabela:
ip route add table 10 172.16.0.0/24 dev enp1s0f0
ip route add table 172 10.0.0.0/24 dev enp4s0f1
Com este modelo, se por exemplo duas outras redes internas "normais" fossem adicionadas, elas poderiam se comunicar entre si (e usariam a rota padrão da tabela principal para sair) sem configuração extra, mas exigiriam novamente a duplicação de suas rotas em cada tabela de roteamento adicional para se comunicar com as duas LANs especiais.
As rotas agora estão boas, mas ainda há...
OFluxo ARPproblema
O Linux segue omodelo de hospedeiro fraco. Esse é o caso do roteamento IP, e também da forma como o Linux responde às solicitações ARP: de qualquer interface para qualquer IP, mas é claro usando o próprio endereço MAC da interface. Como isso pode acontecer em todas as interfaces simultaneamente quando várias interfaces estão na mesma LAN, geralmente o mais rápido ganha. Em seguida, as informações ARP são armazenadas em cache no sistema remoto e permanecerão lá por algum tempo. Eventualmente o cache expira, o mesmo acontece, com um possível resultado diferente. Então, como isso causa um problema? Aqui está um exemplo:
- O roteador (modem) envia uma solicitação ARP para 192.168.0.6 para enviar de volta a resposta roteada e NAT (pelo Linux) ao tráfego enviado inicialmente de 10.0.0.0/24.
- Linux responde emenp1s0f1(enp1s0f1venceu a corrida) usandoenp1s0f1endereço MAC em resposta para informar que tem 192.168.0.6.
- Por alguns segundos a alguns minutos, pacotes IP de entrada futura do roteador para 192.168.0.6 chegam emenp1s0f1,
- ao mesmo temposaídapacotes de 192.168.0.6 saem usandoenp4s0f0.
Este roteamento assimétrico é capturado porEncaminhamento estrito de caminho reverso(rp_filter) e o tráfego falhará. Isso pode até parecer funcionar aleatoriamente por alguns segundos e depois falhar novamente. Dependendo do tráfego geral, o problema pode mudar ainda mais tarde para o outro link (e então os problemas mudarem para a outra LAN).
Felizmente, para evitar isso, o Linux fornece uma configuração, para ser usada apenas em conjunto com a política de roteamento, para que o ARP siga as mesmas regras definidas pelo roteamento:arp_filter.
arp_filter - BOOLEAN
1 - Permite ter múltiplas interfaces de rede na mesma sub-rede, e ter os ARPs de cadainterfaceser respondido com base emse o kernel roteia ou não um pacote do IP ARP para fora dessa interface(portantovocê deve usar roteamento baseado na origempara que isso funcione). Em outras palavras, permite controlar quais cartões (geralmente 1) responderão a uma solicitação arp.
sysctl -w net.ipv4.conf.enp4s0f0.arp_filter=1
sysctl -w net.ipv4.conf.enp1s0f1.arp_filter=1
Agora que o comportamento do ARP está correto, se as configurações acabaram de ser definidas, deve-se forçar a liberação do cache ARP dopares(aqui: o modem) fazendo uma detecção de endereço duplicado comarping(deiputils/iputils-arping) que transmitirá para os pares e fará com que eles atualizem seu cache:
arping -c 5 -I enp4s0f0 -D -s 192.168.0.6 192.168.0.6 &
arping -c 5 -I enp1s0f1 -D -s 192.168.0.3 192.168.0.3
Observe que as duas regras do marcador 3. na parte anterior agora são obrigatórias, porque os endereços IP 192.168.0.3 e 192.168.0.6 devem corresponder nas regras de roteamento da política para a resolução ARP correta com arp_filter=1.
Como depurar
ip route geté muito útil para verificar rotas e filtrar caminhos reversos:
novo caso de teste para o item 4. acima:
# ip route get from 10.0.0.111 iif enp4s0f0 172.16.0.111
172.16.0.111 from 10.0.0.111 dev enp1s0f0 table 10
cache iif enp4s0f0
# ip route get from 172.16.0.111 iif enp1s0f0 to 10.0.0.111
10.0.0.111 from 172.16.0.111 dev enp4s0f1 table 172
cache iif enp1s0f0
ao excluir regras ou rotas:
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp4s0f0 table 10
cache iif enp4s0f1
# ip rule del from 10.0.0.0/24 lookup 10
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp1s0f1
cache iif enp4s0f1
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
local 192.168.0.6 from 192.168.0.1 dev lo table local
cache <local> iif enp4s0f0
# ip rule delete from 192.168.0.6 lookup 10
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
RTNETLINK answers: Invalid cross-device link
Isso mostra como os resultados são alterados dependendo da (falta de) regras e rotas adicionais. O último resultado é a mensagem de erro que informa que a verificação do encaminhamento de caminho reverso falhou (=> descartar).
Depois, há ip neigh(mais úteis emparsistemas) para verificar entradas ARP tcpdump, etc.