Duas interfaces, dois endereços, dois gateways?

15

Eu tenho um sistema que possui duas interfaces de rede com endereços IP diferentes, ambos no intervalo de endereços públicos (embora via NAT no caso do primeiro) e ambos com gateways diferentes. (Longa história, é para fins de teste)

O problema é que, no momento, se eu tentar executar o ping no endereço na segunda interface, a rota padrão será exibida através da primeira interface - e nunca chegará corretamente.

É possível garantir que as respostas sempre saiam pela mesma interface de rede (e com o mesmo IP de origem) em que foram inseridas? E se sim, como?

debian networking ipv4 Shadur
fonte
1
Possivelmente alguma variante disso: unix.stackexchange.com/questions/4420/…
Shawn J. Goff

Respostas:

17

Você está entendendo mal o problema. Nem todo pacote é uma resposta e nem todo pacote pode ser correspondido a outro pacote, de modo que "a mesma interface de rede em que eles entraram" faz sentido. O que você deseja fazer é selecionar o gateway para um pacote com base em seu endereço IP de origem.

Isso é chamado de roteamento baseado em origem ou roteamento de política. Você pode fazer isso com uma regra simplesiptables , mas a melhor maneira é configurar duas tabelas de roteamento, uma para cada endereço de origem público:

Primeiro, crie duas tabelas (Substitua <NAME1> e <NAME2> por nomes sensíveis para seus dois provedores, o mesmo com IP1, DEV1 e assim por diante):

echo 200 <NAME1> >> /etc/iproute2/rt_tables
echo 201 <NAME2> >> /etc/iproute2/rt_tables

Adicione um gateway a cada tabela de roteamento (se necessário):

ip route add <NET1> dev <DEV1> src <SRC1> table <NAME1>
ip route add <NET2> dev <DEV2> src <SRC2> table <NAME2>

Em seguida, uma rota padrão:

ip route add default via <IP1> table <NAME1>
ip route add default via <IP2> table <NAME2>

Em seguida, as regras para selecionar a tabela de rotas com base no endereço de origem:

ip rule add from <IP1> table <NAME1>
ip rule add from <IP2> table <NAME2>

Consulte Roteamento para vários uplinks / provedores para obter mais detalhes.

David Schwartz
fonte
Você escreveu: 'Nem todo pacote é uma resposta e nem todo pacote pode ser correspondido a outro pacote, de modo que "a mesma interface de rede em que eles entraram" faz sentido. 'Você pode explicar isso mais? Entendo que nem todos os pacotes são uma resposta e nem todos os pacotes podem ser correspondidos a outro pacote "de origem". Se excluirmos esses pacotes da consideração, porque eles não causam problemas e, portanto, não nos preocupam, por que os pacotes restantes não podem ser roteados para a "mesma interface de rede em que entraram"?
Andrew Savinykh
@AndrewSavinykh Isso não resolveria todo o problema. Em particular, ele era interrompido sempre que um pacote de saída se originava localmente (como uma solicitação de ping de saída) saía da interface errada para seu endereço IP de origem e era eliminado pelo gateway. O problema é, como expliquei, sobre garantir que os pacotes saiam do gateway correspondente ao seu endereço IP de origem.
David Schwartz
David, quero alcançar o mesmo que OP, mas não consigo. Eu postei uma pergunta aqui: serverfault.com/questions/992624/... , seria ótimo se você pudesse dar uma olhada
Housemd
6

A resposta de David Schwartz é excelente, mas você pode simplificar um pouco as regras de roteamento tendo apenas uma tabela extra e usando sua rota padrão para a outra. Eu tenho um servidor que está por trás de dois gateways NAT e recentemente passei pelo processo de recriar esse cenário entre várias VMs. Minha /etc/network/interfacesaparência é assim:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.13.13
    netmask 255.255.255.0
    up ip route add table optus default via 192.168.13.10
    up ip rule add from 192.168.13.213 table optus
    up ip route add default via 192.168.13.11

auto eth0:0
iface eth0:0 inet static
    address 192.168.13.213
    netmask 255.255.255.0

(isto é para uma configuração em que os dois ISPs são Optus e iiNet, daí o nome da tabela 'optus')

Isso, mais a linha /etc/iproute2/rt_tables criação da tabela, deve ser tudo o que você precisa. Você terá dois endereços IP; o tráfego de 192.168.13.13 será eliminado por meio de 192.168.13.11 e o tráfego de 192.168.13.213 será eliminado por meio de 192.168.13.10. Configure esses dois gateways para fazer o encaminhamento de porta adequadamente (192.168.13.11 encaminha as coisas para 192.168.13.13 e 192.168.13.10 encaminha as coisas para 192.168.13.213), e o restante deve cuidar de si.

Pode ser necessário ajustar um pouco as coisas para sua situação, pois você está usando IPs públicos diretamente, mas algo assim ainda deve funcionar. Além disso, é muito mais fácil fazer essas coisas /etc/network/interfacese gerenciar o arquivo com o git, em vez de tentar lembrar como você o configurou, dois anos depois, quando o sistema precisa ser reiniciado!

rosuav
fonte
1

Exemplo de rede dupla

Este exemplo está mostrando como um adicional eth1com 10.130.0.2máscara de rede 255.255.255.255e gateway10.130.0.1 pode ser disponibilizado para serviços vinculados a ele, comoping -I eth1 8.8.8.8

Tecnicamente, somos:

  • Adicionando um outro gateway com uma métrica maior
  • Adicionando / usando a tabela 100 e configurando-a
  • Adicionando uma regra para rotear o tráfego de / para eth1 através dele
ip addr add 10.130.0.2/32 broadcast 10.130.0.2 dev eth1
ip link set eth1 up
ip route add 10.130.0.1 src 10.130.0.2 dev eth1
ip route add 10.130.0.1 src 10.130.0.2 dev eth1 table 100
ip route add default via 10.130.0.1 dev eth1 metric 10
ip route add default via 10.130.0.1 dev eth1 table 100
ip rule add from 10.130.0.2/32 table 100
ip rule add to 10.130.0.2/32 table 100
curl --interface eth1 ifconfig.co
curl --interface eth0 ifconfig.co
ping -I eth1 8.8.8.8
intika
fonte