O servidor de encapsulamento Linux 6in4 não pode encaminhar corretamente os pacotes IPv6 devido à falha na descoberta do vizinho

1

Estou tentando configurar o servidor de encapsulamento 6in4 no meu VPS. Cliente e servidor podem pingar endereços IPv6 uns dos outros, quando eu tento pingar um servidor externo do cliente, eu recebo erro inacessível de endereço ICMP.

Mas eu posso fazer ping no site IPv6 do servidor sem problemas, e depois do ping do servidor, eu sou capaz de fazer ping do cliente em cerca de 30 segundos, depois disso eu recebo novamente o erro de endereço ICMP inacessível.

O tcpdump mostra que, ao fazer o ping do servidor, ele enviará um pacote de solicitação vizinho usando seu endereço IPv6 público e obterá corretamente o anúncio vizinho do gateway. Mas ao fazer o ping do cliente, o servidor enviará o pacote de solicitação do vizinho usando seu endereço de link local e não receberá nada de volta. Depois de algumas tentativas, o servidor desistirá e retornará o endereço ICMP inacessível para o cliente.

Como posso consertar isso? Eu sei que posso adicionar uma entrada vizinha permanente ao gateway, mas isso é bastante hacky, então eu quero evitá-lo, se possível.

Aqui estão algumas informações extras:

  • SO do servidor: Ubuntu 13.10 Server

  • uname -a : Linux 3.11.0-19-generic #33-Ubuntu SMP Tue Mar 11 18:48:34 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

  • Meu ISP me deu apenas um bloco / 112, então usei npd6 para lidar com pacotes de solicitação do vizinho de entrada

  • ip6tables não tem entrada na tabela INPUT e OUTPUT

tcpdump (ao pingar do servidor):

18:14:33.988952 IP6 [server's public IPv6 address] > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has [gateway's IPv6 address], length 32
18:14:33.989410 IP6 [gateway's IPv6 address] > [server's public IPv6 address]: ICMP6, neighbor advertisement, tgt is [gateway's IPv6 address], length 32
18:14:33.989428 IP6 [server's public IPv6 address] > google-public-dns-a.google.com: ICMP6, echo request, seq 1, length 64
18:14:34.038299 IP6 google-public-dns-a.google.com > [server's public IPv6 address]: ICMP6, echo reply, seq 1, length 64

tcpdump (ao fazer o ping do cliente, note que fe80 :: 5054: ff: fe3b: 3836 é o endereço local do servidor):

18:12:35.284184 IP [client's IPv4 address] > server: IP6 [sit tunnel address (client)] > google-public-dns-a.google.com: ICMP6, echo request, seq 1, length 64
18:12:35.284263 IP6 fe80::5054:ff:fe3b:3836 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has [gateway's IPv6 address], length 32
18:12:36.282458 IP6 fe80::5054:ff:fe3b:3836 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has [gateway's IPv6 address], length 32
18:12:37.282470 IP6 fe80::5054:ff:fe3b:3836 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has [gateway's IPv6 address], length 32
18:12:38.282503 IP server > [client's IPv4 address]: IP6 [sit tunnel address (server)] > [sit tunnel address (client)]: ICMP6, destination unreachable, unreachable address google-public-dns-a.google.com, length 112

Após o ping do cliente, a saída de ip neigh no servidor se parece com isso (entradas irrelevantes removidas):

[gateway's IPv6 address] dev eth0  router FAILED

ip addr e ip -6 route (os endereços são anônimos):

.. snipped ..
2: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
    inet .. snipped .. scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:aa:b::cccc:1/48 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe3b:3836/64 scope link 
       valid_lft forever preferred_lft forever

9: sit: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1472 qdisc noqueue state UNKNOWN 
    link/sit .. snipped .. peer 1.2.3.4
    inet6 2001:db8:aa:b::cccc:8001/120 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::dafb:71de/128 scope link 
       valid_lft forever preferred_lft forever

::1.2.3.4 dev sit  metric 1024 
2001:db8:aa:b::cccc:8000/120 dev sit  proto kernel  metric 256
2001:db8:aa::/48 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via 2001:db8:aa::1 dev eth0  metric 1024 
    
por SAPikachu 16.04.2014 / 12:15

1 resposta

1

Esta configuração está fundamentalmente quebrada. Você vai precisar de muitos hacks, como rotas estáticas, proxy-NDP, etc para fazer o trabalho. Não há soluções bonitas aqui ...

Agora, como deve ser feito é:

  • O ISP fornece um / 48 de espaço de endereço IPv6
  • Toda LAN é uma / 64
  • Seus servidores estão em um / 64 diretamente conectados ao ISP
  • O seu ISP fornece-lhe uma forma de encaminhar prefixos para o (s) seu (s) servidor (es)
    • o roteamento estático é comum nos ISPs que eu conheço
    • O DHCPv6-PD com concessões longas e estáveis também pode resolvê-lo
por 16.04.2014 / 13:22

Tags