Kontroll av VPN-rutt på macOS: route get utan att ändra något

En användare når intranätet på kontorsnätet och inte genom tunneln, medan Inställningar fortfarande visar VPN som ansluten. Att redigera rutttabellen i det ögonblicket riskerar att kapa fjärrsessionen du använder för att diagnostisera. Fråga i stället kärnan vilken väg den skulle välja för värden som misslyckas. macOS-verktyget route har en get-operation som svarar exakt på det, för en destination, utan att ändra någonting.

Fråga värden som misslyckas, inte standardrutten

En skärmbild av standardrutten säger väldigt lite på en modern Mac, eftersom en mer specifik destination eller en begränsad policy kan åsidosätta det standardrutten ser ut att säga. Tunneln kan vara uppe, standardrutten kan se korrekt ut, och den enda värd du behöver kan ändå routas någon annanstans. Fråga adressen som misslyckas och låt kärnan namnge den väg den valde.

Formen är route -n get följt av adressen: route -n get 203.0.113.10, där dokumentationsadressen står för ditt mål. Använd den auktoriserade destinationen och motsvarande adressfamilj, eftersom ett IPv4-svar inte säger något om en resurs som bara är IPv6. Dokumentationen för route-verktyget beskriver get-operationen och fälten den skriver ut.

Läs gränssnittet och gatewayen som bevis

Kör frågan innan du ansluter VPN:en och sedan igen efteråt, och jämför raderna för gränssnitt och gateway. Skillnaden mellan de två svaren är det tunneln faktiskt ändrade, och den är mycket mer användbar än en full tabellutskrift. Om gränssnittet är identiskt i båda körningarna var rutten aldrig problemet, och du kan sluta titta på routing.

Anteckna destinationen, gränssnittet, gatewayen och tiden för frågan innan du drar en slutsats. Utdata är bevis, inte en diagnos: samma gränssnitt kan vara korrekt för en värd och fel för en annan när en delad tunnel är inblandad.

En korrekt rutt är inte en fungerande begäran

En rutt talar om vilket gränssnitt kärnan skulle använda, inget mer. DNS, en värdbrandvägg och applikationsauktorisering står alla över det beslutet, och begäran kan misslyckas efter att routingen lyckats. Bevara det exakta symptomet innan du går vidare, eftersom "kan inte ansluta" och "ansluter men returnerar ett fel" är olika utredningar med olika nästa steg. Resolver-vyn och gränssnittsvyn kompletterar destinationsfrågan i stället för att ersätta den.

En utskrift av rutttabellen har fortfarande sin plats: det är så du upptäcker en oväntad standardrutt. En kvarvarande vanlig standardrutt bevisar inte att VPN:en är oanvänd, eftersom mer specifika poster vinner över den.

Håll isär slutpunkten och resursen

Två uppslagningar är inblandade och de svarar på olika frågor. Att nå slutpunkten är en yttre resa genom det fysiska nätet. Att nå applikationen sker inne i tunneln, på en adress som bara finns på den privata sidan. Att blanda ihop de två skapar den klassiska falska slingan, där slutpunkten verkar routas genom tunneln den avslutar. Fråga de två adresserna var för sig, märk varje resultat, och förvirringen försvinner.

Prefix-överlappning är det andra fallet som är värt att känna till. När lokala och avlägsna intervall överlappar avgör den längsta prefixmatchningen, så ett överlappande lokalt subnät kan skugga den avlägsna adress du förväntade dig. Den privata destinationen ser då identisk ut med en lokal, och rättelsen hör hemma i adressplanen och inte i rutttabellen. get-frågan visar vilket gränssnitt som vann, och det är det faktum du behöver innan du ändrar något.

Läs först, ändra senare

Håll route add och route delete utanför den första omgången. På en Mac du administrerar på distans kan en enda oaktsam tabelländring ta bort just vägen tillbaka till maskinen, och ingen blir kvar som kan slutföra diagnosen. Bestäm vilken rutt som är korrekt, skriv ned hur ändringen ångras, och kör den först då. En inspektion har ingen sådan svans.

Samma försiktighet gäller för att tömma cachar och starta om nätverkstjänster som första drag, eftersom båda förstör beviset du var på väg att läsa. Skrivskyddade kontroller är billiga, repeterbara och säkra i vilken ordning som helst. Gör dem till standardsteget, och grip bara efter en ändring när beviset pekar på en.