IPv6 através de um túnel OpenVPN: uma volta pelo router de casa

O portátil tem um endereço IPv6, o túnel está ativo sobre IPv4 e, mesmo assim, todos os testes IPv6 falham. Ou pior: o teste passa e o tráfego saiu pelo caminho do fornecedor sem nunca entrar no túnel. Ambos os resultados remetem para uma decisão em falta: ninguém deu ao router um prefixo que ele pudesse encaminhar para os clientes. Percorrer o caminho do cliente para fora descobre que peça falta.

Comece onde está o cliente

Veja o cliente antes de tocar no servidor. ip -6 addr deveria mostrar um endereço de túnel do pool, e ip -6 route deveria mostrar o prefixo empurrado que aponta para o dispositivo de túnel. Quando o endereço existe mas a rota não, falta o push ou o cliente ignorou-o. Quando não existe nenhum dos dois, o servidor não atribuiu absolutamente nada.

Depois verifique o que o cliente acredita sobre o mundo exterior. Uma rota predefinida pelo túnel reclama todo o tráfego IPv6, enquanto uma rota para 2000::/3 reclama apenas unicast global. Ambas podem estar certas e respondem a perguntas diferentes sobre fugas.

Um cliente sem qualquer rota predefinida IPv6 falha todos os testes públicos, embora o túnel esteja perfeitamente saudável. Isso é uma lacuna de política, não um túnel avariado.

Verifique o pool que o servidor consegue realmente encaminhar

Um servidor só pode atribuir de um prefixo que controla realmente. Se o fornecedor delegar um /56, reserve um /64 para o túnel e deixe o resto para a LAN. Onde o fornecedor entrega apenas um /64 na WAN e não encaminha mais nada, deixe o prefixo da LAN em paz e dê ao túnel um intervalo local único, aceitando que os clientes não terão saída global.

O pool e o push andam juntos. server-ipv6 2001:db8:80:10::/64 atribui endereços, e push "route-ipv6 2000::/3" diz aos clientes o que enviar para o túnel. Empurrar 2000::/3 cobre o unicast global e deixa os intervalos link-local e multicast fora do túnel.

Escreva o prefixo escolhido no registo de implementação. Quem alterar a entrega do fornecedor da próxima vez precisa de saber que /64 o túnel já ocupa.

Ative o forwarding para a segunda família

O forwarding IPv4 não implica o forwarding IPv6. Defina net.ipv6.conf.all.forwarding=1 e replique tudo o que a política FORWARD de IPv4 já permite. Num router cuja cadeia FORWARD descarta por predefinição, um conjunto de regras ausente parece exatamente um túnel morto.

O aperto de mão tem sucesso, o cliente recebe um endereço e nada volta. Acrescente regras para ambos os sentidos e para o troço WAN, porque um túnel que chega à LAN mas não à internet falha o terceiro teste. Depois de uma tentativa falhada, veja os contadores da cadeia, porque uma regra que nunca correspondeu é um problema diferente de uma que correspondeu e descartou.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Um efeito secundário apanha quem acaba por culpar o túnel. Ativar o forwarding faz o kernel saltar a configuração de endereço via Router Advertisement, salvo indicação em contrário, e uma rota predefinida aprendida assim desaparece com ela. Ou fixa uma rota predefinida explícita na interface WAN, ou define aí accept_ra como 2 de propósito. Depois de qualquer alteração, confirme que o router ainda tem um caminho IPv6 utilizável para fora antes de testar os clientes outra vez.

Responda à descoberta de vizinhos quando a parte de cima não encaminha

O equipamento a montante trata por vezes o /64 delegado como pertencente à sua própria ligação e recusa encaminhar qualquer subprefixo para a caixa VPN. Quando isso acontece, algo tem de responder às solicitações de vizinhos para cada endereço de cliente individualmente.

OpenVPN expõe o endereço atribuído a um hook client-connect, para que as entradas possam seguir o pool real em vez de uma lista mantida à mão. O hook acrescenta ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, e um hook client-disconnect correspondente remove-o. Sem essa remoção, a tabela de proxy fica desatualizada e um cliente posterior pode herdar uma entrada para um endereço que nunca recebeu. Confirme o estado com ip -6 neigh show proxy.

Trate o proxy como uma solução de contorno. Uma rota estática para o /64 do túnel apontada ao router sobrevive às mudanças de clientes e não exige qualquer hook de shell privilegiado.

Siga o caminho para fora, salto a salto

Teste para fora em três passos: primeiro o endereço de túnel do router, depois um anfitrião da LAN e terceiro um destino público via traceroute6. O pool é provado pelo primeiro, o forwarding e a firewall da LAN pelo segundo, e o caminho de volta pela parte de cima pelo terceiro. Cada falha estreita a busca a um único dispositivo em vez de reabrir todo o desenho.

Vigie a MTU do túnel, porque os routers IPv6 no caminho não fragmentam por si. Uma MTU demasiado grande manifesta-se como um erro packet-too-big e TLS bloqueado em vez de uma falha limpa. Defina-a explicitamente e teste com uma carga perto do limite.