Hvorfor route -interface ikke når en vert utenfor lenken

route godtar Wi-Fi-interface-navnet, avslutter uten klage, og verten forblir uoppnåelig. Ingenting er skadet; forholdet i ruten er rett og slett feil: et interface-flagg sier hvilken lenke en destinasjon ligger på, ikke hvilken ruter som skal motta trafikk for en destinasjon som ligger et annet sted. Kommandoen lykkes fordi den er syntaktisk gyldig, ikke fordi den beskriver en fungerende vei.

Den forskjellen avgjør om et ruteunntak ved siden av en VPN vil virke eller bare se plausibelt ut.

Interface er utgangen, neste hopp er overleveringen

På en Mac med adresse 192.168.50.20 og en ruter på 192.168.50.1 kan en annen maskin på samme lenke nås direkte. Rammen adresseres til den maskinen og legges på ledningen. Ingen ruter er involvert, og en interface-begrenset rute uttrykker nettopp det. Endre den fjerne enden til en vert i en annen bygning, og samme kommando slutter å gi mening. Macen har ingen adresse på lag to å legge på ledningen, så interface-flagget har ingenting å beskrive.

En destinasjon utenfor lenken er annerledes. Macen kan ikke legge en ramme på ledningen adressert til en vert den ikke når på lag to; den overleverer pakken til en ruter som kan. Ruten trenger derfor en gateway, og gatewayen selv må være tilgjengelig på den tilkoblede lenken.

Å bruke interface-flagget for en destinasjon utenfor lenken forteller macOS å behandle destinasjonen som om den var på ledningen. Kjernen klarer da ikke å slå opp en adresse på lag to for den, og pakken forkastes uten noe nyttig i feilen.

Hva interface-flagget faktisk hevder

Apples ruter-referanse definerer interface-formen for destinasjoner som er direkte tilgjengelige uten en mellommann. Det er en uttalelse om lenkemodellen, ikke en preferanse for hvilken adapter som brukes. Å nå en internettvert via Wi-Fi krever fortsatt en ruter på den Wi-Fi-lenken, og ruten må navngi den.

Interface-omfang er et eget attributt. Det knytter en rute til et bestemt interface for omfangsbeslutninger som hvilken kildeadresse som gjelder, men det skaper ikke tilgjengelighet for en destinasjon som interfacet ikke når selv. De to attributtene svarer på forskjellige spørsmål.

Derfor kan en kommando godtas, vises i tabellen og likevel mislykkes. Kjernen validerer ikke hensikten din; den registrerer det du hevdet, og hevdelsen var at destinasjonen ligger på lenken. Stille suksess etterfulgt av stille forkastelse er det forventede resultatet, ikke en feil. Les hevdelsen på nytt for deg selv før du klandrer nettverket.

Ruten en destinasjon utenfor lenken trenger

For en godkjent vei til en dokumentasjonsadresse som 198.51.100.25 via LAN-ruteren er det tiltenkte forholdet en destinasjon, et neste hopp på 192.168.50.1 og LAN-interfacet som når det neste hoppet. Interfacet antydes av oppslaget av neste hopp i stedet for å tvinges av rute-kommandoen.

På macOS er den skrivebeskyttede inspeksjonen route -n get 198.51.100.25. Les gateway- og interface-linjene sammen og kontroller at gatewayen er en adresse Macen faktisk kan nå. En gateway på et annet subnett, eller en som er borte siden den siste nettverksendringen, gir en rute som ser riktig ut og ikke videresender noe.

Ikke hardkod en0 i en varig instruksjon. Interface-navn endres med adaptere, dokker og VPN-klienter, og en rute som navngir den gale feiler på en måte som lett mistolkes som en bredere nettverksfeil.

Les det gjeldende valget før du erstatter det

Før du legger til noe, undersøk hva systemet allerede har valgt og hvorfor. Det outputet forteller deg om trafikken går gjennom tunnelen, gjennom LAN-ruteren eller ingen steder, og gir deg en baseline å sammenligne med etter endringen. Uten det kan du ikke avgjøre om den nye ruten har hatt effekt.

Sjekk deretter adressefamilien. En rute lagt til for IPv4 gjør ingenting for en IPv6-destinasjon, og en tjeneste som løses til begge familier kan virke periodevis tilgjengelig. Rutetabellen og resolveren svarer på forskjellige spørsmål, og begge må stemme med den tiltenkte veien.

Til slutt, husk at en rute er et valg, ikke en tillatelse. En administrert VPN-profil eller et klientfilter kan fortsatt forby den direkte veien selv når tabellen peker på den, så test med den faktiske applikasjonen i stedet for å anta at en vellykket tabelloppføring avslutter undersøkelsen.

Tunneler og policy endrer formen

Punkt-til-punkt-interfaces er sin egen sak. En tunnel kan bære en rute uten en gatewayadresse i Ethernet-stil, og det er ikke automatisk feil. Bruk interfacets virkelige lenkemodell i stedet for å utvide et Wi-Fi-eksempel til hver tabelloppføring du ser.

For endringsforespørsler, skriv ned destinasjonen, den godkjente nettverksveien, gjeldende gateway og interface, og hvem som forventes å vedlikeholde unntaket. Eieren betyr noe fordi en engangsrute skrevet ved ledeteksten ikke er en policy, og neste gjentilkobling vil slette den.

Hvis kravet er å nå denne verten mens VPN-en er oppe, er det ærlige svaret vanligvis en spesifikk vertsrute gjennom den lokale ruteren, installert av nettverksbehandleren som eier interfacet. Hvis kravet er å nå alt direkte, trenger kravet selv en policygjennomgang før det trenger en rute-kommando.