Mga persistent na ruta para sa Mac VPN: networksetup o isang connect hook?

Ang rutang itinatype pagkatapos ng bawat koneksyon ay lumulutas sa sandali at hindi sa linggo. Sa macOS, ang matibay na pagpipilian ay karaniwang prefix na nakaimbak kasama ng serbisyo ng VPN, dahil ini-install itong muli ng serbisyo sa bawat koneksyon at tinatanggal kapag patay ang serbisyo. Ang mga alternatibo ay isang pansamantalang route add para sa pagsubok at isang connect hook para sa mga address na malalaman lamang pagkatapos ng negosasyon.

Magpasya kung ang ruta ay pag-aari ng serbisyo o ng sesyon

Itanong kung ano ang dipende ng prefix. Kung ito ay isang nakapirming pribadong network sa likod ng isang native na serbisyo ng VPN, ang ruta ay pag-aari ng serbisyong iyon. Kung ito ay dipende sa isang address ng peer na nagbabago sa bawat koneksyon, isang hook o gawaing pinapatakbo ng estado ang maaaring maging mas mabuting may-ari. Kung sinusuri mo lamang ang isang landas para sa susunod na limang minuto, sapat na ang isang pansamantalang ruta.

Ang rutang nakatali sa serbisyo ang may pinakamalinis na ikot ng buhay. Lumilitaw ito kasama ng serbisyo at nawawala kapag hindi konektado ang serbisyo, kaya hindi ito maaaring mabuhay nang mas matagal kaysa sa tunnel na tinutukoy nito. Ang katangiang iyon ay mas mahalaga kaysa sa kaginhawahan ng isang linyang utos.

Ang rutang nakatali sa sesyon ay pag-aari ng interface, at nagbabago ang numerong iyon nang walang abiso. Ang muling pagkonekta ay maaaring magbigay sa tunnel ng ibang pangalang utun kaysa sa ginamit ng nakaraang sesyon, na ginagawang isang rutang tumuturo sa wala o, mas masahol pa, sa ibang tunnel ang isang hardcoded na utos.

Basahin ang kasalukuyang estado ng ruta at serbisyo

Magsimula sa mga pangalang aktwal na ginagamit ng system. Ang pangalan ng serbisyo sa Mga Setting ng Network ang identifier para sa mga utos sa ibaba, at ang kasalukuyang talahanayan ng ruta ay nagpapakita kung ano ang ininstall ng konektadong kliyente. Basahin ang dalawa habang nakaup ang tunnel.

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

Ipinapakita ng paghahanap na iyon kung aling gateway at interface ang pipiliin ng kernel para sa address na ito sa sandaling ito. Kung pinipili na nito ang tunnel, sakop ang prefix at magiging kalabisan ang isang bagong ruta. Kung pinipili nito ang lokal na router, kulang ang tunnel sa prefix na iyon.

Itala ang address ng peer habang konektado. Ito ang magiging halaga ng gateway sa rutang nakatali sa serbisyo, at karaniwang ito ang destinasyong ipinapakita para sa default na ruta ng tunnel sa netstat -rn.

Itago ang prefix gamit ang networksetup

Ang tool na networksetup ay nag-uugnay ng karagdagang ruta sa isang serbisyo ng network. Para sa serbisyong pinangalanang OfficeVPN at pribadong prefix na naaabot sa pamamagitan ng peer ng tunnel, ang anyo ay:

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

Ang bawat triple pagkatapos ng pangalan ng serbisyo ay nagbibigay ng destinasyon, netmask nito at peer ng tunnel bilang gateway. Ang isang tawag ay maaaring magdala ng ilang prefix, at ang walang laman na tawag ay nagbubura ng nakaimbak na listahan. Ang mambabasa ang hakbang ng pagpapatunay; kung walang laman ang listahan, hindi nailapat ang set sa serbisyong iniisip mo.

Ang gateway ay dapat na peer ng tunnel, hindi ang pisikal na router. Ang rutang nagngangalan sa lokal na gateway ay nagpapadala ng pribadong prefix palabas sa pisikal na interface, na siyang orihinal na pagkabigo na may dagdag na hakbang. Ang lumang peer ang pinakakaraniwang dahilan kung bakit ang rutang mukhang tama ay hindi kailanman nagdadala ng trapiko. Basahin muli ang peer mula sa konektadong estado sa halip na kopyahin ang address mula sa lumang tala.

Gamitin ang route add para sa pagsubok lamang

Ang direktang ruta ay kapaki-pakinabang upang patunayan na gumagana ang isang prefix bago mo itong gawing permanente. Iniiwasan ng anyo ng interface ang paghahanap ng gateway:

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

Nawawala ang ruta sa susunod na muling pagkonekta at nakadepende sa numero ng interface na umiiral ngayon. Ginagawa iyon na diagnosis, hindi deployment. Kung gumagana ang pagsubok at hindi ang rutang nakatali sa serbisyo, ihambing muna ang halaga ng gateway; iyon ang patlang na pinakamadalas mali.

Mag-ingat sa mga payong pinapalitan ang default na ruta ng VPN upang pilitin ang paghahati. Ang kliyenteng nagpapatupad ng buong tunnel ay maaaring mag-install muli ng mga ruta nito pagkatapos ng muling pagkonekta o pag-refresh ng patakaran, kaya tahimik na binabalik ang manu-manong pagbabago. Ang ilang pribadong prefix ay problema sa routing; ang panatilihing lokal ang lahat ng trapiko sa internet laban sa patakaran ng buong tunnel ay desisyon sa panig ng server.

Pumili ng hook lamang kapag nakikipagnegosasyon ang address

Para sa mga link na nakabatay sa PPP tulad ng L2TP, pinapatakbo ng macOS ang /etc/ppp/ip-up kapag naitatag ang link. Natatanggap ng script ang pangalan ng interface at ang naipagkasundong lokal at malayong address, kaya makakadagdag ito ng rutang dipende sa peer na itinalaga ng server. Iyon ang eksaktong kaso na hindi maipahayag ng nakapirming rutang pangserbisyo.

Maaaring hindi gamitin ng IKEv2 at mga kliyente ng vendor ang PPP path na iyon, na nangangahulugang maaaring manatiling tahimik ang script sa buong sesyon. Kapag nangyari iyon, ang gawaing launchd na nagtatanong sa scutil --nc status at kumikilos sa pagbabago ng estado ang katumbas na mekanismo, na may maliit na pagkaantala.

Anuman ang hook na gamitin mo, gawin itong idempotent at hayaang alisin lamang ang mga rutang nilikha nito. Ang script na nagbubura ng bawat rutang nagbabanggit ng tunnel ay sa huli ay magbubura ng rutang nagpapanatili sa server ng VPN na maabot, at babagsak ang koneksyon sa oras na magtagumpay ito.

Tapusin sa pamamagitan ng pagsuri sa pribadong destinasyon, ordinaryong pag-browse at ikot ng muling pagkonekta o pagtulog. Pagkatapos ay siyasatin ang scutil --dns, dahil ang paglutas ng pangalan ay hiwalay na patakaran at ang gumaganang ruta ay hindi nagpapatunay na nareresolba ang mga pribadong pangalan.