Como autoconfigurar a rota IPv6

Question

Eu configurei um roteador simples que deve fornecer conectividade IPv6 para máquinas que estão em LAN por trás dele. O roteador possui 2 interfaces de rede (eth0, eth1), as máquinas possuem 1 (eth0).

Na eth0 do roteador está o acesso apenas à rede local, na eth1 está o acesso à internet. Eu configurei todos os parâmetros do kernel, isso funciona bem.

O IP do roteador é fd00::1 , eu instalei o dhcpd no roteador e o intervalo configurado fd00::100 - fd00::fffe .

Quando eu inicio uma máquina nessa rede, ela recebe IP do dhcpd, por exemplo fd00::fffa , mas não consegue acessar a internet por razões óbvias - está faltando a rota.

Quando eu adiciono route by hand sudo route -6 add 2000::/3 gw fd00::1 , a máquina começa a ter acesso à internet até que eu reinicie.

Eu posso adicionar essa rota manualmente no script de inicialização de cada máquina, mas eu prefiro que ela seja autoconfigurada para que, quando eu iniciar uma máquina nessa rede, ela tenha acesso à Internet IPv6 sem necessidade de mais nada.

Baseado em algumas sugestões instalei também radvd no roteador e inseri esta opção:

route 2000::/3 {};

É mais provável que esteja errado, mas não consegui encontrar nenhuma documentação ou exemplos. Não funciona Usar radvd em vez de dhcpd para designar endereços IPv6 não funciona, se eu desabilitar as máquinas dhcpd, autoconfigure alguns endereços IPv6 aleatórios e nem sequer se vejam, nem eles podem fazer o ping do roteador.

Como configuro minha rede local para autoconfigurar o IPv6 para todas as máquinas?

Nota: Eu não preciso nem quero que cada máquina tenha IPv6 público, o NAT é bom.

    

Answer 1

Eu imediatamente identifico dois problemas com sua configuração. Endereços RFC 4193 não são globalmente roteáveis. Isso significa que esses endereços não poderão se comunicar com o mundo exterior.

Claro que você pode usar o NAT, mas o NAT é conhecido por causar vários problemas. NAT é uma solução pretendida para resolver temporariamente a falta de endereços IP. O IPv6 resolve esse problema. Todos os outros problemas que as pessoas tentaram resolver usando o NAT têm uma solução melhor que não envolve NAT.

Além disso, seu prefixo claramente não foi gerado de acordo com as especificações da RFC 4193. Citação relevante:

Locally assigned Global IDs MUST be generated with a pseudo-random algorithm

Se esses dois problemas na configuração de rede impedem que os clientes se comuniquem externamente, você só descobrirá testando-os. Existem softwares que tentam detectar a configuração de IPv6 abaixo do ideal e evitam completamente o uso do IPv6 se algum for detectado. É bastante plausível que algum software cliente se recuse a usar a conexão IPv6 na sua configuração.

Dito isto, não é impossível fazer com que os clientes se comuniquem externamente usando os endereços RFC 4193. Aqui está um arquivo radvd.conf , que usei brevemente no passado. Com essa configuração, alguns clientes tentaram se comunicar externamente usando seus endereços RFC 4193 atribuídos.

interface wlan0 { 
        AdvSendAdvert on;
        MinRtrAdvInterval 3; 
        MaxRtrAdvInterval 10;
        prefix fdbd:5df9:dca3::/64 { 
                AdvOnLink on;
                AdvAutonomous on; 
                AdvRouterAddr on; 
        };
};

Esta configuração, no entanto, não funciona com todos os clientes. Eu testei novamente com um cliente rodando o Android. O telefone conseguiu um endereço IPv6 configurado, mas não tentou usar o IPv6 para comunicação externa.

Em seguida, alterei o prefixo para 2001:db8:dca3::/64 , quando o telefone começou a enviar pacotes IPv6 para o gateway. Então, o Android é um exemplo de uma plataforma que se recusa a usar os endereços RFC 4193 dessa maneira.