Vedvarende ruter for en Mac-VPN: networksetup eller en tilkoblingskrok?

En rute som skrives inn etter hver tilkobling, løser øyeblikket og ikke uken. På macOS er det varige valget vanligvis et prefiks som lagres med VPN-tjenesten, fordi tjenesten installerer det på nytt ved hver tilkobling og fjerner det når tjenesten er nede. Alternativene er en midlertidig route add for testing og en tilkoblingskrok for adresser som først er kjent etter forhandlingen.

Bestem om ruten hører til tjenesten eller økten

Spør hva prefikset avhenger av. Hvis det er et fast privat nettverk bak en innebygd VPN-tjeneste, hører ruten til den tjenesten. Hvis det avhenger av en peer-adresse som endres ved hver tilkobling, kan en krok eller en tilstandsstyrt jobb være en bedre eier. Hvis du bare sjekker en vei for de neste fem minuttene, er en midlertidig rute nok.

Den tjenestebundne ruten har den reneste livssyklusen. Den vises med tjenesten og forsvinner når tjenesten ikke er tilkoblet, så den kan ikke overleve tunnelen den peker på. Den egenskapen er mer verdt enn bekvemmeligheten ved en enkelt kommando.

En øktbundet rute hører til grensesnittet, og det nummeret endres uten varsel. En gjentilkobling kan gi tunnelen et annet utun-navn enn forrige økt brukte, noe som gjør en hardkodet kommando til en rute som peker på ingenting eller, verre, på en annen tunnel.

Les gjeldende rute- og tjenestestatus

Begynn med navnene systemet faktisk bruker. Tjenestenavnet i Nettverksinnstillinger er identifikatoren for kommandoene nedenfor, og gjeldende rutetabell viser hva den tilkoblede klienten har installert. Les begge mens tunnelen er oppe.

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

Det oppslaget viser hvilken gateway og grensesnitt kjernen ville velge for denne adressen akkurat nå. Hvis den allerede velger tunnelen, er prefikset dekket, og en ny rute ville være overflødig. Hvis den velger den lokale ruteren, mangler tunnelen det prefikset.

Noter peer-adressen mens du er tilkoblet. Den blir gateway-verdien i den tjenestebundne ruten, og den er vanligvis destinasjonen som vises for tunnelens standardrute i netstat -rn.

Lagre prefikset med networksetup

Verktøyet networksetup knytter ekstra ruter til en nettverkstjeneste. For en tjeneste som heter OfficeVPN og et privat prefiks som nås gjennom tunnelens peer, er formen:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

Hver trippel etter tjenestenavnet gir en destinasjon, nettmasken og tunnelens peer som gateway. Ett kall kan bære flere prefikser, og et tomt kall tømmer den lagrede listen. Leseren er verifiseringstrinnet; hvis listen er tom, ble settet ikke brukt på tjenesten du tror.

Gatewayen må være tunnelens peer, ikke den fysiske ruteren. En rute som navngir den lokale gatewayen, sender det private prefikset ut gjennom det fysiske grensesnittet, som er den opprinnelige feilen med ekstra trinn. En utdatert peer er den vanligste grunnen til at en riktig utseende rute aldri bærer trafikk. Les peeren på nytt fra den tilkoblede tilstanden i stedet for å kopiere en adresse fra et gammelt notat.

Bruk route add bare til en test

En direkte rute er nyttig for å bevise at et prefiks virker før du gjør det permanent. Grensesnittformen unngår et gateway-oppslag:

sudo route -n add -net 10.20.0.0/16 -interface utun4

Ruten forsvinner ved neste gjentilkobling og avhenger av grensesnittnummeret som finnes i dag. Det gjør den til en diagnose, ikke en utrulling. Hvis testen virker og den tjenestebundne ruten ikke, sammenlign gateway-verdien først; det er feltet som oftest er feil.

Vær forsiktig med råd som erstatter VPN-ens standardrute for å tvinge deling. En klient som håndhever en full tunnel, kan installere rutene sine på nytt etter en gjentilkobling eller en policyoppdatering, så den manuelle endringen blir stille angret. Noen få private prefikser er et ruteproblem; å holde all internettrafikk lokal mot en fulltunnelpolicy er en beslutning på serversiden.

Velg en krok bare når adressen forhandles

For PPP-baserte lenker som L2TP, kjører macOS /etc/ppp/ip-up når lenken er etablert. Skriptet mottar grensesnittnavnet og de forhandlede lokale og eksterne adressene, så det kan legge til en rute som avhenger av peeren serveren tildelte. Det er nettopp tilfellet en fast tjenesterute ikke kan uttrykke.

IKEv2 og leverandørklienter bruker kanskje ikke den PPP-veien i det hele tatt, noe som betyr at skriptet kan være stille hele økten. Når det skjer, er en launchd-jobb som spør scutil --nc status og handler på en tilstandsending, den tilsvarende mekanismen, med en liten forsinkelse.

Uansett hvilken krok du bruker, gjør den idempotent og la den bare fjerne ruter den selv opprettet. Et skript som sletter hver rute som nevner tunnelen, vil til slutt slette ruten som holder VPN-serveren tilgjengelig, og tilkoblingen faller så snart det lykkes.

Avslutt med å sjekke den private destinasjonen, vanlig surfing og en gjentilkoblings- eller søvnssyklus. Undersøk deretter scutil --dns, fordi navneoppslag er en egen policy, og en fungerende rute beviser ikke at de private navnene løses.