IPv6 de enlace local no funciona por VPN: por qué fe80 se queda en el enlace
Una dirección fe80:: solo significa algo en un enlace. Vea por qué una VPN enrutada no puede transportarla, cómo se ve el fallo y qué dirección usar en su lugar.
Levanta el túnel, hace ping a fe80::1 con el túnel como interfaz de origen y no recibe nada. No es una regla de cortafuegos que olvidó. Una dirección de enlace local solo significa algo en el único enlace donde se formó, y una VPN enrutada no es ese enlace. La fe80::1 del router remoto vive en el segmento remoto de la LAN; usted está a un salto de distancia en otro segmento, e IPv6 no tiene ningún mecanismo para que un router reenvíe paquetes de enlace local.
El prefijo fe80 describe un ámbito, no un rango
El unicast de enlace local es fe80::/10, y la propiedad que lo define no es el número sino el ámbito. La dirección solo es válida en un enlace, y cada interfaz forma una a partir de su propio identificador; por eso dos máquinas sin relación en dos redes sin relación pueden responder ambas a fe80::1 sin el menor conflicto. El prefijo básicamente dice «en algún enlace»; el enlace mismo viene del contexto.
En un host, ese contexto es la zona, o el ID de ámbito, que añade tras un signo de porcentaje: fe80::1%eth0 en Linux, fe80::1%3 o fe80::1%12 en Windows y en herramientas que exponen índices de interfaz. El núcleo resuelve la dirección junto con el índice de interfaz y luego envía. Quite la zona y el destino queda ambiguo, así que la pila no tiene forma de elegir un segmento.
Por qué un túnel enrutado no puede entregarla
Una VPN enrutada es una interfaz punto a punto que lleva sus propias direcciones, normalmente un /64 de espacio IPv6 único-local o privado dentro del túnel. La LAN remota es un enlace aparte, alcanzado porque el extremo del túnel enruta y reenvía en su nombre. Son dos segmentos distintos, así que una dirección de uno no es un destino válido en el otro.
La regla de reenvío es explícita en el estándar y no una rareza de su cliente: los routers no reenvían paquetes con origen o destino de enlace local. Por eso el paquete muere incluso cuando la tabla de rutas parece correcta. Añada una ruta para fe80::/64 hacia el túnel y una pila conforme al estándar o bien la rechaza o bien la acepta y descarta todos los paquetes que coincidan: el ámbito del destino dice «solo este enlace», y la interfaz de salida no es ese enlace.
El descubrimiento de vecinos refuerza la misma frontera. Los hosts resuelven los siguientes saltos de enlace local con una solicitud de vecino enviada a multicast de ámbito de enlace con un límite de saltos de 255, de modo que los routers pueden rechazar cualquier cosa reenviada. Hacerlo funcionar por un túnel significaría hacer de proxy del descubrimiento para un segmento remoto, que es un puente de capa 2 con otro sombrero.
Hay un segundo fallo más silencioso, y hace tropezar a quien intenta forzar la ruta de todos modos: la zona. Cualquier zona que escriba localmente nombra la interfaz del túnel, mientras que la dirección que quiere está ligada a la interfaz de la LAN remota. Las dos nunca coinciden, así que el paquete no puede dirigirse a la interfaz correcta en el extremo opuesto.
Cómo se ve el fallo en la práctica
La salida de las herramientas ante un error de ámbito se lee como un error de enrutamiento o de cortafuegos, y es exactamente por eso que la gente pasa una tarde en la capa equivocada.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
La tercera fila es la que más tiempo hace perder, porque un cliente ssh sin salida parece un problema del servicio que escucha. Si tiene cualquier vía de entrada, mire el lado remoto y confirme si sshd está ligado a todas las direcciones o solo a una.
Use una dirección pensada para ser enrutada
Para cualquier cosa a la que deba llegar por el túnel, use la dirección que se dio al servicio para ese propósito: una dirección unicast global, o una dirección único-local de fc00::/7, el rango reservado exactamente para este caso interno. Confirme que el oyente la liga de verdad, y confirme la ruta de vuelta y cualquier regla de cortafuegos del host.
Mire el host remoto en lugar de adivinar. ip -6 addr show lista las direcciones que existen, y ss -6 -ltn lista en qué escucha el demonio. Un servicio ligado solo a fe80:: es alcanzable solo desde su propio segmento, lo que normalmente es una opción por defecto que nadie eligió a propósito y que puede cambiarse con el acuerdo del administrador.
Cuando el servicio realmente no puede volver a ligarse, suba el puente a la capa de aplicación en lugar de la de red. Un repetidor en el host remoto que escucha en una dirección enrutable y se conecta a la de enlace local resuelve el problema sin extender ningún segmento:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Aquí la zona está en el lado correcto, en el host que realmente tiene eth0 en ese enlace. Su cliente habla con fd00:1:2::10, que se enruta con normalidad, y el repetidor hace local el salto de enlace local. El mismo truco funciona para la interfaz web de un aparato o un BMC antiguo que solo anuncia una dirección de enlace local.
Cuándo el puente es realmente la respuesta, y qué comprobar
Algunos despliegues sí necesitan un segmento compartido: un dispositivo que solo habla descubrimiento de enlace local, un aparato que depende de multicast, un laboratorio que reproduce una LAN plana. Eso es un problema de capa 2 y necesita una respuesta de capa 2, como un dispositivo tap puenteado a la interfaz remota o un producto cliente con un modo puente explícito. Le cuesta tráfico de difusión y multicast atravesando el túnel, además de descubrimiento de vecinos que debe funcionar de extremo a extremo.
No lo aproxime añadiendo fe80::/64 a un perfil enrutado. Eso produce el peor estado de todos: la configuración parece terminada, la tabla de rutas muestra una entrada y cada paquete sigue descartándose en algún lugar entre dos pilas que ambas se comportan correctamente.
Verifique con la interfaz, no con el ping. ip -6 addr show tun0 le dice si el enlace del túnel formó una dirección de enlace local propia, y ip -6 route get fe80::1%tun0 le dice qué haría realmente el núcleo con un destino con ámbito. Cuando el núcleo dice que el destino no es alcanzable en esa interfaz, ninguna configuración del túnel lo cambiará, y es hora de dejar de editar el perfil.
Una secuencia breve que resuelve la cuestión:
- Lea la dirección en el host remoto y anote si es fe80:: o un prefijo enrutable.
- Si es fe80::, vuelva a ligar el servicio, repita en ese host o puentee el segmento; si es enrutable, corrija la ruta, el cortafuegos o la dirección de enlace.
- Revise la zona cada vez que vuelva a probar, porque un comando copiado suele conservar la interfaz equivocada.