Por que route -interface non alcanza un host fóra da ligazón

route acepta o nome da interface Wi-Fi, sae sen queixarse e o host segue inalcanzable. Nada está corrupto; a relación na ruta simplemente é incorrecta: un indicador de interface di en que ligazón está un destino, non que router debe recibir o tráfico dun destino que está noutro lugar. O comando ten éxito porque é sintacticamente válido, non porque describa un camiño que funcione.

Esa distinción decide se unha excepción de ruta xunto a unha VPN funcionará ou só parecerá plausible.

A interface é a saída, o seguinte salto é a entrega

Nun Mac con enderezo 192.168.50.20 e un router en 192.168.50.1, outra máquina na mesma ligazón é alcanzable directamente. A trama diríxese a esa máquina e ponse no cable. Non intervé ningún router, e unha ruta limitada á interface expresa exactamente iso. Cambie o extremo remoto por un host noutro edificio e o mesmo comando deixa de ter sentido. O Mac non ten un enderezo de segunda capa para pór no cable, así que o indicador de interface non ten nada que describir.

Un destino fóra da ligazón é distinto. O Mac non pode pór no cable unha trama dirixida a un host que non alcanza na segunda capa; entrega o paquete a un router que si pode. A ruta, xa que logo, necesita unha pasarela, e a pasarela mesma debe ser alcanzable na ligazón conectada.

Usar o indicador de interface para un destino fóra da ligazón di a macOS que trate ese destino coma se estivese no cable. Entón o núcleo non logra resolver un enderezo de segunda capa para el, e o paquete descártase sen nada útil no erro.

Que afirma realmente o indicador de interface

A referencia de rutas de Apple define a forma de interface para destinos alcanzables directamente sen intermediario. É unha afirmación sobre o modelo de ligazón, non unha preferencia sobre que adaptador usar. Alcanzar un host de internet por Wi-Fi segue requirindo un router nesa ligazón Wi-Fi, e a ruta debe nomealo.

O ámbito de interface é un atributo aparte. Asocia unha ruta cunha interface concreta para decisións de ámbito como que enderezo de orixe se aplica, pero non crea alcanzabilidade para un destino que a interface non pode alcanzar por si soa. Os dous atributos responden preguntas distintas.

Por iso un comando pode aceptarse, aparecer na táboa e aínda así fallar. O núcleo non valida a súa intención; rexistra o que vostede afirmou, e a afirmación era que o destino está na ligazón. Un éxito silencioso seguido dun descarte silencioso é o resultado esperado, non un erro. Relle a afirmación antes de culpar a rede.

A ruta que necesita un destino fóra da ligazón

Para unha ruta aprobada a un enderezo de documentación como 198.51.100.25 a través do router LAN, a relación prevista é un destino, un seguinte salto de 192.168.50.1 e a interface LAN que alcanza ese seguinte salto. A interface dedúcese da busca do seguinte salto en lugar de impoñerse polo comando de ruta.

En macOS a inspección de só lectura é route -n get 198.51.100.25. Lea xuntas as liñas de pasarela e interface e comprobe que a pasarela é un enderezo que o Mac pode alcanzar de verdade. Unha pasarela noutra subrede, ou unha que desapareceu desde o último cambio de rede, produce unha ruta que parece correcta e non reenvía nada.

Non fixe en0 nunha instrución duradeira. Os nomes de interface cambian con adaptadores, docks e clientes VPN, e unha ruta que nomea o incorrecto falla dun xeito fácil de malinterpretar como unha avaría de rede máis ampla.

Lea a elección actual antes de substituíla

Antes de engadir nada, inspeccione que seleccionou xa o sistema e por que. Esa saída dille se o tráfico vai polo túnel, polo router LAN ou a ningures, e dá unha base para comparar despois do cambio. Sen ela, non pode saber se a nova ruta surtiu efecto.

Despois comprobe a familia de enderezos. Unha ruta engadida para IPv4 non fai nada por un destino IPv6, e un servizo que resolve a ambas familias pode parecer intermitentemente alcanzable. A táboa de rutas e o resolvedor responden preguntas distintas, e ambos deben coincidir coa ruta prevista.

Por último, lembre que unha ruta é unha selección, non un permiso. Un perfil de VPN xestionado ou un filtro de cliente aínda poden prohibir a ruta directa aínda que a táboa apunte a ela, así que probe coa aplicación real en lugar de supor que unha entrada correcta na táboa remata a investigación.

Os túneles e a política cambian a forma

As interfaces punto a punto son o seu propio caso. Un túnel pode levar unha ruta sen un enderezo de pasarela ao estilo Ethernet, e iso non é automaticamente incorrecto. Aplique o modelo de ligazón real da interface en lugar de estender un exemplo Wi-Fi a cada entrada da táboa que vexa.

Para solicitudes de cambio, anote o destino, a ruta de rede aprobada, a pasarela e a interface actuais, e quen debe manter a excepción. O propietario importa porque unha ruta puntual escrita no prompt non é unha política, e a próxima reconexión borraraa.

Se o requisito é chegar a este host mentres a VPN está activa, a resposta honesta adoita ser unha ruta de host específica a través do router local, instalada polo xestor de rede que posúe a interface. Se o requisito é chegar a calquera cousa directamente, o requisito mesmo necesita unha revisión de política antes que un comando de ruta.