forçando o tráfego de rede a ser roteado através de uma interface específica, não padrão

Question

Eu tenho um monte de servidores Linux com várias (3) NICs e interfaces de rede associadas. Estou tropeçando em um problema de roteamento bizarro, onde o tráfego que deve usar a rota padrão não é, e não conseguir ser roteado como resultado. Aqui está a minha tabela de roteamento:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.31.96.1      0.0.0.0         UG    0      0        0 em3
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 em1
10.31.96.0      0.0.0.0         255.255.252.0   U     0      0        0 em3
10.31.96.0      0.0.0.0         255.255.252.0   U     0      0        0 em4
# ip route list
default via 10.31.96.1 dev em3  proto static 
10.0.0.0/8 dev em1  proto kernel  scope link  src 10.0.0.100 
10.31.96.0/22 dev em3  proto kernel  scope link  src 10.31.97.100 
10.31.96.0/22 dev em4  proto kernel  scope link  src 10.31.96.61

10.31.96.1 é a minha rota padrão que todo o tráfego deve estar usando (que em # coisas é coisa do Fedora, você pode mentalmente substituir 'eth' em todos os lugares que você vê se eles facilitarem o acompanhamento). Aqui saída de ifconfig:

em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 10.0.0.100  netmask 255.0.0.0  broadcast 10.255.255.255
    inet6 fe80::b6b5:2fff:fe5b:9e7c  prefixlen 64  scopeid 0x20<link>
    ether b4:b5:2f:5b:9e:7c  txqueuelen 1000  (Ethernet)
    RX packets 283922868  bytes 44297545348 (41.2 GiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 538064680  bytes 108980632740 (101.4 GiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    device memory 0xfeb60000-feb80000

em3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 10.31.97.100  netmask 255.255.252.0  broadcast 10.31.99.255
    inet6 fe80::b6b5:2fff:fe5b:9e7e  prefixlen 64  scopeid 0x20<link>
    ether b4:b5:2f:5b:9e:7e  txqueuelen 1000  (Ethernet)
    RX packets 3733210  bytes 1042607750 (994.3 MiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 1401537  bytes 114335537 (109.0 MiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    device memory 0xfea60000-fea80000

em4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 10.31.96.61  netmask 255.255.252.0  broadcast 10.31.99.255
    inet6 fe80::b6b5:2fff:fe5b:9e7f  prefixlen 64  scopeid 0x20<link>
    ether b4:b5:2f:5b:9e:7f  txqueuelen 1000  (Ethernet)
    RX packets 2416588  bytes 196633917 (187.5 MiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 205038  bytes 19363499 (18.4 MiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    device memory 0xfeae0000-feb00000

em1 / 10.0.0.100 vai para um comutador que está conectado somente aos servidores no mesmo rack. É usado apenas para os servidores desse rack se comunicarem entre si. em3 & em4 ambos encaminham para a mesma sub-rede. A única diferença entre eles é que o em3 nem sempre está ativo (está associado a um endereço IP flutuante com base em qual servidor está atualmente na função 'principal'). Basicamente, todo o tráfego deve sair pelo em3, a menos que seja destinado a outra coisa na sub-rede local 10.0.0.1/8, caso em que deve passar por em1. No entanto, não é isso que está acontecendo. 10.31.96.1/16, 10.31.97.1/16 e 10.31.99.1/16 o tráfego está passando por em3, mas o material destinado a 10.31.45.1/16 está tentando passar por em1, e o tempo limite está esgotado porque não há como rotear esse tráfego efetivamente.

Isso também é ilustrado com o seguinte comando:     # tcptraceroute cuda-linux     traceroute para cuda-linux (10.31.45.106), 30 hops no máximo, pacotes de 60 bytes      1 cuda-fs1a-interno (10.0.0.100) 3006.650 ms! H 3006.624 ms! H 3006.619 ms! H

No entanto, quando executado a partir de um sistema na mesma rede da caixa acima, com apenas uma interface de rede, ele funciona:     # tcptraceroute cuda-linux     traceroute para cuda-linux (10.31.45.106), 30 hops no máximo, pacotes de 40 bytes      1 10.31.96.2 (10.31.96.2) 0,345 ms 0,403 ms 0,474 ms      2 cuda-linux (10.31.45.106) 0.209 ms 0.208 ms 0.201 ms

Achei que poderia corrigir isso adicionando uma rota a 10.31.45.1 para em3, mas isso falha:

# route add default gw 10.31.45.1 em3
SIOCADDRT: Network is unreachable

Estou perdido neste ponto em que mais tentar. ajuda?

    

Answer 1

As rotas são processadas da rota mais específica para a rota menos específica (como padrão).

default via 10.31.96.1 dev em3  proto static 
10.0.0.0/8 dev em1  proto kernel  scope link  src 10.0.0.100 
10.31.96.0/22 dev em3  proto kernel  scope link  src 10.31.97.100 
10.31.96.0/22 dev em4  proto kernel  scope link  src 10.31.96.61

Você disse que deseja should be going out through em3 unless its destined for something else on the local 10.0.0.1/8 subnet . Isso é exatamente o que está acontecendo. O endereço IP 10.31.45.1 está dentro de 10.0.0.0/8 e, portanto, está saindo via em1. A rota 10.0.0.0/8 corresponde a esse endereço é mais específica que a rota padrão. O endereço não corresponde à rota 10.31.96.0/22 . Portanto, a rota em1 é selecionada.

Seu problema real é que você tem uma máscara de sub-rede nessa interface em1 que é muito grande para o que você provavelmente precisa e entra em conflito com as outras redes. Qualquer coisa destinada a um endereço IP no intervalo 10.0.0.1-10.255.255.254 tentará usar em1 como se fosse local, o que a exceção de endereços no 10.31.96.0/22 deixará por em3 / em4.

Sua solução é corrigir a sub-rede / rede em1 para que não entre em conflito com suas outras redes ou para adicionar muitas rotas.

Algo como ip route add 10.31.45.0/24 via 10.31.96.1 pode fazer o que você deseja.