Por qué falla el descubrimiento de vecinos IPv6 en una VPN enrutada

El descubrimiento de vecinos IPv6 pertenece a un enlace, y un túnel enrutado es una frontera entre dos enlaces. Esa sola frase explica casi todos los informes de un host remoto que responde por dirección y no se encuentra por ningún otro medio. Comprueba el ámbito de la dirección que estás probando antes de comprobar el túnel. Una dirección local al enlace solo tiene sentido en su propio enlace, y un grupo de multicast de nodo solicitado tiene el mismo ámbito. Ninguna de las dos cruza un enrutador, y por eso un ping a una dirección global puede tener éxito mientras el descubrimiento para el mismo host no.

El ámbito va antes que la configuración

La solicitud y el anuncio de vecino llevan un límite de saltos de 255 y no se reenvían, por diseño. El enrutador entre tu túnel y la LAN remota reenvía paquetes IPv6 y no retransmite mensajes de vecinos en su nombre. Así, la caché de vecinos de la interfaz del túnel contiene al par y poco más, lo que es un comportamiento correcto y no un defecto que corregir.

Una dirección local al enlace como una entrada fe80:: también tiene ámbito de zona, y el mismo texto puede designar a otro host en otro enlace. Probar una desde el otro lado del túnel no demuestra nada salvo que la dirección es ambigua.

La trampa es la suposición de que el prefijo está en el enlace

Un host que cree que un prefijo está en el enlace envía una solicitud de vecino en lugar de entregar el paquete a su enrutador, y eso incluye un /64 enrutado a un sitio remoto. Cuando ese prefijo llega como en el enlace, el host pregunta al enlace local por un host que vive en otro lugar, y nada responde. Enruta algo más pequeño hacia el host remoto, o termina el prefijo en el enrutador que responderá por él.

Un /128 para un solo servicio es la disposición menos sorprendente, y elimina la ambigüedad por completo. La especificación de descubrimiento de vecinos describe el conjunto de mensajes y el indicador de en el enlace que lo decide.

El puente cambia las reglas a propósito

Cuando el túnel transporta tramas Ethernet, los segmentos remoto y local se convierten en un solo enlace, el multicast llega a ambos lados y el descubrimiento de vecinos se comporta como en un conmutador. Las consecuencias llegan con ello: inundación de broadcast y multicast, detección de direcciones duplicadas a través del puente y anuncios de enrutador filtrándose en un segmento que no debería verlos. El dominio de fallo ahora abarca también dos sitios. Nada de eso argumenta contra el puente, y cada punto es una razón para tender un puente a propósito y no de forma incidental.

Cambiar un perfil de TUN a TAP para que aparezca el descubrimiento es el orden equivocado de operaciones. El servidor, el cliente y el plan de direccionamiento tienen que coincidir, y los clientes móviles no ofrecen ninguna interfaz TAP, así que un diseño así funciona en un portátil y falla en un teléfono. Los proxies y repetidores de vecinos son mecanismos separados con sus propios requisitos, y pertenecen a la disposición documentada del administrador de red y no a los ajustes de una aplicación.

Prueba con la dirección que usa la aplicación

Confirma la ruta con ip -6 route get, inspecciona la entrada de vecino con ip -6 neigh y luego confirma el servicio por la ruta enrutada. DNS y el camino de vuelta son comprobaciones separadas, y una entrada de vecino sana no demuestra ninguna de las dos.

Si la aplicación insiste en un destino local al enlace o basado en descubrimiento, eso es una conversación de diseño y no un ejercicio de ajuste, porque ningún ajuste del cliente hace que un mecanismo limitado al enlace funcione a través de un enrutador.

Anota qué diseño tienes

Registra si es enrutado o con puente antes del incidente, porque los dos despliegues responden a estas preguntas de manera distinta y un ingeniero de guardia no debería deducirlo de un perfil.

Leer el conjunto de mensajes una vez elimina la tentación de explicar una propiedad de ámbito de enlace como un error de la VPN, que es el diagnóstico equivocado más caro en esta área.