De ce route -interface nu ajunge la un host din afara legăturii

route acceptă numele interfeței Wi-Fi, se încheie fără reclamații, iar hostul rămâne inaccesibil. Nimic nu este corupt; relația din rută este pur și simplu greșită: un indicator de interfață spune pe ce legătură se află o destinație, nu care router trebuie să primească traficul pentru o destinație aflată în altă parte. Comanda reușește pentru că este sintactic validă, nu pentru că descrie o cale funcțională.

Această distincție decide dacă o excepție de rută lângă un VPN va funcționa sau doar va părea plauzibilă.

Interfața este ieșirea, următorul salt este predarea

Pe un Mac cu adresa 192.168.50.20 și un router la 192.168.50.1, o altă mașină din aceeași legătură este accesibilă direct. Cadrul este adresat acelei mașini și pus pe cablu. Niciun router nu este implicat, iar o rută limitată la interfață exprimă exact asta. Schimbați capătul îndepărtat cu un host din altă clădire și aceeași comandă nu mai are sens. Mac-ul nu are o adresă de nivel doi de pus pe cablu, deci indicatorul de interfață nu are ce descrie.

O destinație din afara legăturii este diferită. Mac-ul nu poate pune pe cablu un cadru adresat unui host pe care nu îl atinge la nivelul doi; predă pachetul unui router care poate. Ruta are deci nevoie de o poartă, iar poarta însăși trebuie să fie accesibilă pe legătura conectată.

Folosirea indicatorului de interfață pentru o destinație din afara legăturii îi spune macOS să trateze acea destinație ca și cum ar fi pe cablu. Nucleul nu reușește atunci să rezolve o adresă de nivel doi pentru ea, iar pachetul este aruncat fără nimic util în eroare.

Ce afirmă de fapt indicatorul de interfață

Referința de rute a Apple definește forma cu interfață pentru destinații accesibile direct, fără intermediar. Este o afirmație despre modelul legăturii, nu o preferință privind adaptorul folosit. Atingerea unui host de internet prin Wi-Fi necesită în continuare un router pe acea legătură Wi-Fi, iar ruta trebuie să îl numească.

Domeniul interfeței este un atribut separat. Asociază o rută cu o anumită interfață pentru decizii de domeniu, cum ar fi ce adresă sursă se aplică, dar nu creează accesibilitate pentru o destinație pe care interfața nu o poate atinge singură. Cele două atribute răspund la întrebări diferite.

De aceea o comandă poate fi acceptată, poate apărea în tabel și totuși poate eșua. Nucleul nu validează intenția dumneavoastră; înregistrează ceea ce ați afirmat, iar afirmația a fost că destinația este în legătură. Un succes silențios urmat de o aruncare silențioasă este rezultatul așteptat, nu un defect. Recitiți afirmația înainte de a învinui rețeaua.

Ruta de care are nevoie o destinație din afara legăturii

Pentru o cale aprobată către o adresă de documentație precum 198.51.100.25 prin routerul LAN, relația dorită este o destinație, un următor salt 192.168.50.1 și interfața LAN care atinge acel următor salt. Interfața este implicită din căutarea următorului salt, nu impusă de comanda de rută.

Pe macOS, inspecția doar-citire este route -n get 198.51.100.25. Citiți împreună liniile de poartă și interfață și verificați că poarta este o adresă pe care Mac-ul o atinge efectiv. O poartă într-o altă subrețea, sau una care a dispărut de la ultima schimbare de rețea, produce o rută care pare corectă și nu transmite nimic.

Nu codificați en0 într-o instrucțiune durabilă. Numele interfețelor se schimbă cu adaptoare, dock-uri și clienți VPN, iar o rută care o numește pe cea greșită eșuează într-un mod ușor de interpretat greșit ca o defecțiune de rețea mai largă.

Citiți alegerea actuală înainte de a o înlocui

Înainte de a adăuga ceva, inspectați ce a ales deja sistemul și de ce. Acea ieșire vă spune dacă traficul merge prin tunel, prin routerul LAN sau nicăieri, și vă oferă o bază de comparație după schimbare. Fără ea, nu puteți spune dacă noua rută a avut efect.

Apoi verificați familia de adrese. O rută adăugată pentru IPv4 nu face nimic pentru o destinație IPv6, iar un serviciu care se rezolvă în ambele familii poate părea accesibil intermitent. Tabela de rute și resolverul răspund la întrebări diferite, iar ambele trebuie să fie de acord cu calea dorită.

În final, rețineți că o rută este o selecție, nu o permisiune. Un profil VPN gestionat sau un filtru de client poate interzice în continuare calea directă chiar și când tabela indică spre ea, așa că testați cu aplicația reală în loc să presupuneți că o intrare reușită în tabel încheie investigația.

Tunelurile și politicile schimbă forma

Interfețele punct-la-punct sunt un caz separat. Un tunel poate transporta o rută fără o adresă de poartă în stil Ethernet, iar asta nu este automat greșit. Aplicați modelul real de legătură al interfeței în loc să extindeți un exemplu Wi-Fi la fiecare intrare din tabel pe care o vedeți.

Pentru cererile de modificare, notați destinația, calea de rețea aprobată, poarta și interfața actuale și cine se așteaptă să întrețină excepția. Proprietarul contează pentru că o rută unică tastată la prompt nu este o politică, iar următoarea reconectare o va șterge.

Dacă cerința este să ajungeți la acest host cu VPN-ul activ, răspunsul onest este de obicei o rută de host specifică prin routerul local, instalată de managerul de rețea care deține interfața. Dacă cerința este să ajungeți la orice direct, cerința în sine are nevoie de o revizuire de politică înainte de a avea nevoie de o comandă de rută.