Rute persistente pentru un VPN pe Mac: networksetup sau un hook de conexiune?

O rută scrisă după fiecare conexiune rezolvă momentul, nu săptămâna. Pe macOS, alegerea durabilă este de obicei un prefix stocat împreună cu serviciul VPN, pentru că serviciul îl reinstalează la fiecare conexiune și îl elimină atunci când serviciul este oprit. Alternativele sunt un route add temporar pentru testare și un hook de conexiune pentru adrese cunoscute abia după negociere.

Decideți dacă ruta aparține serviciului sau sesiunii

Întrebați de ce depinde prefixul. Dacă este o rețea privată fixă în spatele unui serviciu VPN nativ, ruta aparține acelui serviciu. Dacă depinde de o adresă de partener care se schimbă la fiecare conexiune, un hook sau o sarcină condusă de stare poate fi proprietarul mai bun. Dacă verificați doar o cale pentru următoarele cinci minute, o rută temporară este suficientă.

Ruta legată de serviciu are cel mai curat ciclu de viață. Apare împreună cu serviciul și dispare când serviciul nu este conectat, așa că nu poate supraviețui tunelului către care indică. Această proprietate valorează mai mult decât comoditatea unei comenzi de o singură linie.

O rută legată de sesiune aparține interfeței, iar acel număr se schimbă fără anunț. O reconectare poate da tunelului un nume utun diferit de cel folosit de sesiunea anterioară, ceea ce transformă o comandă codificată fix într-o rută care nu indică nimic sau, mai rău, un alt tunel.

Citiți starea actuală a rutei și a serviciului

Începeți cu numele pe care sistemul le folosește efectiv. Numele serviciului din Setări de rețea este identificatorul pentru comenzile de mai jos, iar tabelul de rute actual arată ce a instalat clientul conectat. Citiți-le pe amândouă cât timp tunelul este activ.

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

Această căutare arată ce gateway și ce interfață ar alege nucleul pentru această adresă în acest moment. Dacă alege deja tunelul, prefixul este acoperit și o rută nouă ar fi redundantă. Dacă alege routerul local, tunelului îi lipsește acel prefix.

Notați adresa partenerului cât timp sunteți conectat. Devine valoarea gateway-ului în ruta legată de serviciu și este de obicei destinația afișată pentru ruta implicită a tunelului în netstat -rn.

Stocați prefixul cu networksetup

Utilitarul networksetup atașează rute suplimentare unui serviciu de rețea. Pentru un serviciu numit OfficeVPN și un prefix privat atins prin partenerul tunelului, forma este:

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

Fiecare triplu după numele serviciului dă o destinație, masca sa de rețea și partenerul tunelului ca gateway. Un singur apel poate purta mai multe prefixe, iar un apel gol șterge lista stocată. Cititorul este pasul de verificare; dacă lista este goală, setul nu s-a aplicat serviciului la care vă gândiți.

Gateway-ul trebuie să fie partenerul tunelului, nu routerul fizic. O rută care numește gateway-ul local trimite prefixul privat prin interfața fizică, ceea ce este eșecul original cu pași suplimentari. Un partener învechit este cel mai frecvent motiv pentru care o rută corectă la vedere nu transportă niciodată trafic. Recitiți partenerul din starea conectată în loc să copiați o adresă dintr-o notă veche.

Folosiți route add doar pentru un test

O rută directă este utilă pentru a demonstra că un prefix funcționează înainte de a-l face permanent. Forma cu interfață evită o căutare a gateway-ului:

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

Ruta dispare la următoarea reconectare și depinde de numărul de interfață care există astăzi. Asta o face un diagnostic, nu o implementare. Dacă testul funcționează și ruta legată de serviciu nu, comparați mai întâi valoarea gateway-ului; acesta este câmpul cel mai des greșit.

Fiți atenți la sfaturile care înlocuiesc ruta implicită a VPN-ului pentru a forța divizarea. Un client care impune un tunel complet poate reinstala rutele după o reconectare sau o reîmprospătare a politicii, așa că modificarea manuală este anulată în tăcere. Câteva prefixe private sunt o problemă de rutare; păstrarea întregului trafic de internet local împotriva unei politici de tunel complet este o decizie pe partea de server.

Alegeți un hook doar când adresa este negociată

Pentru legături bazate pe PPP, cum ar fi L2TP, macOS execută /etc/ppp/ip-up odată ce legătura este stabilită. Scriptul primește numele interfeței și adresele locală și la distanță negociate, așa că poate adăuga o rută care depinde de partenerul alocat de server. Este exact cazul pe care o rută fixă de serviciu nu îl poate exprima.

IKEv2 și clienții producătorilor pot să nu folosească deloc acea cale PPP, ceea ce înseamnă că scriptul poate rămâne tăcut toată sesiunea. Când se întâmplă asta, o sarcină launchd care interoghează scutil --nc status și acționează la o schimbare de stare este mecanismul echivalent, cu o mică întârziere.

Indiferent de hook-ul folosit, faceți-l idempotent și lăsați-l să elimine doar rutele pe care le-a creat. Un script care șterge fiecare rută ce menționează tunelul va șterge în cele din urmă ruta care menține serverul VPN accesibil, iar conexiunea va cădea imediat ce reușește.

Încheiați verificând destinația privată, navigarea obișnuită și un ciclu de reconectare sau somn. Apoi inspectați scutil --dns, pentru că rezolvarea numelor este o politică separată, iar o rută funcțională nu dovedește că numele private se rezolvă.