Ang karagdagang ruta ng Mac VPN ay kailangan ng may-ari, hindi ng login script

Ang maabot ang isang pribadong prefix sa pamamagitan ng VPN ay isang pangangailangang may tagal: ito ay umiiral habang ang koneksyong iyon ay magagamit, at nagtatapos kapag nagtapos ang koneksyon. Hindi ito maipapahayag ng isang login script, dahil ang pag-login at ang pag-angat ng tunnel ay magkaibang sandali, at ang tunnel na umiiral sa pag-login ay maaaring hindi ang nagdadala ng trapiko makalipas ang isang minuto. Ang unang desisyon ay hindi kung aling utos ang patatakbuhin. Ito ay kung aling bahagi ang nagmamay-ari ng prefix.

Kailangan ng prefix ang isang may-ari, hindi isang sandali

Simulan sa pagsulat ng pangangailangan bilang pangungusap na may simuno: maabot 10.77.0.0/24 sa pamamagitan ng Office VPN habang nakataas ang koneksyong iyon. Pinapangalanan ng pangungusap na iyon ang prefix, ang koneksyon at ang kondisyon, at agad nitong tinatanggihan ang dalawang sikat na kapalit: isang login hook at isang pangalan ng interface tulad ng ppp0 o utun2.

Ang mga pangalan ng interface ay itinatakda sa oras ng pagtakbo at hindi matatag sa pagitan ng mga muling pagkonekta. Ang isang hook na tumutugma sa pangalang nakita nito noong nakaraang linggo ay alinman sa hindi magaganap o magaganap laban sa interface ng ibang tao. Ang parehong kinalabasan ay lumilitaw na bug sa pagruruta at hindi ang lumang palagay na taglay nila. Ang parehong pagtutol ay naaangkop sa anumang script na nakasalalay sa isang pangalang umiiral lamang habang nakataas ang isang partikular na tunnel.

Gumamit ng suportadong pinagmulan ng layunin ng ruta

Ang gateway, pinamamahalaang profile o ang dokumentadong mekanismo ng ruta ng kliyenteng nagmamay-ari ang tamang lugar, kapag ang mekanismong iyon ay maipapahayag ang pangangailangan. Alin ang naaangkop ay nakasalalay sa protocol at provider, at ang mga susi ay hindi naglalakbay sa pagitan nila, kaya ang isang halagang nagko-configure ng profile OpenVPN ay walang sinasabi tungkol sa native na kliyenteng L2TP o IKEv2.

Para sa mga developer ng packet tunnel, ang mga setting ng IPv4 tunnel ng Apple ay hayagang inilalantad ang mga rutang kasama at hindi kasama, at ang IPv6 ay may katumbas nito. Ito ay mga API na ginagamit ng provider, hindi patunay na ang bawat native na panel ng VPN ay nag-aalok sa administrator ng di-makatwirang listahan ng ruta. Kung ang kasalukuyang kombinasyon ay hindi maipapahayag ang mga prefix na kailangan mo, ang susunod na hakbang ay isang suportadong landas ng configuration mula sa operator, hindi isang ibang app na iniinstala sa pag-asang mas mahusay itong kikilos.

Kasama sa haba ng buhay ang paglilinis

Minsan ang isang panlabas na katulong ay tunay na kailangan, at kapag gayon, ang «idagdag ang ruta» ang pinakamaliit na bahagi ng trabaho nito. Kailangan nitong malaman kung aling koneksyon ang pinaglilingkuran nito at kung aling interface ang ginagamit ng koneksyong iyon, maghintay hanggang sa tumahimik ang kaugnay na kalagayan ng network, manatiling idempotent kapag tumakbo nang dalawang beses nang sunud-sunod, at walang lilinisin na hindi nito mismo ininstalla.

Ang huling sugnay ang masakit. Ang isang katulong na nagbubura ng bawat rutang tumutugma sa prefix ng opisina ay maaga o huli ay magbubura ng rutang hindi nito idinagdag. Ang resultang pagkawala ng serbisyo ay isinisisi sa kliyente ng VPN, dahil ang kliyente ang bahaging nakikita ng gumagamit. Ang pagpapasya kung ano ang pag-aari ng katulong bago ito isulat ay mas mura kaysa ipaliwanag pagkatapos kung bakit tumigil sumagot ang isang lokal na subnet.

Ang karera sa muling pagkonekta

Isipin ang isang mabilis na muling pagkonekta. Bumagsak ang session A, umangat ang session B at ininstalla ang ruta nito, at pagkatapos ay tumakbo sa wakas ang naantalang paglilinis ng A. Kung ang paglilinis na iyon ay nag-aalis ng mga ruta ayon sa prefix, dinadala nito ang wastong kalagayan ng B, at ang koneksyong gumana isang segundo ang nakalipas ay nagruruta na ngayon sa wala.

Ito ay karera ng pagmamay-ari, at ang pagdagdag ng pagtulog sa script ay nagbabago lamang kung aling panig ang mananalo. Ang solusyon ay gawing may kondisyon sa pagkakakilanlan ang paglilinis: ihambing ang interface at session na ininstalla ng katulong sa mga may bisa pa, at alisin lamang kapag tumutugma.

Ano ang susubukan, at ano ang hindi kaya ng isang ruta

Dapat saklawin ng pagtanggap ang apat na pagbabago: ang unang koneksyon, isang muling pagkonekta sa ibang interface, isang pagtatangkang kumonekta na nabigo, at ang huling paghihiwalay. Pagkatapos ng bawat isa, basahin ang rutang aktwal na pinili ng sistema para sa isang address sa malayong panig, hindi ang inaasahan mo.

route -n get 10.77.0.5
netstat -rn -f inet

Isama ang mga mahirap na kaso sa parehong pag-ikot: IPv6 kung saan kailangan, isang lokal na prefix na nagsasapawan sa malayo, at ang ruta patungo sa pampublikong endpoint ng VPN mismo, na dapat magpatuloy sa paggana habang nakataas ang tunnel. Pagkatapos ay isulat kung ano ang hindi ruta. Pumipili ito ng packet; hindi ito nagbibigay ng pahintulot sa malayong panig at hindi ito gumagawa ng daan pabalik, at ang mga iyon ay nananatiling magkahiwalay na pangangailangan na may magkahiwalay na may-ari.

Ang resultang gusto mo ay isang prefix na sumusunod sa suportadong may-ari ng koneksyon nito sa bawat pagbabago, hindi isang utos na nagtagumpay nang isang beses nang nagkataon sa makinang kinasulatan nito.