Rrugë të përhershme për një VPN Mac: networksetup apo një hook lidhjeje?

Një rrugë e shkruar pas çdo lidhjeje zgjidh momentin dhe jo javën. Në macOS, zgjedhja e qëndrueshme është zakonisht një prefiks i ruajtur me shërbimin VPN, sepse shërbimi e riinstalon në çdo lidhje dhe e heq kur shërbimi është i ndalur. Alternativat janë një route add i përkohshëm për testim dhe një hook lidhjeje për adresa që njihen vetëm pas negociatës.

Vendosni nëse rruga i përket shërbimit apo sesionit

Pyetni nga çfarë varet prefiksi. Nëse është një rrjet privat fiks pas një shërbimi VPN amtare, rruga i përket atij shërbimi. Nëse varet nga një adresë partneri që ndryshon në çdo lidhje, një hook ose një punë e drejtuar nga gjendja mund të jetë pronari më i mirë. Nëse po kontrolloni vetëm një rrugë për pesë minutat e ardhshme, një rrugë e përkohshme mjafton.

Rruga e lidhur me shërbimin ka ciklin e jetës më të pastër. Shfaqet me shërbimin dhe zhduket kur shërbimi nuk është i lidhur, kështu që nuk mund të mbijetojë më shumë se tuneli ku tregon. Ajo veti vlen më shumë se lehtësia e një komande një rresht.

Një rrugë e lidhur me sesionin i përket ndërfaqes, dhe ai numër ndryshon pa njoftim. Një rilidhje mund t'i japë tunelit një emër utun të ndryshëm nga ai i sesionit të mëparshëm, gjë që e kthen një komandë të koduar fort në një rrugë që nuk tregon asgjë ose, më keq, një tunel tjetër.

Lexoni gjendjen aktuale të rrugës dhe shërbimit

Filloni me emrat që sistemi përdor vërtet. Emri i shërbimit në Cilësimet e rrjetit është identifikuesi për komandat më poshtë, dhe tabela aktuale e rrugëve tregon çfarë ka instaluar klienti i lidhur. Lexoni të dyja ndërsa tuneli është aktiv.

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

Ai kërim tregon cilin portë dhe ndërfaqe do të zgjidhte kerneli për këtë adresë në këtë moment. Nëse tashmë zgjedh tunelin, prefiksi është i mbuluar dhe një rrugë e re do të ishte e tepërt. Nëse zgjedh ruterin lokal, tunelit i mungon ai prefiks.

Shënoni adresën e partnerit ndërsa jeni i lidhur. Ajo bëhet vlera e portës në rrugën e lidhur me shërbimin, dhe zakonisht është destinacioni i shfaqur për rrugën e paracaktuar të tunelit në netstat -rn.

Ruani prefiksin me networksetup

Mjeti networksetup bashkëngjit rrugë shtesë një shërbimi rrjeti. Për një shërbim të quajtur OfficeVPN dhe një prefiks privat të arritur përmes partnerit të tunelit, forma është:

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

Çdo treshe pas emrit të shërbimit jep një destinacion, maskën e tij të rrjetit dhe partnerin e tunelit si portë. Një thirrje mund të mbajë disa prefikse, dhe një thirrje e zbrazët fshin listën e ruajtur. Lexuesi është hapi i verifikimit; nëse lista është e zbrazët, cilësimi nuk u zbatua për shërbimin që mendoni.

Porta duhet të jetë partneri i tunelit, jo ruteri fizik. Një rrugë që emërton portën lokale e dërgon prefiksin privat përmes ndërfaqes fizike, që është dështimi origjinal me hapa shtesë. Një partner i vjetruar është arsyeja më e zakonshme pse një rrugë që duket e saktë nuk mbart kurrë trafik. Rilexoni partnerin nga gjendja e lidhur në vend që të kopjoni një adresë nga një shënim i vjetër.

Përdorni route add vetëm për një test

Një rrugë e drejtpërdrejtë është e dobishme për të provuar se një prefiks funksionon përpara se ta bëni të përhershëm. Forma me ndërfaqe shmang një kërkim porte:

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

Rruga zhduket në rilidhjen tjetër dhe varet nga numri i ndërfaqes që ekziston sot. Kjo e bën atë një diagnostikim, jo një vendosje. Nëse testi funksionon dhe rruga e lidhur me shërbimin jo, krahasoni fillimisht vlerën e portës; është fusha që është më shpesh e gabuar.

Kujdes me këshillat që zëvendësojnë rrugën e paracaktuar të VPN për të imponuar ndarjen. Një klient që imponon një tunel të plotë mund t'i riinstalojë rrugët e tij pas një rilidhjeje ose një rifreskimi politike, kështu që ndryshimi manual anulohet në heshtje. Disa prefikse private janë problem rrugëtimi; mbajtja e të gjithë trafikut të internetit lokalisht kundër një politike tuneli të plotë është vendim në anën e serverit.

Zgjidhni një hook vetëm kur adresa negociohet

Për lidhje të bazuara në PPP si L2TP, macOS ekzekuton /etc/ppp/ip-up sapo lidhja të vendoset. Skripti merr emrin e ndërfaqes dhe adresat lokale e të largëta të negociuar, kështu që mund të shtojë një rrugë që varet nga partneri që caktoi serveri. Ky është pikërisht rasti që një rrugë fikse shërbimi nuk mund ta shprehë.

IKEv2 dhe klientët e prodhuesve mund të mos e përdorin fare atë rrugë PPP, që do të thotë se skripti mund të qëndrojë i heshtur gjatë gjithë sesionit. Kur kjo ndodh, një detyrë launchd që pyet scutil --nc status dhe vepron mbi një ndryshim gjendjeje është mekanizmi ekuivalent, me një vonesë të vogël.

Çfarëdo hook që përdorni, bëjeni idempotent dhe lëreni të heqë vetëm rrugët që ka krijuar vetë. Një skript që fshin çdo rrugë që përmend tunelin do të fshijë përfundimisht rrugën që mban serverin VPN të arritshëm, dhe lidhja do të bjerë sapo të ketë sukses.

Përfundoni duke kontrolluar destinacionin privat, shfletimin e zakonshëm dhe një cikël rilidhjeje ose gjumi. Pastaj inspektoni scutil --dns, sepse zgjidhja e emrave është politikë e veçantë dhe një rrugë që funksionon nuk dëshmon se emrat privatë zgjidhen.