Roteando o tráfego para duas NICs na mesma rede

5

Eu tenho algumas caixas de teste do Linux no Scaleway, cada uma com duas NICs conectadas à mesma rede 10.0.0.0/8 , mas cada uma tem seu próprio gateway.

Eu quero poder usar as duas NICs (eth0 / eth1) e seus IPs para comunicação. Portanto, se os aplicativos ligados ao IP .187, então dev eth0 deve ser usado. Se um aplicativo estiver vinculado ao IP .189, então eth1 deve ser usado.

Agora, apenas a interface eth0 com o IP .187 está respondendo às solicitações. Qualquer pedido (é por isso que eu uso ping e ssh para testes). No entanto, se eu alterar a rota padrão de eth0 para eth1 (ip. 189), o tráfego de saída será roteado corretamente pela eth1, nesse caso a eth0 não poderá ser usada.

Então, como configurar a caixa, ambas as interfaces podem ser usadas.

Dado

Box 1:
eth0_ip = 10.5.68.187/31
eth0_gw = 10.5.68.186

eth1_ip = 10.5.68.189/31
eth1_gw = 10.5.68.188

Abordagem

Com base em minha pesquisa, aqui , aqui Eu criei um script bash que deve adicionar rotas estáticas com tabelas para que se possa use os dois nics.

#/bin/bash
# My Vars with IP and GW for eth0
eth0_ip=$(ip -o -4 addr list eth0 | awk '{print $4}' | cut -d/ -f1)
eth0_gw=$(ip route list dev eth0 | awk '{print $1}' | tail -1 | cut -d'/' -f1)

eth1_ip=$(ip -o -4 addr list eth1 | awk '{print $4}' | cut -d/ -f1)
eth1_gw=$(ip route list dev eth1 | awk '{print $1}' | tail -1 | cut -d'/' -f1)

#ip route add 10.0.0.0/8 dev eth0 table 1 priority 100
#ip route add ${eth0_ip} dev eth0 table 1
ip route add default via ${eth0_gw} dev eth0 table 1
ip rule add from ${eth0_ip}/32 table 1

#ip route add 10.0.0.0/8 dev eth1 table 2 priority 110
#ip route add ${eth1_ip} dev eth1 table 2
ip route add default via ${eth1_gw} dev eth1 table 2
ip rule add from ${eth1_ip}/32 table 2

cache de limpeza de rotas ip

Eu fiz alguma variação do script, mas nenhum deles trabalhou

Saída

[node]# ip route
default via 10.1.229.186 dev eth0 
10.1.229.186/31 dev eth0 proto kernel scope link src 10.1.229.187 
10.1.229.188/31 dev eth1 proto kernel scope link src 10.1.229.189 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1 

[node]# ip route show table 1
10.1.229.187 dev eth0 scope link 

[node]# ip route show table 2
10.1.229.189 dev eth1 scope link 

Teste

[]]# ip route get 10.5.68.187 from 10.1.229.187
10.5.68.187 from 10.1.229.187 via 10.1.229.186 dev eth0 
    cache 
[]# ip route get 10.5.68.187 from 10.1.229.189
10.5.68.187 from 10.1.229.189 via 10.1.229.188 dev eth1 
    cache 

De outra máquina.

ping 10.1.229.187   # OK
ping 10.1.229.189   # NOK

nmap 10.1.229.187 -p 22   # OK
nmap 10.1.229.189 -p 22   # NOK

Então, como posso configurar o roteamento para que ele funcione, comunique-se com .187 e .189 ao mesmo tempo.

Atualização 2:

Com essa configuração, consegui ter algum tipo de sucesso.

eth0_ip=$(ip -o -4 addr list eth0 | awk '{print $4}' | cut -d/ -f1)
eth0_gw=$(ip route list dev eth0 | awk '{print $1}' | tail -1 | cut -d'/' -f1)

eth1_ip=$(ip -o -4 addr list eth1 | awk '{print $4}' | cut -d/ -f1)
eth1_gw=$(ip route list dev eth1 | awk '{print $1}' | tail -1 | cut -d'/' -f1)

ip route add default via ${eth0_gw} dev eth0 table 1
ip rule add from ${eth0_ip} table 1

ip route add default via ${eth1_gw} dev eth1 table 2
ip rule add from ${eth1_ip} table 2

Depois de aplicar o script acima, modifiquei a rota padrão, mude para eth1 e, em seguida, de volta, depois disso consegui fazer ping para .187 e .189. (Em outro exemplo eu também removi completamente) Não tenho certeza qual é o problema aqui.

# remove and add route 
ip route change default via ${eth1_gw} dev eth1
ip route change default via ${eth0_gw} dev eth0

ip route flush cache

Atualização 3:

De vários testes, parece-me que a tabela 2 é completamente ignorada. Como o ISP tem um kernel customizado, é possível desabilitar as tabelas de roteamento no kernel? Como posso testá-lo?

Atualização 4:

Mais uma vez tive um pequeno progresso, mas ainda longe de uma solução de trabalho. Experimentando diferentes opções, me deparei com essa estranha situação. Para ver a eth1 funcionando, preciso usar a interface em questão primeiro, por exemplo,

Eu preciso fazer ping de IP .189 (node1) para outro nó na rede, por exemplo: Exemplo: Nó 1- > Nó 2: ping -I 10.1.229.189 10.5.68.187 isto funciona e então de repente em retorno o ping do Nó 2 - > Nó 1 ping 10.1.229.189 está funcionando. Se eu não fizer a conexão / ping inicial de (Nó 1 - > Nó 2) então (Nó 2 - > Nó 1) não está funcionando.

O problema aqui é no entanto, se eu reiniciar a máquina ou esperar algum tempo (10-60 minutos), ele volta ao estado inicial.

A configuração mínima que está funcionando parcialmente é essa (removi tudo posteriormente, isso não fez diferença)

eth1_ip=$(ip -o -4 addr list eth1 | awk '{print $4}' | cut -d/ -f1)
eth1_gw=$(ip route list dev eth1 | awk '{print $1}' | tail -1 | cut -d'/' -f1)

ip route add default via ${eth1_gw} dev eth1 table 2
ip rule add from ${eth1_ip} lookup 2

Esta é a saída solicitada de @Anton Danilov

[root@cluser-node-1 ~]# ip -4 r ls table all
default via 10.1.229.188 dev eth1 table 2 
default via 10.1.229.186 dev eth0 
10.1.229.186/31 dev eth0 proto kernel scope link src 10.1.229.187 
10.1.229.188/31 dev eth1 proto kernel scope link src 10.1.229.189 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1 
local 10.1.229.187 dev eth0 table local proto kernel scope host src 10.1.229.187 
broadcast 10.1.229.187 dev eth0 table local proto kernel scope link src 10.1.229.187 
local 10.1.229.189 dev eth1 table local proto kernel scope host src 10.1.229.189 
broadcast 10.1.229.189 dev eth1 table local proto kernel scope link src 10.1.229.189 
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
broadcast 172.17.0.0 dev docker0 table local proto kernel scope link src 172.17.0.1 
local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1 
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1 
broadcast 172.18.0.0 dev docker_gwbridge table local proto kernel scope link src 172.18.0.1 
local 172.18.0.1 dev docker_gwbridge table local proto kernel scope host src 172.18.0.1 
broadcast 172.18.255.255 dev docker_gwbridge table local proto kernel scope link src 172.18.0.1 



[root@cluser-node-1 ~]# ip rule list
0:  from all lookup local 
32765:  from 10.1.229.189 lookup 2 
32766:  from all lookup main 
32767:  from all lookup default 

[root@cluser-node-1 ~]# ip n ls dev eth1
10.1.229.188 lladdr 00:07:cb:0b:0d:93 REACHABLE

[root@cluser-node-1 ~]# tcpdump -ni eth1 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:36:17.237182 ARP, Request who-has 10.1.229.188 tell 10.1.229.189, length 28
16:36:17.237369 ARP, Reply 10.1.229.188 is-at 00:07:cb:0b:0d:93, length 46

2 packets captured
4 packets received by filter
0 packets dropped by kernel

Esta é a outra saída depois que o sistema é reiniciado ou após o tempo limite de 15 a 30 minutos.

[root@cluser-node-1 ~]# tcpdump -ni eth1 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

[root@cluser-node-1 ~]# ip n ls dev eth1
10.1.229.188 lladdr 00:07:cb:0b:0d:93 REACHABLE
    
por Vadimo 10.11.2017 / 19:21

1 resposta

1

Verifique, há respostas (talvez as respostas estejam saindo de outra interface) ou as respostas estão faltando.

Verifique as configurações do filtro de caminho inverso (verifique os contadores na saída de 'nstat -az' ou 'netstat -S' - existe TcpExtIPReversePathFilter para pacotes descartados pelo rp_filter). Desativar ou definir no modo solto (veja sysctl define a descrição ). Pesquise a rota inversa para os pacotes de entrada para confirmar a suposição.

Eu acho que você deve adicionar rotas para redes diretamente conectadas em tabelas de rotas, porque é necessário pela resolução de arp correspondentes de gateways e para a comunicação com outros hosts em redes diretamente conectadas. Essas configurações devem ser suficientes para resolver seu caso:

ip route add 10.5.68.186/31 dev eth0 table 1
ip route 0/0 via 10.5.68.186 dev eth0 table 1

ip route add 10.5.68.188/31 dev eth1 table 2
ip route 0/0 via 10.5.68.188 dev eth1 table 2

ip rule add from 10.5.68.187 lookup 1
ip rule add from 10.5.68.189 lookup 2

Além disso, você deve saber, o que esta configuração é apenas para o caso, onde os endereços IP nessas interfaces com endereçamento sobrepostos é diferente. Caso contrário, você deve usar um esquema mais complexo com CONNMARK e pbr por marcas de firewall.

Se você estiver tentando fazer o ping do host a partir do host, use estes comandos:

ip route add local 10.5.68.187 dev eth0 table 1
ip route add 10.5.68.186/31 dev eth0 table 1
ip route 0/0 via 10.5.68.186 dev eth0 table 1

ip route add local 10.5.68.189 dev eth1 table 2
ip route add 10.5.68.188/31 dev eth1 table 2
ip route 0/0 via 10.5.68.188 dev eth1 table 2

ip rule add iif eth0 lookup 1 pref 101
ip rule add iif eth1 lookup 2 pref 102

ip rule add from 10.5.68.187 lookup 1 pref 201
ip rule add from 10.5.68.189 lookup 2 pref 202

ip rule add from all lookup local pref 300
ip rule del pref 0
    
por 22.11.2017 / 12:05