Por que a descoberta de vizinhos IPv6 falha através de uma VPN roteada

A descoberta de vizinhos IPv6 pertence a um link, e um túnel roteado é uma fronteira entre dois links. Essa única frase explica quase todos os relatos de um host remoto que responde pelo endereço e não é encontrado por nenhum outro meio. Verifique o escopo do endereço que você está testando antes de verificar o túnel. Um endereço local ao link só faz sentido no próprio link, e um grupo multicast de nó solicitado tem o mesmo escopo. Nenhum dos dois atravessa um roteador, e é por isso que um ping para um endereço global pode funcionar enquanto a descoberta para o mesmo host não.

O escopo vem antes da configuração

A solicitação e o anúncio de vizinho carregam um limite de saltos de 255 e não são encaminhados, por projeto. O roteador entre o seu túnel e a LAN remota encaminha pacotes IPv6 e não repassa mensagens de vizinhos em nome dele. Assim, o cache de vizinhos na interface do túnel contém o par e pouco mais, o que é comportamento correto e não um defeito a corrigir.

Um endereço local ao link como uma entrada fe80:: também tem escopo de zona, e o mesmo texto pode designar outro host em outro link. Testar um deles do outro lado do túnel não prova nada além de que o endereço é ambíguo.

A armadilha é a suposição de que o prefixo está no link

Um host que acredita que um prefixo está no link envia uma solicitação de vizinho em vez de entregar o pacote ao seu roteador, e isso inclui um /64 roteado para um site remoto. Quando esse prefixo chega como no link, o host pergunta ao link local por um host que vive em outro lugar, e nada responde. Rotear algo menor para o host remoto, ou terminar o prefixo no roteador que responderá por ele.

Um /128 para um único serviço é o arranjo menos surpreendente, e elimina a ambiguidade por completo. A especificação de descoberta de vizinhos descreve o conjunto de mensagens e o sinalizador no link que decide isso.

O bridge muda as regras de propósito

Quando o túnel transporta quadros Ethernet, os segmentos remoto e local tornam-se um único link, o multicast alcança os dois lados e a descoberta de vizinhos se comporta como em um switch. As consequências vêm com isso: inundação de broadcast e multicast, detecção de endereços duplicados através da ponte e anúncios de roteador vazando para um segmento que não deveria vê-los. O domínio de falha agora abrange também dois sites. Nada disso argumenta contra o bridge, e cada ponto é uma razão para fazer bridge deliberadamente e não por acidente.

Mudar um perfil de TUN para TAP para fazer a descoberta aparecer é a ordem errada de operações. O servidor, o cliente e o plano de endereçamento precisam concordar, e clientes móveis não oferecem interface TAP nenhuma, então esse projeto funciona em um notebook e falha em um telefone. Proxies e repetidores de vizinhos são mecanismos separados com requisitos próprios, e pertencem ao arranjo documentado do administrador de rede e não às configurações de um aplicativo.

Teste com o endereço que a aplicação usa

Confirme a rota com ip -6 route get, inspecione a entrada de vizinho com ip -6 neigh e então confirme o serviço pelo caminho roteado. DNS e o caminho de volta são verificações separadas, e uma entrada de vizinho saudável não prova nenhuma das duas.

Se a aplicação insiste em um destino local ao link ou baseado em descoberta, isso é uma conversa de projeto e não um exercício de ajuste, porque nenhuma configuração de cliente faz um mecanismo limitado ao link funcionar através de um roteador.

Anote qual projeto você tem

Registre se é roteado ou com ponte antes do incidente, porque as duas implantações respondem a essas perguntas de forma diferente e um engenheiro de plantão não deveria deduzir isso de um perfil.

Ler o conjunto de mensagens uma vez remove a tentação de explicar uma propriedade de escopo de link como um bug da VPN, que é o diagnóstico errado mais caro nesta área.