Varför route -interface inte når en värd utanför länken

route accepterar Wi-Fi-gränssnittets namn, avslutar utan klagomål och värden förblir onåbar. Inget är skadat; förhållandet i rutten är helt enkelt fel: en interface-flagga säger vilken länk ett mål ligger på, inte vilken router som ska ta emot trafik för ett mål som ligger någon annanstans. Kommandot lyckas för att det är syntaktiskt giltigt, inte för att det beskriver en fungerande väg.

Den skillnaden avgör om ett ruteundantag bredvid en VPN kommer att fungera eller bara se rimligt ut.

Gränssnittet är utgången, nästa hopp är överlämningen

På en Mac med adress 192.168.50.20 och en router på 192.168.50.1 kan en annan maskin på samma länk nås direkt. Rammen adresseras till den maskinen och läggs på ledningen. Ingen router är inblandad, och en gränssnittsbunden rutt uttrycker exakt det. Ändra den bortre änden till en värd i en annan byggnad och samma kommando slutar vara meningsfullt. Macen har ingen adress på lager två att lägga på ledningen, så interface-flaggan har inget att beskriva.

Ett mål utanför länken är annorlunda. Macen kan inte lägga en ram på ledningen adresserad till en värd som den inte når på lager två; den lämnar över paketet till en router som kan. Rutten behöver därför en gateway, och gatewayen själv måste vara nåbar på den anslutna länken.

Att använda interface-flaggan för ett mål utanför länken säger till macOS att behandla målet som om det låg på ledningen. Kärnan lyckas då inte slå upp en adress på lager två för det, och paketet släpps utan något användbart i felet.

Vad interface-flaggan faktiskt påstår

Apples ruttereferens definierar gränssnittsformen för mål som är direkt nåbara utan mellanhand. Det är ett påstående om länkmodellen, inte en preferens för vilken adapter som används. Att nå en internetvärd via Wi-Fi kräver fortfarande en router på den Wi-Fi-länken, och rutten måste namnge den.

Gränssnittsomfattning är ett separat attribut. Det kopplar en rutt till ett visst gränssnitt för omfattningsbeslut som vilken källadress som gäller, men det skapar inte nåbarhet för ett mål som gränssnittet inte når själv. De två attributen svarar på olika frågor.

Därför kan ett kommando accepteras, synas i tabellen och ändå misslyckas. Kärnan validerar inte din avsikt; den registrerar vad du påstod, och påståendet var att målet ligger på länken. Tyst framgång följt av tyst kastning är det förväntade resultatet, inte en bugg. Läs påståendet igen för dig själv innan du skyller på nätverket.

Rutten som ett mål utanför länken behöver

För en godkänd väg till en dokumentationsadress som 198.51.100.25 via LAN-routern är det avsedda förhållandet ett mål, ett nästa hopp på 192.168.50.1 och det LAN-gränssnitt som når det nästa hoppet. Gränssnittet antyds av sökningen av nästa hopp i stället för att tvingas fram av ruttkommandot.

På macOS är den skrivskyddade inspektionen route -n get 198.51.100.25. Läs gateway- och gränssnittsraderna tillsammans och kontrollera att gatewayen är en adress som Macen faktiskt kan nå. En gateway i ett annat subnät, eller en som försvunnit sedan den senaste nätverksändringen, ger en rutt som ser korrekt ut och inte vidarebefordrar något.

Hårdkoda inte en0 i en varaktig instruktion. Gränssnittsnamn ändras med adaptrar, dockor och VPN-klienter, och en rutt som namnger den felaktiga misslyckas på ett sätt som lätt misstolkas som ett bredare nätverksfel.

Läs det nuvarande valet innan du ersätter det

Innan du lägger till något, undersök vad systemet redan har valt och varför. Den utskriften säger om trafiken går genom tunneln, genom LAN-routern eller ingenstans, och ger dig en baslinje att jämföra med efter ändringen. Utan den kan du inte avgöra om den nya rutten har fått effekt.

Kontrollera sedan adressfamiljen. En rutt som lagts till för IPv4 gör ingenting för ett IPv6-mål, och en tjänst som löses till båda familjerna kan verka periodvis nåbar. Ruttabellen och resolvern svarar på olika frågor, och båda måste stämma med den avsedda vägen.

Till sist, kom ihåg att en rutt är ett val, inte ett tillstånd. En hanterad VPN-profil eller ett klientfilter kan fortfarande förbjuda den direkta vägen även när tabellen pekar på den, så testa med den faktiska applikationen i stället för att anta att en lyckad tabellpost avslutar utredningen.

Tunnlar och policy ändrar formen

Punkt-till-punkt-gränssnitt är sitt eget fall. En tunnel kan bära en rutt utan en gatewayadress i Ethernet-stil, och det är inte automatiskt fel. Använd gränssnittets verkliga länkmodell i stället för att bredda ett Wi-Fi-exempel till varje tabellpost du ser.

För ändringsärenden, skriv ned målet, den godkända nätverksvägen, nuvarande gateway och gränssnitt samt vem som förväntas underhålla undantaget. Ägaren spelar roll eftersom en engångsrutt skriven vid prompten inte är en policy, och nästa återanslutning kommer att radera den.

Om kravet är att nå den här värden medan VPN:en är uppe, är det ärliga svaret vanligtvis en specifik värdrutt genom den lokala routern, installerad av nätverkshanteraren som äger gränssnittet. Om kravet är att nå vad som helst direkt, behöver kravet självt en policygenomgång innan det behöver ett ruttkommando.