Per què route -interface no pot arribar a un amfitrió fora de l'enllaç

route accepta el nom de la interfície Wi-Fi, surt sense queixes i l’amfitrió continua inabastable. No hi ha res corrupte; la relació a la ruta simplement és incorrecta: un indicador d’interfície diu en quin enllaç es troba una destinació, no quin encaminador ha de rebre el trànsit per a una destinació que és en un altre lloc. L’ordre té èxit perquè és sintàcticament vàlida, no perquè descrigui un camí que funcioni.

Aquesta distinció decideix si una excepció de ruta al costat d’una VPN funcionarà o només semblarà plausible.

La interfície és la sortida, el següent salt és el lliurament

En un Mac amb adreça 192.168.50.20 i un encaminador a 192.168.50.1, una altra màquina del mateix enllaç és abastable directament. La trama s’adreça a aquesta màquina i es posa al cable. No hi intervé cap encaminador, i una ruta limitada a la interfície expressa exactament això. Canvieu l’extrem llunyà per un amfitrió en un altre edifici i la mateixa ordre deixa de tenir sentit. El Mac no té cap adreça de segona capa per posar al cable, així que l’indicador d’interfície no té res a descriure.

Una destinació fora de l’enllaç és diferent. El Mac no pot posar al cable una trama adreçada a un amfitrió que no pot abastar a la segona capa; lliura el paquet a un encaminador que sí que pot. La ruta, doncs, necessita una porta d’enllaç, i la porta mateixa ha de ser abastable a l’enllaç connectat.

Fer servir l’indicador d’interfície per a una destinació fora de l’enllaç diu a macOS que tracti aquesta destinació com si fos al cable. Llavors el nucli no aconsegueix resoldre una adreça de segona capa per a ella, i el paquet es descarta sense res útil a l’error.

Què afirma realment l’indicador d’interfície

La referència de rutes d’Apple defineix la forma d’interfície per a destinacions directament abastables sense intermediari. És una afirmació sobre el model d’enllaç, no una preferència sobre quin adaptador fer servir. Arribar a un amfitrió d’internet per Wi-Fi encara requereix un encaminador en aquest enllaç Wi-Fi, i la ruta l’ha de nomenar.

L’abast d’interfície és un atribut separat. Associa una ruta amb una interfície concreta per a decisions d’abast com quina adreça d’origen s’aplica, però no crea abastabilitat per a una destinació que la interfície no pot abastar per si sola. Els dos atributs responen preguntes diferents.

Per això una ordre pot ser acceptada, aparèixer a la taula i tot i així fallar. El nucli no valida la vostra intenció; registra què heu afirmat, i l’afirmació era que la destinació és a l’enllaç. Un èxit silenciós seguit d’un descart silenciós és el resultat esperat, no un error. Rellegiu l’afirmació abans de culpar la xarxa.

La ruta que necessita una destinació fora de l’enllaç

Per a un camí aprovat cap a una adreça de documentació com 198.51.100.25 a través de l’encaminador LAN, la relació prevista és una destinació, un següent salt de 192.168.50.1 i la interfície LAN que arriba a aquest següent salt. La interfície se suposa per la consulta del següent salt en lloc de ser forçada per l’ordre de ruta.

A macOS la inspecció només de lectura és route -n get 198.51.100.25. Llegiu les línies de porta d’enllaç i d’interfície juntes i comproveu que la porta és una adreça que el Mac pot abastar realment. Una porta en una altra subxarxa, o una que ha desaparegut des de l’últim canvi de xarxa, produeix una ruta que sembla correcta i no reenvia res.

No fixeu en0 en una instrucció duradora. Els noms d’interfície canvien amb adaptadors, docks i clients VPN, i una ruta que nomena el incorrecte falla d’una manera fàcil de malinterpretar com una avaria de xarxa més àmplia.

Llegiu l’elecció actual abans de substituir-la

Abans d’afegir res, inspeccioneu què ha seleccionat ja el sistema i per què. Aquesta sortida us diu si el trànsit passa pel túnel, per l’encaminador LAN o per enlloc, i us dona una base per comparar després del canvi. Sense això, no podeu saber si la ruta nova ha tingut efecte.

Després comproveu la família d’adreces. Una ruta afegida per a IPv4 no fa res per a una destinació IPv6, i un servei que es resol a les dues famílies pot semblar intermitentment abastable. La taula de rutes i el resolutor responen preguntes diferents, i tots dos han de coincidir amb el camí previst.

Finalment, recordeu que una ruta és una selecció, no un permís. Un perfil de VPN gestionat o un filtre de client encara pot prohibir el camí directe encara que la taula hi apunti, així que proveu amb l’aplicació real en lloc de suposar que una entrada correcta a la taula acaba la investigació.

Els túnels i la política canvien la forma

Les interfícies punt a punt són el seu propi cas. Un túnel pot portar una ruta sense una adreça de porta d’enllaç a l’estil Ethernet, i això no és automàticament incorrecte. Apliqueu el model d’enllaç real de la interfície en lloc d’estendre un exemple Wi-Fi a cada entrada de la taula que veieu.

Per a sol·licituds de canvi, anoteu la destinació, el camí de xarxa aprovat, la porta d’enllaç i la interfície actuals, i qui s’espera que mantingui l’excepció. El propietari importa perquè una ruta puntual escrita al prompt no és una política, i la propera reconnexió l’esborrarà.

Si el requisit és arribar a aquest amfitrió mentre la VPN és activa, la resposta honesta sol ser una ruta d’amfitrió específica a través de l’encaminador local, instal·lada pel gestor de xarxa que posseeix la interfície. Si el requisit és arribar a qualsevol cosa directament, el requisit mateix necessita una revisió de política abans que una ordre de ruta.