Como forçar pacotes TCP a usar um NIC específico

Question

Meu computador Linux (kernel 3.17) tem mais de um NIC: eth0, eth1, (e / ou eth2 ...)

Eu tenho vários PCs conectados a cada um deles:

PC0 <---> eth0 (192.168.1.100)
PC1 <---> eth1 (192.168.1.101)
PC2 <---> eth2 (192.168.1.102)

Um aplicativo no computador Linux iniciou threads para escutar 192.168.1.100 (e os outros dois). Ao receber um pacote do PC0, o encadeamento responde. Como garanto que a resposta nunca passa pela eth1 ou eth2, embora eles tenham a mesma máscara de sub-rede? Da mesma forma, ao receber o pacote do pc1, a resposta nunca deve passar por eth0 ou eth2.

Idealmente, para conseguir o que eu disse, eu deveria usar três sub-redes completamente diferentes, como 10.0.0.1 e 172 ...., mas meu colega sugere que poderia funcionar, então estou aqui para encontrar opiniões de pares. O kernel está no meu controle, eu o construo, então qualquer solução para fazê-lo funcionar pode ser proposta.

Explicação

Por que três NICs na mesma sub-rede? Eth0 é o endereço IP principal que é atribuído estaticamente durante a inicialização do Linux. Não deve mudar, mas pode mudar, se necessário. A questão é: e se o pessoal de campo acidentalmente atribuísse eth1 e eth2 a ter a mesma sub-rede com eth0? Meu aplicativo responderá apenas a eth0 se o soquete escutar em eth0 em uma determinada porta?

Tabela de Roteamento Possível

a regra é passar pelo NIC se é de onde vem o pedido. Eu copiei de algum lugar

ip route add 172.16.10.0/24 dev eth0 src 172.16.10.10 table 10
ip route add default via 172.16.10.251 table 10
ip route add 172.16.10.0/24 dev eth1 src 172.16.10.20 table 20
ip route add default via 172.16.10.251 table 20
ip route add 172.16.10.0/24 dev eth0 src 172.16.10.10
ip route add 172.16.10.0/24 dev eth1 src 172.16.10.20
ip route add default via 172.16.10.251
ip rule add from 172.16.10.10 table 10
ip rule add from 172.16.10.20 table 20
ip route flush cache

    

Answer 1

Normalmente, um aplicativo se vincula a um endereço IP, não a uma interface específica. (A exceção são aplicativos que mexem com a rede diretamente, como por exemplo, tcpdump / wireshark etc - mas esse não é o seu caso, portanto desconsidere isso.) A maioria dos aplicativos pode se ligar a apenas um endereço IP ou a todos eles (mas geralmente não para mais de um-mas-não-todos deles). Quais deles se aplicam ao seu aplicativo específico dependerão de como ele é codificado.

Quando um cliente se conecta a esse soquete, a conexão é identificada por quatro itens:

1. Seu próprio endereço IP (por exemplo, 192.168.1.100)
2. Sua própria porta (por exemplo, 8080)
3. O endereço IP do cliente
4. A porta do cliente

Todas as respostas enviadas aos dados que você recebe nesta conexão serão enviadas usando essas quatro características, ou seja, elas não serão enviadas de outro IP ou interface em seu servidor.

Portanto, enquanto o que seu aplicativo faz é ouvir em um {IP, porta}, aceitar conexões em {IP, porta} e responder ao cliente, não haverá problemas.

Onde você pode encontrar problemas é se o seu aplicativo, às vezes, iniciar sua própria conexão. Nesse caso, ele (geralmente) permitirá que o computador decida qual interface usar. E se o seu computador considerar todas as três interfaces igualmente válidas, você poderá obter tráfego no canal errado.

Ainda é possível fazer com que seu computador sempre use uma interface específica - exatamente como você faz isso dependerá do seu OS / distro específico. O termo para procurar é "roteamento de origem unix".