ipv6 ping host tem destino host inacessível até executar tcpdump

0

No início (todo o computador é inicializado) quando eu ping o gateway (computador linux, duas placas de rede (um é usb)) de um computador windows, eu tenho: "host de destino inacessível", mas quando eu executar " tcpdump -i LANINTERFACE ip6 " no gateway, o ping tem resposta de gateway, o que há de errado com a minha rede, alguma idéia?
O gateway e o computador Windows usam o endereço ipv6 estático.

configuração ipv6 para gateway:

# ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
4: enp0s29f0u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:XXX:YYYY:ZZZZ:WWWW::1111/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:4cff:fe53:4458/64 scope link
       valid_lft forever preferred_lft forever
5: enp2s0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:XXX:YYYY:ZZZZ:WWWW::3333/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::216:d3ff:feb3:34a5/64 scope link
       valid_lft forever preferred_lft forever

Em computadores com Windows (use o seguinte endereço IPv6, estático):

IPv6 address: 2001:XXX:YYYY:ZZZZ:WWWW::6666
Subnet prefix length: 64
Default Gateway: 2001:XXX:YYYY:ZZZZ:WWWW::1111

Tabela de rotas do gateway Linux:

# ip -6 route
2001:XXX:YYYY:ZZZZ::/64 dev enp0s29f0u2  proto kernel  metric 256
2001:XXX:YYYY:ZZZZ::/64 dev enp2s0  proto kernel  metric 256
fe80::/64 dev enp0s29f0u2  proto kernel  metric 256
fe80::/64 dev enp2s0  proto kernel  metric 256
ff00::/8 dev enp0s29f0u2  metric 256
ff00::/8 dev enp2s0  metric 256
default via fe80::1614:4bff:fe60:63eb dev enp2s0  metric 5

Eu tenho uma caixa de linux como roteador (enp2s0, enp0s29f0u2) e outras são computadores windows. O 'Wan' conectado ao adaptador linux box enp2s0, e enp0s29f0u2 conectado a um roteador sem fio (modo de comutação (dhcp off)), todos os windows pc conectados ao roteador wireless.

    
por tmjdone 06.10.2014 / 14:10

1 resposta

0

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). Se tcpdump 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.
por 06.10.2014 / 19:00