Sjekk av VPN-rute på macOS: route get uten å endre noe
Et skjermbilde av standardruten kan overse en mer spesifikk vei. Spør den feilende destinasjonen med route get, les grensesnittet og gatewayen, og ikke endre noe.
En bruker når intranettet på kontornettet og ikke gjennom tunnelen, mens Innstillinger fortsatt viser VPN-en som tilkoblet. Å redigere rutetabellen i det øyeblikket risikerer å kutte fjernøkten du bruker til å diagnostisere. Spør kjernen i stedet om hvilken vei den ville velge for verten som feiler. macOS-verktøyet route har en get-operasjon som svarer nøyaktig på det, for én destinasjon, uten å endre noe.
Spør verten som feiler, ikke standardruten
Et skjermbilde av standardruten sier svært lite på en moderne Mac, fordi en mer spesifikk destinasjon eller en begrenset policy kan overstyre det standardruten ser ut til å si. Tunnelen kan være oppe, standardruten kan se riktig ut, og den ene verten du trenger kan likevel bli rutet et annet sted. Spør adressen som feiler, og la kjernen navngi veien den valgte.
Formen er route -n get etterfulgt av adressen: route -n get 203.0.113.10, der dokumentasjonsadressen står for målet ditt. Bruk den autoriserte destinasjonen og den samsvarende adressefamilien, fordi et IPv4-svar ikke sier noe om en ressurs som bare er IPv6. Dokumentasjonen for route-verktøyet beskriver get-operasjonen og feltene den skriver ut.
Les grensesnittet og gatewayen som bevis
Kjør spørringen før du kobler til VPN-en, og deretter igjen etterpå, og sammenlign linjene for grensesnitt og gateway. Forskjellen mellom de to svarene er det tunnelen faktisk endret, og den er langt mer nyttig enn en full tabellutskrift. Hvis grensesnittet er identisk i begge kjøringene, var ruten aldri problemet, og du kan slutte å se på ruting.
Noter destinasjonen, grensesnittet, gatewayen og tidspunktet for spørringen før du trekker en konklusjon. Utdataene er bevis, ikke en diagnose: det samme grensesnittet kan være riktig for én vert og feil for en annen når en delt tunnel er involvert.
En riktig rute er ikke en forespørsel som virker
En rute forteller deg hvilket grensesnitt kjernen ville bruke, ikke mer. DNS, en vertsbrannmur og applikasjonsautorisasjon ligger alle over den beslutningen, og forespørselen kan feile etter at rutingen lykkes. Bevar det nøyaktige symptomet før du går videre, fordi "kan ikke koble til" og "kobler til, men returnerer en feil" er ulike undersøkelser med ulike neste steg. Resolver-visningen og grensesnitt-visningen utfyller destinasjonsspørringen i stedet for å erstatte den.
En utskrift av rutetabellen har fortsatt sin plass: det er slik du legger merke til en uventet standardrute. En gjenværende vanlig standardrute beviser ikke at VPN-en er ubrukt, fordi mer spesifikke oppføringer vinner over den.
Hold endepunktet og ressursen fra hverandre
To oppslag er involvert, og de svarer på ulike spørsmål. Å nå endepunktet er en ytre reise gjennom det fysiske nettet. Å nå applikasjonen skjer inne i tunnelen, på en adresse som bare finnes på den private siden. Å blande de to gir den klassiske falske løkken, der endepunktet ser ut til å rute gjennom tunnelen det avslutter. Spør de to adressene hver for seg, merk hvert resultat, og forvirringen forsvinner.
Prefiks-overlapp er det andre tilfellet det er verdt å kjenne. Når lokale og eksterne områder overlapper, avgjør den lengste prefiksen, så et overlappende lokalt subnett kan skygge for den eksterne adressen du forventet. Den private destinasjonen ser da identisk ut med en lokal, og rettelsen hører hjemme i adresseplanen og ikke i rutetabellen. get-spørringen viser hvilket grensesnitt som vant, og det er det faktum du trenger før du endrer noe.
Les først, endre senere
Hold route add og route delete utenfor den første runden. På en Mac du administrerer eksternt, kan én uforsiktig tabellendring ta bort nettopp veien tilbake til maskinen, og ingen blir igjen til å fullføre diagnosen. Bestem hvilken rute som er riktig, skriv ned hvordan endringen angres, og kjør den først da. En inspeksjon har ingen slik hale.
Samme forsiktighet gjelder for å tømme hurtigbuffere og starte nettverkstjenester på nytt som første trekk, fordi begge ødelegger beviset du var i ferd med å lese. Skrivebeskyttede kontroller er billige, repeterbare og trygge i hvilken som helst rekkefølge. Gjør dem til standardsteget, og grip bare etter en endring når beviset peker på en.