Beständiga rutter för ett Mac-VPN: networksetup eller en anslutningshook?

En rutt som skrivs in efter varje anslutning löser ögonblicket och inte veckan. På macOS är det varaktiga valet oftast ett prefix som lagras med VPN-tjänsten, eftersom tjänsten installerar det igen vid varje anslutning och tar bort det när tjänsten är nere. Alternativen är en tillfällig route add för test och en anslutningshook för adresser som bara är kända efter förhandlingen.

Bestäm om rutten hör till tjänsten eller sessionen

Fråga vad prefixet beror på. Om det är ett fast privat nätverk bakom en inbyggd VPN-tjänst hör rutten till den tjänsten. Om det beror på en peer-adress som ändras vid varje anslutning kan en hook eller ett tillståndsstyrt jobb vara en bättre ägare. Om du bara kontrollerar en väg för de närmaste fem minuterna räcker en tillfällig rutt.

Den tjänstebundna rutten har den renaste livscykeln. Den dyker upp med tjänsten och försvinner när tjänsten inte är ansluten, så den kan inte överleva tunneln den pekar på. Den egenskapen är värd mer än bekvämligheten med ett enradigt kommando.

En sessionsbunden rutt hör till gränssnittet, och det numret ändras utan varsel. En återanslutning kan ge tunneln ett annat utun-namn än föregående session använde, vilket gör ett hårdkodat kommando till en rutt som pekar på ingenting eller, värre, på en annan tunnel.

Läs aktuell rutt- och tjänstestatus

Börja med de namn systemet faktiskt använder. Tjänstenamnet i Nätverksinställningar är identifieraren för kommandona nedan, och den aktuella rutttabellen visar vad den anslutna klienten har installerat. Läs båda medan tunneln är uppe.

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

Den sökningen visar vilken gateway och vilket gränssnitt kärnan skulle välja för den här adressen just nu. Om den redan väljer tunneln är prefixet täckt och en ny rutt skulle vara överflödig. Om den väljer den lokala routern saknas prefixet i tunneln.

Notera peer-adressen medan du är ansluten. Den blir gateway-värdet i den tjänstebundna rutten, och den är oftast destinationen som visas för tunnelns standardrutt i netstat -rn.

Spara prefixet med networksetup

Verktyget networksetup kopplar extra rutter till en nätverkstjänst. För en tjänst som heter OfficeVPN och ett privat prefix som nås via tunnelns peer är formen:

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

Varje trippel efter tjänstenamnet ger en destination, dess nätmask och tunnelns peer som gateway. Ett anrop kan bära flera prefix, och ett tomt anrop rensar den sparade listan. Läsaren är verifieringssteget; om listan är tom tillämpades inte uppsättningen på tjänsten du tror.

Gatewayen måste vara tunnelns peer, inte den fysiska routern. En rutt som namnger den lokala gatewayen skickar det privata prefixet ut genom det fysiska gränssnittet, vilket är det ursprungliga felet med extra steg. En inaktuell peer är den vanligaste orsaken till att en korrekt utseende rutt aldrig bär trafik. Läs peer-adressen igen från det anslutna tillståndet i stället för att kopiera en adress från en gammal anteckning.

Använd route add bara för ett test

En direkt rutt är användbar för att bevisa att ett prefix fungerar innan du gör det permanent. Gränssnittsformen undviker en gateway-sökning:

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

Rutten försvinner vid nästa återanslutning och beror på gränssnittsnumret som finns idag. Det gör den till en diagnos, inte en utrullning. Om testet fungerar och den tjänstebundna rutten inte, jämför gateway-värdet först; det är fältet som oftast är fel.

Var försiktig med råd som ersätter VPN:ens standardrutt för att tvinga fram delning. En klient som genomdriver en full tunnel kan installera om sina rutter efter en återanslutning eller en policyuppdatering, så den manuella ändringen ångras tyst. Några få privata prefix är ett routingproblem; att hålla all internettrafik lokal mot en fulltunnelpolicy är ett beslut på serversidan.

Välj en hook bara när adressen förhandlas

För PPP-baserade länkar som L2TP kör macOS /etc/ppp/ip-up när länken är upprättad. Skriptet tar emot gränssnittsnamnet och de förhandlade lokala och avlägsna adresserna, så det kan lägga till en rutt som beror på peeren servern tilldelade. Det är precis det fall en fast tjänsterutt inte kan uttrycka.

IKEv2 och leverantörsklienter använder kanske inte den PPP-vägen alls, vilket innebär att skriptet kan vara tyst hela sessionen. När det händer är ett launchd-jobb som frågar scutil --nc status och agerar på en tillståndsändring den likvärdiga mekanismen, med en liten fördröjning.

Vilken hook du än använder, gör den idempotent och låt den bara ta bort rutter den själv skapade. Ett skript som raderar varje rutt som nämner tunneln kommer till slut att radera rutten som håller VPN-servern nåbar, och anslutningen faller så snart det lyckas.

Avsluta med att kontrollera den privata destinationen, vanligt surfande och en återanslutnings- eller sömncykel. Inspektera sedan scutil --dns, eftersom namnuppslagning är en separat policy och en fungerande rutt inte bevisar att de privata namnen löses.