A configuração da rota IPv6 funciona apenas parte do tempo

Question

Eu tenho uma rede que é colocada on-line e acessível em um túnel, tun0. Este tun0 é iniciado com um script python da seguinte forma:

tun_name = 'tun0'.encode()
ifs = ioctl(self.virtualIf, TUNSETIFF, struct.pack("16sH", tun_name, IFF_TUN))
self.ifname = tun_name.decode()
print('[NetworkSideThread] Created virtual interface '+self.ifname+'.')

# configure IPv6 addresses of virtual interface
subprocess.check_call(CMD_IFCONFIG + ' ' + self.ifname + ' up', shell=True)
subprocess.check_call(CMD_IFCONFIG + ' ' + self.ifname + ' inet6 add ' + self.prefix + '::1/64', shell=True)
subprocess.check_call(CMD_IFCONFIG + ' ' + self.ifname + ' inet6 add fe80::1/64', shell=True)
print('[NetworkSideThread] Configured IPv6 address')

# set static route
subprocess.check_call(CMD_ROUTE+' -A inet6 add ' + self.prefix + '::/64 dev ' + self.ifname, shell=True)

Os dispositivos dentro da rede têm um endereço bbbb :: (por exemplo, bbbb :: 17: d00: 30: 6fb6 e bbbb :: 17: d00: 30: 76f6). A finalidade é que o tráfego enviado de 76f6 para 6fb6 chegue ao túnel e, em seguida, seja enviado corretamente para 6fb6.

A coisa estranha é: com a configuração acima, isso só funciona um pouco do tempo!

Fazendo "route -A inet6" revela:

Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
2a02:2c40:500:a006::/64        [::]                       Ue   256 0     0 ens33
bbbb::/64                      [::]                       U    1   3   290 tun0
bbbb::/64                      [::]                       U    256 0     0 tun0
fe80::/64                      [::]                       U    256 1    38 ens33
fe80::/64                      [::]                       U    256 0     0 tun0
[::]/0                         gateway                    UG   100 1     1 ens33
[::]/0                         [::]                       !n   -1  1 16599 lo
ip6-localhost/128              [::]                       Un   0   5882117 lo
2a02:2c40:500:a006::/128       [::]                       Un   0   4     3 lo
ubuntu/128                     [::]                       Un   0   1     0 lo
ubuntu/128                     [::]                       Un   0   3    82 lo
bbbb::/128                     [::]                       Un   0   3     5 lo
ubuntu/128                     [::]                       Un   0   4    57 lo
fe80::/128                     [::]                       Un   0   3     6 lo
fe80::/128                     [::]                       Un   0   1     0 lo
ubuntu/128                     [::]                       Un   0   1     0 lo
ubuntu/128                     [::]                       Un   0   1     0 lo
ubuntu/128                     [::]                       Un   0   3    33 lo
ip6-mcastprefix/8              [::]                       U    256 4   610 ens33
ip6-mcastprefix/8              [::]                       U    256 0     0 tun0
[::]/0                         [::]                       !n   -1  1 16600 lo

Meu palpite seria que às vezes o tráfego enviado de 76f6 para 6fb6 leva a rota "2a02: 2c40: 500: a006 :: / 64 [::] Ue 256 0 0 ens33" e às vezes leva o "bbbb :: / 64 [::] U 1 3 290 tun0 "rota.

Em todos os casos em que um dispositivo envia para um endereço bbbb, o pacote deve ser injetado através do túnel na rede bbbb.

Alguma pista sobre como resolver isso? É estranho, pois não acontece de forma consistente.

Editar:

As informações solicitadas:

ip -6 route get bbbb::17:d00:30:6fb6

dá

bbbb::17:d00:30:6fb6 from :: dev tun0 src bbbb::1 metric 1 pref medium

e

ip route show match bbbb::17:d00:30:6fb6

não dá nada.

Hmmm, seu primeiro comentário faz sentido, então minha hipótese inicial está errada. Para informações adicionais, adicionei uma captura de tela do Wireshark no túnel, que mostra pacotes idênticos nos dois casos em que é recebido em 6fb6 e onde não está (pacotes

Isso parece indicar que eu estava errado. Não é uma pista imediata qual é o problema então - o dispositivo receptor pode cair em alguns casos e não cair em outros, mas isso seria estranho.

O Wireshark também fornece os mesmos resultados. Os primeiros 3 pacotes são a primeira transmissão e chegam ao destino, os últimos 3 pacotes (embora idênticos) são a segunda transmissão e não chegam!