Hvorfor route -interface ikke kan nå en vært uden for linket

route accepterer Wi-Fi-interface-navnet, afslutter uden klage, og værten forbliver uopnåelig. Intet er beskadiget; forholdet i ruten er simpelthen forkert: et interface-flag siger, hvilket link en destination ligger på, ikke hvilken router der skal modtage trafik for en destination et andet sted. Kommandoen lykkes, fordi den er syntaktisk gyldig, ikke fordi den beskriver en fungerende vej.

Den forskel afgør, om en ruteundtagelse ved siden af en VPN vil virke eller blot se plausibel ud.

Interfacet er udgangen, næste hop er overdragelsen

På en Mac med adresse 192.168.50.20 og en router på 192.168.50.1 kan en anden maskine på samme link nås direkte. Frames adresseres til den maskine og lægges på ledningen. Ingen router er involveret, og en interface-begrænset rute udtrykker præcis det. Skift den fjerne ende til en vært i en anden bygning, og den samme kommando holder op med at give mening. Mac'en har ingen adresse på lag to at lægge på ledningen, så der er intet for interface-flaget at beskrive.

En destination uden for linket er anderledes. Mac'en kan ikke lægge en frame på ledningen adresseret til en vært, den ikke kan nå på lag to; den overdrager pakken til en router, der kan. Ruten kræver derfor en gateway, og gatewayen selv skal være tilgængelig på det tilsluttede link.

At bruge interface-flaget til en destination uden for linket fortæller macOS at behandle destinationen, som om den var på ledningen. Kernen formår derefter ikke at opløse en adresse på lag to til den, og pakken kasseres uden noget nyttigt i fejlen.

Hvad interface-flaget faktisk hævder

Apples rutereference definerer interface-formen til destinationer, der kan nås direkte uden en mellemled. Det er en udtalelse om linkmodellen, ikke en præference for, hvilken adapter der skal bruges. At nå en internetvært via Wi-Fi kræver stadig en router på det Wi-Fi-link, og ruten skal navngive den.

Interface-område er et separat attribut. Det knytter en rute til et bestemt interface til omfangsbeslutninger som hvilken kildeadresse der gælder, men det skaber ikke tilgængelighed for en destination, som interfacet ikke selv kan nå. De to attributter besvarer forskellige spørgsmål.

Det er derfor, en kommando kan blive accepteret, optræde i tabellen og alligevel fejle. Kernen validerer ikke din hensigt; den registrerer, hvad du hævdede, og hævdelsen var, at destinationen ligger på linket. Stille succes efterfulgt af stille kassering er det forventede resultat, ikke en fejl. Læs hævdelsen igennem for dig selv, før du bebrejder netværket.

Den rute en destination uden for linket har brug for

For en godkendt vej til en dokumentationsadresse som 198.51.100.25 gennem LAN-routeren er det tilsigtede forhold en destination, et næste hop på 192.168.50.1 og det LAN-interface, der når dette næste hop. Interfacet følger af opslaget af næste hop i stedet for at blive tvunget af rute-kommandoen.

På macOS er den skrivebeskyttede inspektion route -n get 198.51.100.25. Læs gateway- og interface-linjerne sammen, og kontroller, at gatewayen er en adresse, Mac'en faktisk kan nå. En gateway på et andet subnet, eller en der er forsvundet siden den sidste netværksændring, giver en rute, der ser korrekt ud og ikke videresender noget.

Hardkod ikke en0 i en varig instruktion. Interface-navne ændrer sig med adaptere, docks og VPN-klienter, og en rute, der navngiver den forkerte, fejler på en måde, der let mistolkes som en bredere netværksfejl.

Læs det nuværende valg, før du erstatter det

Før du tilføjer noget, skal du undersøge, hvad systemet allerede har valgt, og hvorfor. Det output fortæller dig, om trafikken går gennem tunnelen, gennem LAN-routeren eller ingen steder, og det giver en baseline at sammenligne med efter ændringen. Uden det kan du ikke afgøre, om den nye rute har haft effekt.

Kontroller derefter adressefamilien. En rute tilføjet til IPv4 gør intet for en IPv6-destination, og en tjeneste, der opløses til begge familier, kan virke periodisk tilgængelig. Rutetabellen og resolveren besvarer forskellige spørgsmål, og begge skal stemme overens med den tilsigtede vej.

Husk til sidst, at en rute er et valg, ikke en tilladelse. En administreret VPN-profil eller et klientfilter kan stadig forbyde den direkte vej, selv når tabellen peger på den, så test med den faktiske applikation i stedet for at antage, at en vellykket tabelpost afslutter undersøgelsen.

Tunneler og politik ændrer formen

Punkt-til-punkt-interfaces er deres egen sag. En tunnel kan bære en rute uden en gatewayadresse i Ethernet-stil, og det er ikke automatisk forkert. Anvend interfacets virkelige linkmodel i stedet for at udvide et Wi-Fi-eksempel til enhver tabelpost, du ser.

Til ændringsanmodninger skal du skrive destinationen, den godkendte netværksvej, den nuværende gateway og interface samt, hvem der forventes at vedligeholde undtagelsen. Ejeren betyder noget, fordi en engangsrute skrevet ved prompten ikke er en politik, og den næste genopkobling vil slette den.

Hvis kravet er at nå denne vært, mens VPN'en er oppe, er det ærlige svar normalt en specifik værtsrute gennem den lokale router, installeret af den netværksadministrator, der ejer interfacet. Hvis kravet er at nå alt direkte, har kravet selv brug for en politikgennemgang, før det har brug for en rute-kommando.