Por qué route -interface no alcanza un host fuera del enlace

route acepta el nombre de la interfaz Wi-Fi, sale sin quejarse y el host sigue inalcanzable. Nada está corrupto; la relación en la ruta simplemente es incorrecta: un indicador de interfaz dice en qué enlace está un destino, no qué router debe recibir el tráfico de un destino que está en otro lugar. El comando tiene éxito porque es sintácticamente válido, no porque describa una ruta que funcione.

Esa distinción decide si una excepción de ruta junto a una VPN funcionará o solo parecerá plausible.

La interfaz es la salida, el siguiente salto es la entrega

En un Mac con dirección 192.168.50.20 y un router en 192.168.50.1, otra máquina del mismo enlace es alcanzable directamente. La trama se dirige a esa máquina y se pone en el cable. No interviene ningún router, y una ruta limitada a la interfaz expresa exactamente eso. Cambie el extremo remoto por un host en otro edificio y el mismo comando deja de tener sentido. El Mac no tiene una dirección de segunda capa para poner en el cable, así que el indicador de interfaz no tiene nada que describir.

Un destino fuera del enlace es distinto. El Mac no puede poner en el cable una trama dirigida a un host que no alcanza en la segunda capa; entrega el paquete a un router que sí puede. La ruta, por tanto, necesita una puerta de enlace, y la puerta misma debe ser alcanzable en el enlace conectado.

Usar el indicador de interfaz para un destino fuera del enlace dice a macOS que trate ese destino como si estuviera en el cable. Entonces el núcleo no logra resolver una dirección de segunda capa para él, y el paquete se descarta sin nada útil en el error.

Qué afirma realmente el indicador de interfaz

La referencia de rutas de Apple define la forma de interfaz para destinos alcanzables directamente sin intermediario. Es una afirmación sobre el modelo de enlace, no una preferencia sobre qué adaptador usar. Alcanzar un host de internet por Wi-Fi sigue requiriendo un router en ese enlace Wi-Fi, y la ruta debe nombrarlo.

El ámbito de interfaz es un atributo aparte. Asocia una ruta con una interfaz concreta para decisiones de ámbito como qué dirección de origen se aplica, pero no crea alcanzabilidad para un destino que la interfaz no puede alcanzar por sí sola. Los dos atributos responden preguntas distintas.

Por eso un comando puede aceptarse, aparecer en la tabla y aun así fallar. El núcleo no valida su intención; registra lo que usted afirmó, y la afirmación era que el destino está en el enlace. Un éxito silencioso seguido de un descarte silencioso es el resultado esperado, no un error. Relea la afirmación antes de culpar a la red.

La ruta que necesita un destino fuera del enlace

Para una ruta aprobada a una dirección de documentación como 198.51.100.25 a través del router LAN, la relación prevista es un destino, un siguiente salto de 192.168.50.1 y la interfaz LAN que alcanza ese siguiente salto. La interfaz se deduce de la búsqueda del siguiente salto en lugar de imponerse por el comando de ruta.

En macOS la inspección de solo lectura es route -n get 198.51.100.25. Lea juntas las líneas de puerta de enlace e interfaz y compruebe que la puerta es una dirección que el Mac puede alcanzar de verdad. Una puerta en otra subred, o una que ha desaparecido desde el último cambio de red, produce una ruta que parece correcta y no reenvía nada.

No fije en0 en una instrucción duradera. Los nombres de interfaz cambian con adaptadores, docks y clientes VPN, y una ruta que nombra el incorrecto falla de un modo fácil de malinterpretar como una avería de red más amplia.

Lea la elección actual antes de reemplazarla

Antes de añadir nada, inspeccione qué ha seleccionado ya el sistema y por qué. Esa salida le dice si el tráfico va por el túnel, por el router LAN o a ninguna parte, y le da una base para comparar después del cambio. Sin ella, no puede saber si la nueva ruta ha surtido efecto.

Luego compruebe la familia de direcciones. Una ruta añadida para IPv4 no hace nada por un destino IPv6, y un servicio que resuelve a ambas familias puede parecer intermitentemente alcanzable. La tabla de rutas y el resolutor responden preguntas distintas, y ambos deben coincidir con la ruta prevista.

Por último, recuerde que una ruta es una selección, no un permiso. Un perfil de VPN gestionado o un filtro de cliente aún pueden prohibir la ruta directa aunque la tabla apunte a ella, así que pruebe con la aplicación real en lugar de suponer que una entrada correcta en la tabla termina la investigación.

Los túneles y la política cambian la forma

Las interfaces punto a punto son su propio caso. Un túnel puede llevar una ruta sin una dirección de puerta de enlace al estilo Ethernet, y eso no es automáticamente incorrecto. Aplique el modelo de enlace real de la interfaz en lugar de extender un ejemplo de Wi-Fi a cada entrada de la tabla que vea.

Para solicitudes de cambio, anote el destino, la ruta de red aprobada, la puerta de enlace y la interfaz actuales, y quién debe mantener la excepción. El propietario importa porque una ruta puntual escrita en el prompt no es una política, y la próxima reconexión la borrará.

Si el requisito es llegar a este host mientras la VPN está activa, la respuesta honesta suele ser una ruta de host específica a través del router local, instalada por el gestor de red que posee la interfaz. Si el requisito es llegar a cualquier cosa directamente, el requisito mismo necesita una revisión de política antes que un comando de ruta.