Depuração de pacotes desaparecendo após a recepção

Question

Vou tentar tornar essa explicação o mais direta possível, está me empurrando para a parede, já que eliminei todas as opções que consigo imaginar.

Existem dois hosts, nós os chamamos de Alice e Bob.

• Em Alice 10.242.0.1/32 é atribuído a lo e em Bob 10.242.0.2/32 é atribuído a lo.
• Entre Alice e Bob há um túnel gre que fornece um ponto a ponto de 10.242.0.101/32 a 10.242.0.102/32, chamaremos essa interface de a_b_gre em ambos os lados.
• Além disso, Alice tem o endereço IP 10.242.1.1/24 atribuído a uma ponte.

Focando no Bob, ele sabe que tanto o 10.242.0.1/32 quanto o 10.242.1.0/24 podem ser acessados via 10.242.0.101/32. Não existem regras de firewall, as políticas estão definidas para ACCEPT.

Então aqui está o meu problema: quando Alice pinga 10.242.0.2 com um ip src de 10.242.1.1, os pacotes são recebidos, mas não roteados ou respondidos. Agora, para algumas das muitas coisas que tentei no processo de depuração:

1. Ping de 10.242.0.101 a 10.242.0.102: funciona bem
2. Ping de 10.242.0.1 a 10.242.0.2: funciona bem
3. Ping de 10.242.1.1 a 10.242.0.102: também não funciona
4. tshark -pi any icmp : os pacotes são vistos chegando, nenhum pacote de resposta
5. tshark -i lo icmp : nenhum pacote visto

6. Verificações de sysctl:

   net.ipv4.conf.all.forwarding = 1
   net.ipv4.ip_forward = 1
   net.ipv4.conf.all.accept_local = 1
   net.ipv4.conf.all.rp_filter = 0
   net.ipv4.conf.all.route_localnet = 1
   net.ipv4.conf.all.log_martians = 1
   

7. Regra TRACE do iptables: TRACE: filter:INPUT:policy:1 IN=a_b_gre OUT= MAC= SRC=10.242.1.1 DST=10.242.0.2 ... que sugere que ela passou pela cadeia de entrada.

8. conntrack -L: icmp 1 29 src=10.242.1.1 dst=10.242.0.2 type=8 code=0 id=29499 [UNREPLIED] src=10.242.0.2 dst=10.242.1.1 type=0 code=0 id=29499 mark=0 use=1 ... Então definitivamente chega lá ... limpar a entrada conntrack não ajuda.

9. Verificações de pesquisa de rota: nossa pesquisa diz ...

   Bob # ip route get 10.242.0.2 from 10.242.0.1 iif a_b_gre
   local 10.242.0.2 from 10.242.0.1 dev lo table local
       cache <local>  iif a_b_gre
   Bob # ip route get 10.242.1.1 from 10.242.0.2 iif lo
   10.242.1.1 from 10.242.0.2 via 10.242.0.101 dev a_b_gre
       cache  iif lo
   

E agora estou sem ideias. Bob claramente recebe o pacote, e parece saber o que deveria estar fazendo com ele, mas parece que algo está fazendo com que ele solte o pacote em vez de respondê-lo ou encaminhá-lo para o loopback. Considerando que vejo o mesmo comportamento quando tento fazer um ping nas linhas de ping -I 10.242.0.1 10.242.0.2 10.242.0.3 , em que .3 pertence a uma terceira configuração de host de forma semelhante às duas primeiras, e novamente ip route get dando a resposta certa, eu sou definitivamente suspeito do estágio de encaminhamento.

Ah, eu também devo observar que eu especificamente não quero o endereço do NAT. Embora isso resolva o problema imediato, ele também anula o objetivo, que é fazer com que o pacote seja encaminhado corretamente.

Então, algum pensamento sobre para onde ir a partir daqui?