O ping ao par do túnel IPv6 falha? Verifique o endereço ::

Uma extremidade do seu túnel IPv6 faz ping à outra, e só uma direção responde alguma vez. A interface está ativa, a rota parece correta e nada no registo o explica. O endereço que atribuiu é o endereço anycast do router da sub-rede, que não é de todo um endereço de host, e numa ligação de dois extremos tem exatamente um destino de entrega: o emissor. Nenhum valor de timeout o corrige, porque o endereço não faz o que pensa.

O sintoma que aponta para o endereço

Todos os hosts da ligação respondem exceto aquele cujo identificador de interface é todo a zero. Um pacote endereçado a essa forma é entregue por definição a um router da sub-rede, por isso num túnel ponto a ponto volta à máquina que o enviou. Do extremo distante isto lê-se como um par inalcançável; do extremo próximo como silêncio. Troque por outro identificador do mesmo prefixo e o sintoma desaparece sem qualquer outra alteração, e essa é a confirmação a obter antes de tocar nas rotas.

O identificador todo a zero está reservado como anycast

A RFC 4291 mantém o identificador de interface todo a zero como o endereço anycast do router da sub-rede, por isso um /64 como 2001:db8:4a::/64 não contém nenhum host utilizável em 2001:db8:4a::. A reserva merece o seu lugar: os anúncios de router e a descoberta de vizinhos endereçam essa forma, e um router responde pelo prefixo que serve. Atribuir esse valor a um extremo do túnel dá um papel de router a uma folha, e é por isso que nada volta. Qualquer outro identificador no prefixo funciona como host, pelo que a reparação costuma ser um dígito.

Trate a reserva como um papel que não tem o direito de ocupar a partir de um extremo do túnel, e não como uma peculiaridade a contornar com uma rota.

Atribua endereços de host e encaminhe o prefixo

Escolha ::1 e ::2 para os dois extremos, acrescente um com ip -6 addr add 2001:db8:4a::2/64 dev tun0, e depois encaminhe o prefixo remoto em vez de tentar endereçá-lo. Uma rota para 2001:db8:4a::/64 pelo túnel torna o lado distante alcançável; o endereço sozinho apenas configura a interface local.

Para um túnel completo há um terceiro passo, uma rota predefinida para unicast global através do dispositivo, que é o equivalente IPv6 de enviar tudo para o túnel. Se o omitir, o IPv6 continua a usar a ligação física enquanto o IPv4 viaja dentro do túnel, pelo que o host fuga precisamente o tráfego que julgava coberto. Confirme com ip -6 route get 2001:4860:4860::8888 e leia que dispositivo nomeia em vez de assumir a resposta.

O multicast é recusado antes do encaminhamento

O Android valida endereços e rotas para VpnService.Builder através de LinkAddress, e esse construtor recusa multicast de imediato. Dê-lhe um prefixo multicast como rota e o resultado é uma falha de parâmetros LinkAddress incorretos em vez de uma rota, o que é uma resposta de validação e não de rede. A recusa corresponde ao meio: um dispositivo tun ponto a ponto não tem multicast de camada de ligação, por isso uma rota de grupo nele não tem modelo de entrega para instalar. Os endereços de grupo são criados e consumidos pela própria pilha em vez de configurados à mão.

Os endereços IPv6 all-nodes e solicited-node caem na mesma regra. A interface transporta-os porque a pilha os colocou ali, não porque uma política os pretendesse.

O que um túnel pode transportar em vez disso

Mover a descoberta multicast através de um túnel exige uma camada que compreenda a pertença a grupos: uma ponte TAP que apresente um segmento Ethernet, um relé ao nível da aplicação ou um protocolo de encaminhamento ao qual se diga explicitamente a que pares replicar. Nada disso existe no modelo VpnService, onde a aplicação lê e escreve pacotes e não tem chamada que se junte a um grupo para o túnel. Ou acrescenta o componente que compreende grupos ou retira o requisito do desenho.

O unicast, pelo contrário, não precisa de nada além dos endereços e rotas acima, e é por isso que normalmente se espera que os túneis o transportem e depois se lhes atribui a culpa quando um protocolo de descoberta falha.

Três verificações antes de atribuir seja o que for

Confirme que o endereço não é a forma anycast, confirme que não é multicast e confirme que o prefixo está encaminhado e não apenas atribuído ao dispositivo. Depois envie o seu teste para um destino que seja um host real, porque um ping dirigido ao endereço anycast mede o emissor e não diz nada sobre o caminho. Guarde essas três verificações no registo de alterações para que a implantação seguinte não as redescubra.

Uma rota que a plataforma nunca instalou não se depura esperando mais tempo, e um endereço que nunca foi host não se repara com um ping melhor.