tunnel 6in4 para roteador, sucesso parcial

Question

Meu ISP não fornece endereços IPv6 para clientes (apenas um IPv4). Eu tenho um servidor dedicado com endereço IPv4 estático e / 64 bloco IPv6, então eu decido ser meu próprio corretor de túneis (6in4). Sim, posso usar o tunnerbroker.net, mas quero aprender sozinho.

Meta: forneça o túnel 6in4 do servidor com a conexão IPv4 + IPv6 (eth0) nativa para os clientes atrás do roteador doméstico apenas com IPv4.

O que eu fiz:

Lado do servidor:

ip tunnel add sit5 mode sit ttl 255 remote [home_router_ipv4] local [server_ipv4]
ip link set dev sit5 up
ip -6 addr add [ipv6]::1/64 dev sit5
ip -6 route add [ipv6]::/64 via [ipv6]::2 dev sit5 metric 1
ip -6 neigh add proxy [ipv6]::2 dev eth0

sysctl:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.proxy_ndp=1
net.ipv4.conf.all.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0
net.ipv4.conf.all.send_redirects=0

Lado do cliente:

O roteador executando o DD-WRT com suporte nativo para túneis de 6 em 4 com radvd para propagação de endereço para os clientes (testado com sucesso para o tunnelbroker.net).

config radvd:

interface br0
{
 IgnoreIfMissing on;
 AdvSendAdvert on;
 MinRtrAdvInterval 3;
 MaxRtrAdvInterval 10;
 AdvHomeAgentFlag off;
 AdvManagedFlag off;
 AdvOtherConfigFlag on;
 AdvLinkMTU 1480;
 prefix [ipv6]::/64
 {
  AdvOnLink on;
  AdvAutonomous on;
 };
 RDNSS [ipv6]::1 2620:0:ccd::2 {};
};

Problema: O roteador está corretamente conectado via túnel à rede IPv6 (ele pode navegar na rede ipv6), mas os clientes não (eles recebem o endereço ipv6 correto, mas não podem pingar nada, inclusive o roteador e servidor).

Quando estou fazendo um traceroute6 do servidor para o cliente, tenho um loop de roteamento:

# traceroute6 [ipv6]:4d34:1981:aba6:620c
traceroute to [ipv6]:4d34:1981:aba6:620c ([ipv6]:4d34:1981:aba6:620c) from [ipv6]::1, 30 hops max, 24 byte packets
 1  [ipv6]::2 ([ipv6]::2)  43.446 ms  44.439 ms  39.687 ms
 2  [ipv6]::1 ([ipv6]::1)  41.955 ms  41.391 ms  43.225 ms
 3  [ipv6]::2 ([ipv6]::2)  80.456 ms  80.515 ms  81.893 ms
 4  [ipv6]::1 ([ipv6]::1)  81.966 ms  83.338 ms  92.166 ms
    ...

    

Answer 1

O primeiro problema é que você usou a mesma sub-rede em dois lugares - sua LAN e o túnel p2p. Embora isso possa funcionar depois de algumas discussões sobre rotas, não é uma boa ideia.

(Observe como o Tunnelbroker também aloca duas sub-redes: uma / 64 apenas para o link ponto-a-ponto, mais uma sub-rede 'roteada' para a LAN.)

Portanto, se você tiver apenas um / 64, use-o somente para LAN. O túnel p2p funcionará muito bem com o endereçamento link-local (ou, na verdade, nenhum endereçamento, por ser um link p2p).

Então, ao invés desses comandos ...

ip -6 addr add [ipv6]::1/64 dev sit5
ip -6 route add [ipv6]::/64 via [ipv6]::2 dev sit5 metric 1

use algo assim:

ip -6 addr add fe80::1/64 dev sit5
ip -6 route add [ipv6]::/64 via fe80::2 dev sit5

ou até mesmo um link completamente não numerado:

# <no 'addr add' necessary>
ip -6 route add [ipv6]::/64 dev sit5

Claro, configure o roteador doméstico de acordo - neste exemplo, ele teria o endereço fe80::2/64 e usaria fe80::1 como o gateway.

Observação: acima não é necessariamente uma solução completa. Eu tenho essa suspeita de que você pode estar usando o mesmo / 64 em três links de uma vez (LAN, p2p e eth0 do próprio servidor), o que provavelmente vai precisar ainda mais bandaids do que o habitual.

O segundo problema é que, como eu entendi, o seu provedor de servidor configura o / 64 como uma sub-rede on-link , em vez de rotear em direção ao servidor.

Esse é um problema irritante (se infelizmente comum) em um link significa que seu servidor terá que procurar por Neighbor Novel para todos os endereços que seus dispositivos de rede local usam;

Então o seu próprio roteador tem acesso à Internet porque você usou este comando:

ip -6 neigh add proxy [ipv6]::2 dev eth0

Mas você teria que repeti-lo para todos os dispositivos, sem mencionar os endereços de 'privacidade' gerados temporariamente que seus PCs poderiam usar.

Seria melhor se o seu provedor de servidor pudesse reconfigurar o / 64 para ser encaminhado para o seu servidor (pergunte via e-mail ou ticket talvez) - isso tornaria o proxy ND totalmente desnecessário.

Se isso não for possível, talvez seja necessário executar ndppd para o ND-proxying em todo o / 64.

No final, pode ser mais fácil confiar apenas no Tunnelbroker ou no NetAssist.