Sinisimulan ng iyong script ang VPN; hindi nito ito inihahanda

Nagsusulat ka ng script na nagpapatakbo ng scutil --nc start kasama ang pangalan ng koneksyon, gumagana ito sa iyong Mac, at nabigo ito sa bawat bagong install na makina sa opisina. Hindi sira ang script. Hinihingan ito ng isang bagay na hindi nito kayang gawin: ang pagsisimula ng umiiral na koneksyon ay hindi kaparehong operasyon ng paglikha ng bago.

Ang paghahanda at kontrol ng sesyon ay dalawang trabaho na may dalawang may-ari, at ang daloy ng trabaho na nagpapalagay ng kabaligtaran ay papasa sa bawat pagsubok sa makinang pinagsulatan nito.

Ano ang talagang kinakausap ng utos ng pagsisimula

Ang utos ng kontrol ng sesyon ay humaharap sa isang konfigurasyong umiiral na at aprubado na. Hinihiling nito sa sistema na itaas ang pinangalanang koneksyon, gamit ang mga setting ng server, mga reperensya ng pagkakakilanlan at patakaran na naitala noon. Kung ang mga iyon ay hindi kailanman na-install, walang masisimulan.

Kaya lumilitaw ang kabiguan sa bagong hardware at hindi sa laptop ng administrador. Ang laptop ay inihanda noong mga nakaraang buwan ng taong nakalimutan na niya iyon. Isipin ang utos ng pagsisimula na parang kampana ng pinto na kinabitan ng kawad ng isang tao noong nakaraang quarter. Ang pagpindot dito ay hindi katulad ng paglalagay ng mga kawad.

Tatlong may-ari ng isang konfigurasyon ng VPN

Ang profile na pinamamahalaan ng organisasyon ay nagmumula sa pamamahala ng device. Dinadala ng profile ang mga address ng server, ang kaayusan ng pagpapatunay at ang patakarang kailangan ng organisasyon, at ang administrador ng VPN ang taong nagbibigay ng mga ito. Hindi dapat buuin muli ng script ang mga setting na iyon mula sa display name na nakita nito sa isang listahan.

Ang native na personal na konfigurasyon ng VPN ay nililikha sa pamamagitan ng Network Extension API ng Apple, na sumasaklaw sa mga built-in na protocol na IPsec at IKEv2. Ito ay interface ng aplikasyon na may hakbang ng pag-save at pag-apruba ng user, hindi utos ng shell na tahimik na lumilikha ng anumang uri ng tunnel na ibinibigay ng vendor.

Ang kliyente ng third party ay ikatlong kaso na may sariling format ng pag-import, sariling tool sa pamamahala at kadalasan ay sariling privileged helper. Ang sesyon nito ay pag-aari ng proseso ng vendor na iyon. Ang makahanap ng serbisyo ng system na may katulad na pangalan ay hindi patunay na kinokontrol ng utos ng system ang tunnel, at ang pagpapalagay nito ay gumagawa ng mga script na tila gumagana hanggang i-update ng vendor ang kliyente.

Ang native na paghahanda ay may pag-save at pag-apruba

Ang modelo ng Apple ay i-load, baguhin, i-save. Naglo-load ang aplikasyon ng umiiral na mga kagustuhan bago ang unang pag-save nito pagkatapos ng paglulunsad, binabago ang konfigurasyon at pagkatapos ay ini-save ito. Nag-uulat ang pag-save ng error kapag hindi ito makapanatili, at ang pagwawalang-bahala sa resultang iyon ay ginagawang kabiguan ng koneksyon ang kabiguan ng paghahanda pagkalipas ng tatlong hakbang.

Ang unang pag-save ay nangangailangan din na aprubahan ng user ang aplikasyon. Iyon ay sadyang hangganan ng seguridad, at nangangahulugan ito na ang unang pagpapatakbo sa bagong Mac ay interaktibo kahit na ang bawat susunod na koneksyon at paghinto ay maaaring awtomatikin. Plano ang unang pagpapatakbo bilang gawaing pantao na may taong naroroon. Awtomatikin ang ikalawa at mga susunod na pagpapatakbo, at isulat iyon sa runbook para walang mangakong imposible. Ang plano ng deployment na nangangako ng ganap na walang pagmamatyag na unang pagpapatakbo ay nangangako ng bagay na hindi inaalok ng platform.

Inirerekomenda rin ng Apple ang pagpapatunay ng pagiging tugma ng server sa isang profile ng konfigurasyon bago umasa sa API. Ang paggawa ng pagsusuring iyon muna ay naghihiwalay ng «hindi tatanggapin ng server ang kliyenteng ito» mula sa «hindi kailanman nag-save ang kliyente ng mga setting», na magkaibang ticket para sa magkaibang team.

Ano ang maaaring ipalagay ng isang napepeat na utos ng pagsisimula

Pagkatapos ng paghahanda, maaaring ligtas na ituon ng script ang umiiral na koneksyon sa pamamagitan ng interface ng may-ari nito. Ibigay dito ang matatag na pagkakakilanlan ng koneksyon kasama ang aksyon na gusto mo, at wala nang iba. Hindi nito dapat basahin ang hinulaang landas ng kagustuhan, at hindi nito dapat ipalagay na ang pangalang nakikita sa menu ay natatangi sa buong system.

Para sa native na mga koneksyon, ang pinangalanang hiling ng sesyon tulad ng scutil --nc start ay operasyon ng kontrol. Hindi ito nag-i-install ng mga setting ng server, hindi nag-i-import ng mga kredensyal at hindi nagsasagawa ng awtorisasyon ng unang pag-save. Ituring ito bilang huling hakbang ng isang kadena, hindi kailanman bilang buong kadena.

Itago ang mga lihim sa labas ng mga argumento ng command line at sa labas ng ordinaryong diagnostic na output. Anuman ang mekanismo ng pagkakakilanlan na pinili ng deployment, iyon ang dapat asahan ng utos ng pagsisimula, at ang password na idinikit sa kasaysayan ng shell ay isang natuklasan sa anumang pagsusuri.

Dalawang pagsusuri ng pagtanggap

Ang unang pagsusuri ay ang paghahanda: kumuha ng bagong install na Mac at patunayang naroroon ang konfigurasyon, pag-aari ng tamang manager at ganap na aprubado. Gawin ito bago subukan ang konektibidad, dahil ang pagsubok ng koneksyon sa makina na hindi inihanda ay walang pinatutunayan tungkol sa script.

Ang ikalawang pagsusuri ay ang sesyon: kumonekta, maabot ang awtorisadong resource at humiwalay nang malinis. Bawat kabiguan ay may may-ari na, at iyon ang praktikal na pakinabang ng paghihiwalay ng dalawang trabaho. Ang nawawalang profile ay problema sa paghahatid, ang error sa pag-save ay problema sa pag-apruba, ang tinanggihang login ay problema sa pagpapatunay, at ang pag-timeout pagkatapos ng matagumpay na pagsisimula ay ang layer ng sesyon. Wala sa mga ito ang «sira ang script».