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
tcpdump
sem o modo promíscuo (-p
switch). Setcpdump
ajudar 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
tcpdump
no modo promíscuo). - Reconfigure a interface que foi configurada com o prefixo de rede incorreto para ver se isso ajuda.