Varige ruter for ein Mac-VPN: networksetup eller ein tilkoplingskrok?

Ei rute som blir skrive inn etter kvar tilkopling, løyser augneblinken og ikkje veka. På macOS er det varige valet vanlegvis eit prefiks som blir lagra med VPN-tenesta, fordi tenesta installerer det på nytt ved kvar tilkopling og fjernar det når tenesta er nede. Alternativa er eit mellombels route add for testing og ein tilkoplingskrok for adresser som først er kjende etter forhandlinga.

Avgjer om ruta høyrer til tenesta eller økta

Spør kva prefikset avheng av. Viss det er eit fast privat nettverk bak ei innebygd VPN-teneste, høyrer ruta til den tenesta. Viss det avheng av ei peer-adresse som endrar seg ved kvar tilkopling, kan ein krok eller ein tilstandsstyrt jobb vere ein betre eigar. Viss du berre sjekkar ein veg for dei neste fem minutta, er ei mellombels rute nok.

Den tenestebundne ruta har den reinaste livssyklusen. Ho viser seg med tenesta og forsvinn når tenesta ikkje er tilkopla, så ho kan ikkje overleve tunnelen ho peikar på. Den eigenskapen er meir verdt enn bekvemmeleiken ved ein einlinjekommando.

Ei øktbunden rute høyrer til grensesnittet, og det nummeret endrar seg utan varsel. Ei attilkopling kan gje tunnelen eit anna utun-namn enn førre økt brukte, noko som gjer ein hardkoda kommando til ei rute som peikar på ingenting eller, verre, på ein annan tunnel.

Les gjeldande rute- og tenestestatus

Byrja med namna systemet faktisk brukar. Tenestenamnet i Nettverksinnstillingar er identifikatoren for kommandoane nedanfor, og gjeldande rutetabell viser kva den tilkopla klienten har installert. Les begge medan tunnelen er oppe.

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

Det oppslaget viser kva gateway og grensesnitt kjernen ville velje for denne adressa akkurat no. Viss han alt vel tunnelen, er prefikset dekt, og ei ny rute ville vere overflødig. Viss han vel den lokale rutaren, manglar tunnelen det prefikset.

Noter peer-adressa medan du er tilkopla. Ho blir gateway-verdien i den tenestebundne ruta, og ho er vanlegvis destinasjonen som blir vist for standardruta til tunnelen i netstat -rn.

Lagre prefikset med networksetup

Verktøyet networksetup knyter ekstra ruter til ei nettverksteneste. For ei teneste som heiter OfficeVPN og eit privat prefiks som ein når gjennom peeren til tunnelen, er forma:

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

Kvar trippel etter tenestenamnet gjev ein destinasjon, nettmaska og peeren til tunnelen som gateway. Eitt kall kan bere fleire prefiks, og eit tomt kall tømmer den lagra lista. Lesaren er verifiseringstrinnet; viss lista er tom, vart settet ikkje brukt på tenesta du trur.

Gatewayen må vere peeren til tunnelen, ikkje den fysiske rutaren. Ei rute som nemner den lokale gatewayen, sender det private prefikset ut gjennom det fysiske grensesnittet, som er den opphavlege feilen med ekstra steg. Ein utdatert peer er den vanlegaste grunnen til at ei riktig utsjåande rute aldri ber trafikk. Les peeren på nytt frå den tilkopla tilstanden i staden for å kopiere ei adresse frå eit gammalt notat.

Bruk route add berre til ein test

Ei direkte rute er nyttig for å bevise at eit prefiks verkar før du gjer det permanent. Grensesnittforma unngår eit gateway-oppslag:

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

Ruta forsvinn ved neste attilkopling og avheng av grensesnittnummeret som finst i dag. Det gjer ho til ein diagnose, ikkje ein utrulling. Viss testen verkar og den tenestebundne ruta ikkje, samanlikn gateway-verdien først; det er feltet som oftast er feil.

Ver varsam med råd som erstattar standardruta til VPN-en for å tvinge deling. Ein klient som handhevar ein full tunnel, kan installere rutene sine på nytt etter ei attilkopling eller ei policyoppdatering, så den manuelle endringa blir stille angra. Nokre få private prefiks er eit ruteproblem; å halde all internettrafikk lokal mot ein fulltunnelpolicy er eit vedtak på serversida.

Vel ein krok berre når adressa blir forhandla

For PPP-baserte lenkjer som L2TP, køyrer macOS /etc/ppp/ip-up når lenkja er etablert. Skriptet får grensesnittnamnet og dei forhandla lokale og eksterne adressene, så det kan leggje til ei rute som avheng av peeren serveren tildelte. Det er nettopp tilfellet ei fast tenesterute ikkje kan uttrykkje.

IKEv2 og leverandørklientar brukar kanskje ikkje den PPP-vegen i det heile, noko som betyr at skriptet kan vere stille heile økta. Når det skjer, er ein launchd-jobb som spør scutil --nc status og handlar på ei tilstandsendring, den tilsvarande mekanismen, med ei lita forseinking.

Uansett kva krok du brukar, gjer han idempotent og la han berre fjerne ruter han sjølv oppretta. Eit skript som slettar kvar rute som nemner tunnelen, vil til slutt slette ruta som held VPN-serveren tilgjengeleg, og tilkoplinga fell så snart det lykkast.

Avslutt med å sjekke den private destinasjonen, vanleg surfing og ein attilkoplings- eller svevnssyklus. Gransk deretter scutil --dns, fordi namneoppslag er ein eigen policy, og ei fungerande rute beviser ikkje at dei private namna blir løyste.