root@host-3:~# uname -a
Linux host-3 4.4.35-1-pve #1 SMP Fri Dec 9 11:09:55 CET 2016 x86_64 GNU/Linux
root@host-3:~# cat /etc/debian_version
8.9
root@host-3:~# ifconfig
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.1.2 Bcast:192.168.1.2.255 Mask:255.255.255.0
inet6 addr: xxxx::xxxx:xxxx:xxxx:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3313 errors:0 dropped:0 overruns:0 frame:0
TX packets:348 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:224843 (219.5 KiB) TX bytes:29794 (29.0 KiB)
eth1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: xxxx::xxxx:xxxx:xxxx:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3028 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:196588 (191.9 KiB) TX bytes:1330 (1.2 KiB)
Na configuração abaixo, no host-3, o tráfego não sai para o fio. A pilha simplesmente envia de volta para o aplicativo de recebimento.
Uma captura de pacotes em ambas as interfaces mostra que nenhum pacote chegou realmente a qualquer interface de rede.
Por que isso acontece?
2 HOSTS, 1 NIC / HOST: ISTO FUNCIONA (PARA COMPARAÇÃO COM O host-3 ABAIXO)
--------------------- ------------------------------------------- ---------------------
| Linux Host host-1 | | Device Under Test (router) | | Linux Host host-2 |
| 192.168.1.2/24|----------|192.168.1.1/24 192.168.2.1/24|----------|192.168.2.2/24 |
--------------------- ------------------------------------------- ---------------------
1 HOST COM 2 NICs: ISTO NÃO TRABALHA
---------------------
| Linux Host host-3 |
| 192.168.1.2/24|--------|
| eth0| |
| | |
| | |
| eth1| |
| 192.168.2.2/24|---| |
--------------------- | |
| |
| |
| |
| | -------------------------------------------
| | | Device Under Test (router) |
| |---------|192.168.1.1/24 192.168.2.1/24|---------|
| ------------------------------------------- |
| |
| |
| |
| |
|------------------------------------------------------------------|
TABELA DE ROTEAMENTO, INCLUINDO ROTAS ESTÁTICAS PARA O host-3
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.2 192.168.2.1 255.255.255.255 UGH 0 0 0 eth1
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.2.2 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
PARÂMETROS RELEVANTES DE KERNEL PARA o host-3
root@host-3:~# sysctl -a | grep "\.rp_filter"
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
root@host-3:~# sysctl -a | grep "accept_local"
net.ipv4.conf.eth0.accept_local = 1
net.ipv4.conf.eth1.accept_local = 1
net.ipv4.conf.all.accept_local = 1
net.ipv4.conf.default.accept_local = 1
net.ipv4.conf.lo.accept_local = 0
UPDATE # 1
Em resposta ao comentário, consulte o tipo de tráfego e se há VMs envolvidas ...
O tráfego é apenas pings. Eu também testei com UDP unicast e não encontrei diferença no comportamento.
Sim, estas são VMs. Na verdade, mais precisamente, eles são contêineres do LXC Linux em execução no Proxmox 4.4.
Além disso, descobri uma outra coisa desde o meu post original.
Durante o ping, se eu usar a opção -I para especificar a saída (ou seja, o endereço IP ), não vejo nenhuma alteração no comportamento. No entanto, se eu usar a opção -I do ping para especificar a interface de saída, as coisas parecem funcionar, com uma ressalva. Eu digo que eles funcionam porque o comando ping recebe respostas com tempos de ida e volta de aproximadamente 40 ms. Isso é sobre o que eu esperaria se os pacotes estivessem realmente saindo e não em curto-circuito pela pilha (nesse caso, os tempos de ida e volta são sub-milissegundos). No entanto, aqui está a advertência ...
As capturas de pacotes nas interfaces de egresso e de entrada mostram apenas o pedido de eco. As capturas não mostram as respostas de eco. Não tenho certeza de como isso pode ser ...