Roteamento baseado em fonte ou política, talvez? O Linux pode ter várias tabelas de roteamento e escolher qual delas usar com base em várias condições. Confira a documentação do OpenVZ sobre roteamento baseado na origem
Enquanto a depuração problema com a configuração de rede para um conjunto de máquinas virtuais executadas no KVM, descobri uma circunstância em que o kernel na máquina virtual convidado decidiu estampar o quadro Ethernet de saída com um endereço de destino que está em conflito com o endereço que escolheria se estava respeitando com a tabela de rotas IP do kernel.
Então, nesse exemplo, eu esperava que o quadro de saída fosse entregue para de: ad: be: 3b: 24: 48 que corresponde ao host que possui o endereço IP 10.11.11.2 e que possui uma rota para 10.8. 0,0 / 24.
O que realmente aconteceu foi que o kernel decidiu carimbar o quadro com um destino de 00: 10: db: ff: 70: 01 que enviou o quadro na direção de 10.11.11.1, que não sabe como rotear para 10.8.0.0/24 e como resultado o pacote foi descartado.
Esta decisão foi em violação da tabela de roteamento local que claramente especificou que a rota para 10.8.0.0/24 era via 10.11.11.2. Veja o relatório original do problema para detalhes.
[O endereço de destino incorreto estava visível ao executar o tcpdump na VM guest que estava enviando o quadro na direção incorreta.].
Na verdade, arrastando a tabela de arp local para fazer o endereço MAC aparente de 10.11.11.1 ser idêntico ao endereço MAC real de 10.11.11.2, consegui fazer com que o quadro fluísse na direção correta.
Portanto, minha pergunta é: qual mecanismo, na VM guest ou no host KVM, poderia fazer com que o kernel guest ignorasse a tabela de rotas locais e enviasse o pacote em um quadro para o host (incorreto) em 10.11.11.1, apesar de 10.11.11.1 não estar listado como um gateway para a rede de destino (10.8.0.0/24)?
Nota: o iptables foi desativado no convidado no momento. Não sei se o ebtables está habilitado no host KVM, mas mesmo assim, como isso faria com que o kernel na VM guest quisesse enviar o pacote na direção de 10.11.11.1?
Um comportamento que notei é que, se eu limpar as tabelas ARP do host afetado e enviar uma solicitação de ping ao host afetado da rede 10.8.0.0/24, ele receberá a solicitação e, em seguida, enviará uma transmissão arp para 10.11. .11.1 imediatamente antes de enviar a resposta de ping na direção de 10.11.11.1 em vez de 10.11.11.2 e, portanto, 10.8.0.0/24. O que está fazendo com que ele tente 10.11.11.1, que não é especificado como um gateway?
Roteamento baseado em fonte ou política, talvez? O Linux pode ter várias tabelas de roteamento e escolher qual delas usar com base em várias condições. Confira a documentação do OpenVZ sobre roteamento baseado na origem