Simulan ang naka-save na Mac VPN mula sa terminal gamit ang scutil --nc

Mayroon kang naka-save na serbisyo ng VPN sa Mga Setting ng System, at gusto mong simulan ito ng terminal. Sa macOS ang sinusuportahang landas ay scutil --nc, ngunit para lamang sa mga serbisyong pag-aari ng sariling tagapamahala ng mga koneksyon sa network ng system. Ang menu bar ay hindi ang API: ang mga kliyente ng third-party ay karaniwang may sariling automation, at ang profile na itinulak ng serbisyo ng pamamahala ay maaaring tumanggi sa lokal na pagsisimula. Ito ang checklist na sinusunod ko: hanapin ang eksaktong serbisyo, basahin ang estado nito, simulan ito, hintayin na magbago ang estado, at pagkatapos ay patunayan na talagang ginagamit ng trapiko ang tunnel. Huminto sa unang hakbang na hindi tugma, dahil ipinapalagay ng bawat susunod na utos na nagtagumpay ang nauna.

Hanapin ang serbisyo bago mo subukang simulan ito

Magsimula sa imbentaryo, hindi sa pangalan ng profile na natatandaan mo:

scutil --nc help
scutil --nc list

Ang bawat linya ay nagpapares ng estado sa identifier ng serbisyo, uri at display name. Ang identifier ang halagang sinusulatan ng mga script, dahil paulit-ulit ang mga display name at maaaring i-edit. Ang manwal ng scutil ng Apple ay nagdodokumento ng mode ng koneksyon sa network, habang ang naka-install na --nc help ang awtoritatibong listahan ng mga subcommand sa Mac na iyon; huwag ipagpalagay na may flag mula sa lumang gabay na umiiral pa sa iyong bersyon ng macOS.

Ang walang laman na listahan ay resulta, hindi error. Ang serbisyong ginawa ng kliyente ng vendor o profile ng pamamahala ay maaaring aktibo habang hindi nakikita dito, o nakikita na may uri na hindi kayang patakbuhin ng native controller. Sa ganoong kaso, gamitin ang tool ng vendor o ang dokumentasyon ng profile. Ang paggawa ng parallel na native na profile para lang may masimulan ay masamang kalakalan.

Basahin ang kasalukuyang estado at kumpirmahin ang tagapili

Tanungin ang serbisyo tungkol sa estado bago ito simulan, para malaman mo kung ano ang dapat baguhin ng matagumpay na pagsisimula:

scutil --nc status "Office VPN"

Kung dalawang serbisyo ang nagbabahagi ng isang display name, ang pangalan ay malabo. Ipasa ang identifier sa halip; tinatanggap ng utos ang dalawa, ngunit ang identifier lamang ang garantisadong pipili ng isang serbisyo. Bago ito i-parse sa script, tiyakin na ang salita ng estado ay isa sa mga alam mo — karaniwang Connected, Disconnected, Connecting o Disconnecting. Tingnan din kung ang profile ay pinamamahalaan, dahil ang naka-lock na configuration ay maaaring tanggapin ang utos at balewalain pa rin ito o humingi ng kumpirmasyon.

Mura ang tawag sa estado na ito, kaya gamitin ito bilang bantay sa automation: magsimula lamang kapag ang estado ay Disconnected, at huwag ituring ang Connecting na pagkabigo. Kung ang serbisyo ay Connected na, laktawan ang pagsisimula sa halip na abalahin ang gumaganang tunnel.

Simulan ang koneksyon at hintayin na maging matatag ang estado

Ang kahilingan sa pagsisimula ay asynchronous. Bumabalik ang utos kapag tinanggap ang kahilingan, hindi kapag natapos ang authentication o nailagay ang mga ruta. Patakbuhin ito, pagkatapos ay suriin ang estado nang may limitadong paghihintay at lumabas kung bumalik ang serbisyo sa Disconnected:

scutil --nc start "Office VPN"
n=0
while [ "$n" -lt 30 ]; do
  state=$(scutil --nc status "Office VPN" | head -n 1)
  [ "$state" = "Connected" ] && break
  [ "$state" = "Disconnected" ] && { echo "start failed"; exit 1; }
  sleep 2
  n=$((n + 1))
done

Ang estado ng Connecting na hindi kailanman nalulutas ay karaniwang tumutukoy sa mga kredensyal, MFA o sa server, hindi sa scutil. Hindi makapagbibigay ang utos ng interactive na pag-login, kaya ang profile na umaasa sa token o hardware key ay mananatili sa Connecting at kalaunan ay babalik. Basahin ang salita ng estado bago magdagdag ng mga pagtatangka; ang loop laban sa prompt ng authentication ay hindi maaaring magtagumpay.

Huwag ituring na kahandaan ang exit status ng shell. Ang kapaki-pakinabang na senyales ay ang string ng estado, na sinusundan ng patunay na ang tunnel ay nagdadala ng trapiko. Ang utos ng pagsisimula na tahimik na bumabalik ay maaari ka pa ring iwanan sa koneksyong hindi kailanman nagpapatunay.

Patunayan na ang tunnel ay nagdadala ng trapiko, hindi lamang nagsasabing Connected

Inilalarawan ng Connected ang koneksyon, hindi ang desisyon sa routing. Ang native na PPP at IKEv2 na serbisyo ay gumagawa ng ppp o utun na interface at naglalagay ng mga ruta, habang ang split tunnel ay sadyang iniiwang hindi ginalaw ang default na ruta. Suriin ang mga interface at ang dalawang pamilya ng address:

ifconfig -l
netstat -rn -f inet
netstat -rn -f inet6
scutil --dns

Hanapin ang interface na ginawa ng serbisyo sa halip na hulaan ang isang numero, pagkatapos ay tanungin ang routing table kung aling interface ang ginagamit ng isang partikular na destinasyon: route -n get 10.0.0.10, na pinapalitan ng panloob na host. Kung iniuulat nito ang pisikal na interface, aktibo ang tunnel ngunit hindi nito dinadala ang daloy na iyon. Tingnan ang mga ruta ng split tunnel, ang pagkakasunod-sunod ng resolver at anumang lokal na tuntunin ng firewall na nagpapahintulot sa interface ng tunnel ngunit hindi sa proseso.

Ang paglutas ng pangalan ang karaniwang maling negatibo. Ang mga panloob na pangalan ay maaaring malutas sa maling resolver habang ang tunnel ay ganap na malusog, na mukhang sira ng VPN at hindi. Ipinapakita ng scutil --dns ang pagkakasunod-sunod na gagamitin ng macOS; pagkatapos ng pagbabago ng resolver, i-flush ang cache gamit ang dscacheutil -flushcache at sudo killall -HUP mDNSResponder.

Panatilihin ang mga kredensyal at pribilehiyo sa labas ng command line

Huwag kailanman maglagay ng password, pre-shared key o token sa mga argumento. Nakikita ang mga argumento sa mga listahan ng proseso at napupunta sa kasaysayan ng shell, at ang nakopyang transcript ng suporta ay maaaring magleak sa mga ito. Ang sariling paghawak ng kredensyal ng profile — item ng Keychain, prompt ng system o daloy ng authentication ng kliyente — ang lugar para sa mga lihim.

Ang pagpapatakbo ng utos gamit ang sudo ay hindi ginagawang walang pagmamatyag ang interactive na pag-login. Binabago nito ang epektibong user, hindi ang pagkakaroon ng GUI prompt, hardware token o login keychain. Maaaring magsimula ang LaunchAgent ng serbisyo pagkatapos mag-login ng user at ma-unlock ang keychain; kadalasan ay hindi naaabot ng LaunchDaemon ang mga bahaging iyon ng session ng user. Kung pinamamahalaan ng isang organisasyon ang serbisyo, ang mga tuntunin ng life cycle nito ay nangingibabaw sa anumang lokal na script.

Ihinto ang serbisyo at tiyakin na nanatiling naka-stop

Ihinto gamit ang parehong tagapili na ginamit mo sa pagsisimula, pagkatapos ay basahin muli ang estado sa halip na ipagpalagay na nawala na ang tunnel:

scutil --nc stop "Office VPN"
scutil --nc status "Office VPN"

Ang paghinto na bumabalik sa Disconnected ay nag-iiwan pa rin ng isang bagay na dapat suriin: kung ang profile ay nakatakda na kumonekta kapag hiniling, na maaaring magbalik nito nang wala ang iyong script. Kung may ruta ang ibang kliyente sa parehong Mac, ang mga rutang iyon ay maaaring makaligtas sa native na paghinto. Muling suriin ang ruta bago mo tapusin na nasa labas ng VPN ang makina.

Para sa wrapper na patakbuhin mo nang manu-mano, panatilihing maayos ang pagkakasunod-sunod: listahan, estado, simula, pagsisiyasat, pagsubok ng ruta, paghinto, pagpapatunay. Huwag i-parse ang palakaibigang pangalan mula sa malayang output kapag may identifier, at huwag ituring na kahandaan ang exit ng utos ng pagsisimula. Iniuulat ng tagapamahala ng koneksyon ang estado; ang patunay mo ay ang estado at isang rutang tumuturo sa tunnel.