¿Falla el ping a tu par de túnel IPv6? Comprueba la dirección ::

Un extremo de tu túnel IPv6 hace ping al otro, y solo una dirección responde alguna vez. La interfaz está activa, la ruta parece correcta y nada en el registro lo explica. La dirección que asignaste es la dirección anycast del router de subred, que no es en absoluto una dirección de host, y en un enlace de dos extremos tiene exactamente un destino de entrega: el emisor. Ningún valor de tiempo de espera lo repara, porque la dirección no hace lo que crees.

El síntoma que apunta a la dirección

Todos los hosts del enlace responden salvo el que tiene el identificador de interfaz todo a ceros. Un paquete dirigido a esa forma se entrega por definición a un router de la subred, así que en un túnel punto a punto vuelve a la máquina que lo envió. Desde el extremo lejano se lee como un par inalcanzable; desde el extremo cercano se lee como silencio. Cambia otro identificador del mismo prefijo y el síntoma desaparece sin ningún otro cambio, y esa es la confirmación que hay que obtener antes de tocar rutas.

El identificador todo a ceros está reservado como anycast

RFC 4291 conserva el identificador de interfaz todo a ceros como la dirección anycast del router de subred, así que un /64 como 2001:db8:4a::/64 no contiene ningún host utilizable en 2001:db8:4a::. La reserva se gana su lugar: los anuncios de router y el descubrimiento de vecinos direccionan esa forma, y un router responde por el prefijo que sirve. Asignar ese valor a un extremo de túnel da un papel de router a una hoja, y por eso no vuelve nada. Cualquier otro identificador del prefijo funciona como host, así que la reparación suele ser un dígito.

Trata la reserva como un papel que no tienes derecho a ocupar desde un extremo de túnel, no como una rareza que rodear con una ruta.

Asigna direcciones de host y enruta el prefijo

Elige ::1 y ::2 para los dos extremos, añade una con ip -6 addr add 2001:db8:4a::2/64 dev tun0, y luego enruta el prefijo remoto en lugar de intentar direccionarlo. Una ruta para 2001:db8:4a::/64 por el túnel hace accesible el lado lejano; la dirección sola solo deja configurada la interfaz local.

Para un túnel completo hay un tercer paso, una ruta por defecto para unicast global a través del dispositivo, que es el equivalente IPv6 de enviarlo todo al túnel. Si lo omites, IPv6 sigue usando el enlace físico mientras IPv4 viaja dentro del túnel, así que el host filtra precisamente el tráfico que creías cubierto. Confírmalo con ip -6 route get 2001:4860:4860::8888 y lee qué dispositivo nombra en lugar de suponer la respuesta.

El multicast se rechaza antes del enrutamiento

Android valida direcciones y rutas para VpnService.Builder mediante LinkAddress, y ese constructor rechaza multicast de plano. Dale un prefijo multicast como ruta y el resultado es un fallo de parámetros LinkAddress incorrectos en lugar de una ruta, que es una respuesta de validación y no de red. El rechazo encaja con el medio: un dispositivo tun punto a punto no tiene multicast de capa de enlace, así que una ruta de grupo sobre él no tiene modelo de entrega que instalar. Las direcciones de grupo las crea y consume la propia pila en lugar de configurarse a mano.

Las direcciones IPv6 all-nodes y solicited-node caen bajo la misma regla. La interfaz las lleva porque la pila las puso ahí, no porque una política las pretendiera.

Qué puede llevar un túnel en su lugar

Mover el descubrimiento multicast por un túnel necesita una capa que entienda la pertenencia a grupos: un puente TAP que presente un segmento Ethernet, un relé a nivel de aplicación o un protocolo de enrutamiento al que se le diga explícitamente a qué pares replicar. Nada de eso existe en el modelo VpnService, donde la aplicación lee y escribe paquetes y no tiene llamada que se una a un grupo para el túnel. O añades el componente que entiende grupos o quitas el requisito del diseño.

Unicast, en cambio, no necesita nada extra más allá de las direcciones y rutas anteriores, y por eso se suele esperar que los túneles lo lleven y luego se les culpa cuando falla un protocolo de descubrimiento.

Tres comprobaciones antes de asignar nada

Confirma que la dirección no es la forma anycast, confirma que no es multicast y confirma que el prefijo está enrutado y no solo asignado al dispositivo. Luego envía tu prueba a un destino que sea un host real, porque un ping dirigido a la dirección anycast mide al emisor y no dice nada del camino. Guarda esas tres comprobaciones en el registro de cambios para que el siguiente despliegue no las redescubra.

Una ruta que la plataforma nunca instaló no se puede depurar esperando más tiempo, y una dirección que nunca fue un host no se puede reparar con un ping mejor.