Daŭraj itineroj por Mac-VPN: networksetup aŭ konekta hoko?

Itinero tajpita post ĉiu konekto solvas la momenton kaj ne la semajnon. Sur macOS la daŭra elekto kutime estas prefikso konservita kun la VPN-servo, ĉar la servo reinstalas ĝin ĉe ĉiu konekto kaj forigas ĝin kiam la servo estas malsupra. La alternativoj estas provizora route add por testado kaj konekta hoko por adresoj konataj nur post traktado.

Decidu ĉu la itinero apartenas al la servo aŭ al la seanco

Demandu de kio dependas la prefikso. Se ĝi estas fiksa privata reto malantaŭ denaska VPN-servo, la itinero apartenas al tiu servo. Se ĝi dependas de samtavola adreso kiu ŝanĝiĝas ĉe ĉiu konekto, hoko aŭ stato-gvidata tasko povas esti la pli bona posedanto. Se vi nur kontrolas vojon por la venontaj kvin minutoj, provizora itinero sufiĉas.

La servo-ligita itinero havas la plej puran vivociklon. Ĝi aperas kun la servo kaj malaperas kiam la servo ne estas konektita, do ĝi ne povas postvivi la tunelon al kiu ĝi montras. Tiu eco valoras pli ol la oportuneco de unulinia komando.

Seanco-ligita itinero apartenas al la interfaco, kaj tiu numero ŝanĝiĝas sen avizo. Rekonekto povas doni al la tunelo alian utun-nomon ol tiu uzita de la antaŭa seanco, kio igas fikskodan komandon itinero kiu montras al nenio aŭ, pli malbone, al alia tunelo.

Legu la nunan itinero- kaj servostaton

Komencu per la nomoj kiujn la sistemo efektive uzas. La serva nomo en Retagordoj estas la identigilo por la subaj komandoj, kaj la nuna itinera tabelo montras kion instalis la konektita kliento. Legu ambaŭ dum la tunelo estas aktiva.

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

Tiu serĉo montras kiun pordegon kaj interfacon la kerno elektus por ĉi tiu adreso en ĉi tiu momento. Se ĝi jam elektas la tunelon, la prefikso estas kovrita kaj nova itinero estus superflua. Se ĝi elektas la lokan enkursigilon, la tunelo mankas tiun prefikson.

Notu la samtavolan adreson dum vi estas konektita. Ĝi fariĝas la pordega valoro en la servo-ligita itinero, kaj ĝi kutime estas la celo montrita por la defaŭlta itinero de la tunelo en netstat -rn.

Konservu la prefikson per networksetup

La ilo networksetup alkroĉas pliajn itinerojn al reta servo. Por servo nomita OfficeVPN kaj privata prefikso atingata tra la tunela samtavolo, la formo estas:

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

Ĉiu triopo post la serva nomo donas celon, ĝian retan maskon kaj la tunelan samtavolon kiel pordegon. Unu voko povas porti plurajn prefiksojn, kaj malplena voko malplenigas la konservitan liston. La legilo estas la kontrola paŝo; se la listo estas malplena, la agordo ne aplikiĝis al la servo kiun vi pensas.

La pordego devas esti la tunela samtavolo, ne la fizika enkursigilo. Itinero kiu nomas la lokan pordegon sendas la privatan prefikson tra la fizika interfaco, kio estas la origina malsukceso kun pliaj paŝoj. Malaktuala samtavolo estas la plej ofta kialo kial ĝuste aspektanta itinero neniam portas trafikon. Relutu la samtavolon el la konektita stato anstataŭ kopii adreson el malnova noto.

Uzu route add nur por testo

Rekta itinero utilas por pruvi ke prefikso funkcias antaŭ ol igi ĝin daŭra. La interfaca formo evitas pordegan serĉon:

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

La itinero malaperas ĉe la venonta rekonekto kaj dependas de la interfaca numero kiu ekzistas hodiaŭ. Tio igas ĝin diagnozilo, ne deplojo. Se la testo funkcias kaj la servo-ligita itinero ne, komparu unue la pordegan valoron; tiu estas la kampo plej ofte malĝusta.

Estu singarda pri konsiloj kiuj anstataŭigas la defaŭltan itinero de la VPN por devigi disiĝon. Kliento kiu trudas plenan tunelon povas reinstali siajn itinerojn post rekonekto aŭ politika refreŝigo, do la permana ŝanĝo estas silente malfarita. Kelkaj privataj prefiksoj estas enkursiga problemo; teni la tutan interretan trafikon loke kontraŭ plentunela politiko estas decido ĉe la servila flanko.

Elektu hokon nur kiam la adreso estas traktata

Por PPP-bazitaj ligiloj kiel L2TP, macOS plenumas /etc/ppp/ip-up post kiam la ligilo establiĝas. La skripto ricevas la interfacan nomon kaj la traktitajn lokan kaj malproksiman adresojn, do ĝi povas aldoni itinerojn dependantajn de la samtavolo atribuita de la servilo. Ĝuste tio estas la kazo kiun fiksa serva itinero ne povas esprimi.

IKEv2 kaj vendistaj klientoj eble tute ne uzas tiun PPP-vojon, kio signifas ke la skripto povas resti silenta dum la tuta seanco. Kiam tio okazas, launchd-tasko kiu demandas scutil --nc status kaj agas je ŝanĝo de stato estas la ekvivalenta mekanismo, kun malgranda prokrasto.

Kiun ajn hokon vi uzas, igu ĝin idempota kaj lasu ĝin forigi nur la itinerojn kiujn ĝi mem kreis. Skripto kiu forigas ĉiujn itinerojn menciontajn la tunelon fine forigos la itineron kiu tenas la VPN-servilon atingebla, kaj la konekto falos tuj kiam ĝi sukcesos.

Finu kontrolante la privatan celon, ordinaran retumadon kaj rekonektan aŭ dorman ciklon. Poste inspektu scutil --dns, ĉar nomresolvo estas aparta politiko kaj funkcianta itinero ne pruvas ke la privataj nomoj solviĝas.