Vedvarende ruter til en Mac-VPN: networksetup eller et tilslutningshook?

En rute, der skrives efter hver forbindelse, løser øjeblikket og ikke ugen. På macOS er det varige valg normalt et præfiks, der gemmes sammen med VPN-tjenesten, fordi tjenesten geninstallerer det ved hver forbindelse og fjerner det, når tjenesten er nede. Alternativerne er en midlertidig route add til test og et tilslutningshook til adresser, der først kendes efter forhandling.

Beslut, om ruten hører til tjenesten eller sessionen

Spørg, hvad præfikset afhænger af. Hvis det er et fast privat netværk bag en indbygget VPN-tjeneste, hører ruten til den tjeneste. Hvis det afhænger af en peer-adresse, der ændres ved hver forbindelse, kan et hook eller et tilstandsdrevet job være den bedre ejer. Hvis du kun tjekker en vej de næste fem minutter, er en midlertidig rute nok.

Den tjenestebundne rute har den reneste livscyklus. Den vises med tjenesten og forsvinder, når tjenesten ikke er forbundet, så den kan ikke overleve den tunnel, den peger på. Den egenskab er mere værd end bekvemmeligheden ved en enkelt kommando.

En sessionsbundet rute hører til grænsefladen, og det nummer ændrer sig uden varsel. En genopkobling kan give tunnelen et andet utun-navn end den forrige session brugte, hvilket gør en hårdkodet kommando til en rute, der peger på intet eller, værre, på en anden tunnel.

Læs den aktuelle rute- og tjenestetilstand

Begynd med de navne, systemet faktisk bruger. Tjenestenavnet i Netværksindstillinger er identifikatoren for kommandoerne nedenfor, og den aktuelle rutetabel viser, hvad den forbundne klient har installeret. Læs begge, mens tunnelen er oppe.

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

Det opslag viser, hvilken gateway og grænseflade kernen ville vælge til denne adresse i dette øjeblik. Hvis den allerede vælger tunnelen, er præfikset dækket, og en ny rute ville være overflødig. Hvis den vælger den lokale router, mangler tunnelen det præfiks.

Noter peer-adressen, mens du er forbundet. Den bliver gatewayværdien i den tjenestebundne rute, og den er normalt den destination, der vises for tunnelens standardrute i netstat -rn.

Gem præfikset med networksetup

Værktøjet networksetup knytter ekstra ruter til en netværkstjeneste. For en tjeneste ved navn OfficeVPN og et privat præfiks, der nås gennem 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 efter tjenestenavnet giver en destination, dens netmaske og tunnelens peer som gateway. Et kald kan bære flere præfikser, og et tomt kald rydder den gemte liste. Læseren er verifikationstrinnet; hvis listen er tom, blev sættet ikke anvendt på den tjeneste, du tror.

Gatewayen skal være tunnelens peer, ikke den fysiske router. En rute, der angiver den lokale gateway, sender det private præfiks ud gennem den fysiske grænseflade, hvilket er den oprindelige fejl med ekstra trin. En forældet peer er den mest almindelige grund til, at en korrekt udseende rute aldrig bærer trafik. Læs peer-adressen igen fra den forbundne tilstand i stedet for at kopiere en adresse fra en gammel note.

Brug kun route add til en test

En direkte rute er nyttig til at bevise, at et præfiks virker, før du gør det permanent. Grænsefladeformen undgår et gateway-opslag:

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

Ruten forsvinder ved næste genopkobling og afhænger af det grænsefladenummer, der findes i dag. Det gør den til en diagnostik, ikke en udrulning. Hvis testen virker, og den tjenestebundne rute ikke gør, skal du først sammenligne gatewayværdien; det er det felt, der oftest er forkert.

Vær forsigtig med råd, der erstatter VPN'ens standardrute for at gennemtvinge opdeling. En klient, der håndhæver en fuld tunnel, kan geninstallere sine ruter efter en genopkobling eller en politikopdatering, så den manuelle ændring fortrydes i stilhed. En håndfuld private præfikser er et routingproblem; at holde al internettrafik lokal mod en fuldtunnelpolitik er en beslutning på serversiden.

Vælg kun et hook, når adressen forhandles

For PPP-baserede links som L2TP, kører macOS /etc/ppp/ip-up, når linket er etableret. Scriptet modtager grænsefladenavnet og de forhandlede lokale og fjernadresser, så det kan tilføje en rute, der afhænger af den peer, serveren tildelte. Det er netop det tilfælde, en fast tjenesterute ikke kan udtrykke.

IKEv2 og leverandørklienter bruger måske slet ikke den PPP-vej, hvilket betyder, at scriptet kan forblive tavst hele sessionen. Når det sker, er et launchd-job, der aflæser scutil --nc status og handler på en tilstandsændring, den tilsvarende mekanisme, med en lille forsinkelse.

Uanset hvilket hook du bruger, gør det idempotent, og lad det kun fjerne ruter, det selv har oprettet. Et script, der sletter hver rute, der nævner tunnelen, vil til sidst slette den rute, der holder VPN-serveren tilgængelig, og forbindelsen falder, så snart det lykkes.

Afslut med at tjekke den private destination, almindelig browsing og en genopkoblings- eller søvncyklus. Undersøg derefter scutil --dns, fordi navneopløsning er en separat politik, og en fungerende rute beviser ikke, at de private navne opløses.