Por que falla o descubrimento de veciños IPv6 nunha VPN encamiñada

O descubrimento de veciños IPv6 pertence a unha ligazón, e un túnel encamiñado é unha fronteira entre dúas ligazóns. Esa única frase explica case todos os informes dun host remoto que responde pola súa dirección e non se atopa por ningún outro medio. Comproba o ámbito da dirección que estás a probar antes de comprobar o túnel. Unha dirección local á ligazón só ten sentido na súa propia ligazón, e un grupo de multicast de nodo solicitado ten o mesmo ámbito. Ningunha das dúas cruza un encamiñador, e por iso un ping a unha dirección global pode ter éxito mentres o descubrimento para o mesmo host non.

O ámbito vai antes ca a configuración

A solicitude e o anuncio de veciño levan un límite de saltos de 255 e non se reenvían, por deseño. O encamiñador entre o teu túnel e a LAN remota reenvía paquetes IPv6 e non retransmite mensaxes de veciños no seu nome. Así, a caché de veciños da interface do túnel contén o par e pouco máis, o que é un comportamento correcto e non un defecto que corrixir.

Unha dirección local á ligazón como unha entrada fe80:: tamén ten ámbito de zona, e o mesmo texto pode designar outro host noutra ligazón. Probar unha desde o outro lado do túnel non demostra nada agás que a dirección é ambigua.

A trampa é a suposición de que o prefixo está na ligazón

Un host que cre que un prefixo está na ligazón envía unha solicitude de veciño en lugar de entregar o paquete ao seu encamiñador, e iso inclúe un /64 encamiñado a un sitio remoto. Cando ese prefixo chega como na ligazón, o host pregunta á ligazón local por un host que vive noutro lugar, e nada responde. Encamiña algo máis pequeno cara ao host remoto, ou remata o prefixo no encamiñador que responderá por el.

Un /128 para un único servizo é a disposición menos sorprendente, e elimina a ambigüidade por completo. A especificación de descubrimento de veciños describe o conxunto de mensaxes e o indicador de na ligazón que o decide.

A ponte cambia as regras a propósito

Cando o túnel transporta tramas Ethernet, os segmentos remoto e local convértense nunha soa ligazón, o multicast chega a ambos os lados e o descubrimento de veciños compórtase como nun conmutador. As consecuencias chegan con iso: inundación de broadcast e multicast, detección de enderezos duplicados a través da ponte e anuncios de encamiñador que se filtran nun segmento que non debería velos. O dominio de fallo agora abrangue tamén dous sitios. Nada diso argumenta contra a ponte, e cada punto é unha razón para tender unha ponte a propósito e non de forma incidental.

Cambiar un perfil de TUN a TAP para que apareza o descubrimento é a orde equivocada de operacións. O servidor, o cliente e o plan de enderezamento teñen que coincidir, e os clientes móbiles non ofrecen ningunha interface TAP, así que un deseño así funciona nun portátil e falla nun teléfono. Os proxies e repetidores de veciños son mecanismos separados cos seus propios requisitos, e pertencen á disposición documentada do administrador de rede e non aos axustes dunha aplicación.

Proba coa dirección que usa a aplicación

Confirma a ruta con ip -6 route get, inspecciona a entrada de veciño con ip -6 neigh e despois confirma o servizo pola ruta encamiñada. O DNS e o camiño de volta son comprobacións separadas, e unha entrada de veciño saudable non demostra ningunha das dúas.

Se a aplicación insiste nun destino local á ligazón ou baseado no descubrimento, iso é unha conversa de deseño e non un exercicio de axuste, porque ningún axuste do cliente fai que un mecanismo limitado á ligazón funcione a través dun encamiñador.

Anota que deseño tes

Rexistra se é encamiñado ou con ponte antes do incidente, porque os dous despregamentos responden a estas preguntas de xeito distinto e un enxeñeiro de garda non debería deducilo dun perfil.

Ler o conxunto de mensaxes unha vez elimina a tentación de explicar unha propiedade de ámbito de ligazón como un erro da VPN, que é o diagnóstico equivocado máis caro nesta área.