169.254 por VPN: la dirección nunca fue enrutable
Un destino local de enlace se descarta antes de llegar al túnel, así que añadir rutas solo amplía el fallo. Elija entre reparar la subred y tender un puente.
Añade la ruta, el túnel sube y, aun así, el ping al otro lado muere con pérdida total en lugar de «network unreachable». La diferencia importa, porque aparta la vista de la tabla de rutas y la lleva a la dirección misma. Un destino 169.254 es local de enlace, y su ámbito termina en el primer salto por diseño, no por mala configuración.
La decisión que sigue es estrecha y conviene tomarla explícitamente: reparar la subred del lado del servidor o ampliar el segmento de capa 2 para que la dirección vuelva a tener sentido local. Todo lo demás, incluida una ruta más amplia, solo hace que el mismo fallo afecte a más destinos.
La dirección no es sin ruta: es inenrutable
Las direcciones IPv4 locales de enlace se asignan solas cuando nada mejor responde; de ahí viene el direccionamiento privado automático de Windows y el equivalente de otros sistemas. El rango se usa en cada enlace a la vez, y por eso funciona: dos equipos del mismo segmento hablan sin coordinación.
Esa misma propiedad es la razón por la que un enrutador no debe reenviar estos paquetes entre redes. Recibir un paquete dirigido a un destino local de enlace y sacarlo por otra interfaz crearía ambigüedad, porque lo «local» del emisor y lo «local» del receptor son sitios distintos. Ninguna consulta puede decidir cuál de los dos quiso decir el emisor. El reenvío no es una opción de política que un administrador pueda activar aquí; la clase de dirección lo excluye.
Así, una puerta de enlace que instala 169.254.1.10 como alcanzable por el túnel pide al núcleo algo que el formato de la dirección prohíbe. El paquete se descarta mucho antes de llegar al equipo remoto, y ninguna precisión de ruta cambia ese resultado.
Por qué un túnel hace visible el problema de ámbito
Una interfaz TUN transporta paquetes IP entre dos pares y no tiene ningún segmento compartido detrás. No hay difusión, ni ARP para el otro lado, ni descubrimiento de vecinos que resuelva un destino local de enlace a una dirección de capa de enlace.
Los síntomas encajan cuando sabes qué buscar. La ruta está en la tabla, ping informa pérdida total en lugar de red inalcanzable y la tabla de vecinos muestra una entrada incompleta o fallida. Una captura en el túnel muestra el paquete saliendo, lo que empuja a mirar el extremo remoto en vez de la clase de dirección.
En Windows hay un segundo síntoma, en apariencia no relacionado, con la misma raíz: un adaptador que solo conserva una dirección local de enlace no tiene puerta de enlace utilizable, así que la identificación de red no clasifica la conexión y el perfil del cortafuegos acaba en público. El túnel no es la causa; la dirección sí.
Decida con tres preguntas
La elección entre reparar la subred y puentear el enlace depende de tres condiciones, y cualquiera de ellas puede resolverla antes de que abra un archivo de configuración.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
La mayoría de los casos se detienen en la primera pregunta. Un equipo con dirección local de enlace suele significar que DHCP no respondió, que un cable o una VLAN están mal, o que alguien escribió la dirección a mano. Repararlo es más barato que cualquier trabajo en el túnel y elimina el problema para todos los clientes futuros, no solo para este.
Compruebe el lado del servidor antes de suponer nada. Ejecute ip addr show y ip route en el equipo, y arp -n o route print -4 en el cliente, para ver si el prefijo existe o si solo una entrada antigua lo afirma.
Qué cuesta un puente cuando es la respuesta correcta
Puentear un adaptador físico con un adaptador TAP hace que el cliente remoto forme parte del dominio de difusión local. Entonces la difusión y el descubrimiento de vecinos funcionan, y una dirección local de enlace vuelve a tener sentido porque el cliente es realmente local en ese enlace.
Los costes son reales y hay que decirlos antes de que alguien acepte. El tráfico de difusión cruza el túnel, el cliente queda expuesto al segmento local para todo y no solo para los servicios que necesita, y el servidor ahora reenvía tramas en lugar de enrutar paquetes. Es un intercambio razonable para un banco de laboratorio o un dispositivo sin ruta de configuración enrutable, y un mal valor por defecto para el acceso remoto.
Cuando haga el puente, hacen falta las dos mitades: el puente en el servidor y una ruta en el perfil del cliente que diga qué destinos están al otro lado. Un puente solo deja al cliente adivinando, y una ruta sola no arregla una clase de dirección.