Há um erro óbvio na configuração do seu gateway. Ambas as interfaces foram configuradas com o mesmo /64 .
Em uma configuração correta, você usa o prefixo link que recebeu do seu provedor na interface WAN, e usa o prefixo roteado que recebeu do seu provedor na LAN interface. Se o prefixo roteado for menor que /64 (o que é suposto ser), você poderá escolher qualquer /64 desse /48 para sua LAN. Por exemplo, se seu provedor forneceu o prefixo roteado 2001:db8:1234::/48 , seu prefixo de LAN poderia ser 2001:db8:1234::/64 , 2001:db8:1234:ffff::/64 , 2001:db8:1234:babe::/48 ou qualquer uma das 65533 outras possibilidades.
O que acontece quando você executa tcpdump é que (por padrão) transforma a interface de rede em modo promíscuo, o que significa que o hardware começará a aceitar quadros Ethernet mesmo se eles não forem enviados para o endereço MAC dessa interface de rede.
Não é óbvio como esses dois poderiam estar conectados. Mas é possível formular uma hipótese que pode então ser testada.
Pode ser que ao receber solicitações de descoberta vizinhas, o gateway responda com o endereço MAC da outra interface. Isso é pelo menos um comportamento plausível considerando que ambas as interfaces estão configuradas com o mesmo /64 . Mas como os pacotes são enviados para esse outro endereço MAC, a interface de rede os soltará até que a interface de rede seja alternada para o modo promíscuo.
Existem várias coisas que você pode fazer para testar essa hipótese:
- Executar
tcpdumpsem o modo promíscuo (-pswitch). Setcpdumpajudar no modo promíscuo, mas não de outra forma, confirmamos que o modo promíscuo faz a diferença. - Observe qual endereço MAC é enviado nas respostas de descoberta do vizinho e compare-o com as duas interfaces de rede.
- Observe o endereço MAC de destino nos pacotes enviados para o endereço IP para ver para qual endereço MAC eles são enviados (isso pode ser feito usando Ethereal ou
tcpdumpno modo promíscuo). - Reconfigure a interface que foi configurada com o prefixo de rede incorreto para ver se isso ajuda.