VPN bago mag-log in sa macOS: pag-unlock, window ng login, sesyon

Narito ang isang paniniwala na nagkakahalaga ng isang linggo: na ang Mac ay may isang sandali na tinatawag na bago mag-log in at ang VPN client ay nagsisimula noon o hindi. Sa totoo lang, ang makina ay may hindi bababa sa tatlong sandali kung saan mahalaga ang pag-access sa network, na pinaghihiwalay ng kung sino ang pinapayagang humawak ng mga kredensyal sa puntong iyon. Ang client na inilunsad mula sa isang item ng login ay sumasaklaw nang eksakto sa isa sa kanila, at ito ang huli.

Ang mito na ang isang setting ay sumasaklaw sa buong boot

Basahin muli ang pahina ng produkto at tingnan kung aling yugto ang pinangalanan ng tampok. Ang check box na may label na simulan sa login ay nangangahulugang item ng login, na tumatakbo pagkatapos na umiral ang sesyon ng user. Ang check box na may label na kumonekta kapag kinakailangan ay nangangahulugang binubuksan ng client ang isang koneksyon kapag tumugma ang trapiko sa isang tuntunin, na nangangailangan pa rin na ang client at ang mga kredensyal nito ay available.

Wala sa dalawa ang nakararating sa proseso ng boot. Hindi ito limitasyong nakalimutang alisin ng vendor; ito ang pinapayagan ng operating system. Bago ma-unlock ang volume ay walang tumatakbong system na mapaglulunsaran ng client, at pagkatapos ng logout ay umaalis ang mga lihim ng user kasama ng sesyon. Dalawang magkahiwalay na pader, at walang isa ang yumuyuko sa ibang check box.

Kapag pinaghiwalay mo ang mga yugto, nagbabago ang hugis ng orihinal na tanong. Sa halip na itanong kung nagsisimula ang VPN bago mag-log in, itatanong mo kung alin sa tatlong partikular na sandali ang dapat gumana, at pagkatapos ay matuklasan mong may ibang may-ari ang bawat isa: ang stack ng encryption, ang extension ng network o ang sesyon ng user.

Ano ang aktwal na nangyayari sa bawat yugto

Nagsisimula ang boot sa isang naka-encrypt na volume na dapat i-unlock bago umiral ang isang system na magagamit para sa anumang pangkalahatang gawain. Ang pag-unlock na iyon ay nangyayari sa limitadong konteksto na may limitadong hanay ng mga kredensyal, at malinaw na itinatala ng Apple na ang naka-encrypt na data ay nananatiling hindi ma-access nang walang wastong pag-unlock.

Pagkatapos ay dumarating ang window ng login, kung saan tumatakbo ang system ngunit wala pang sesyon ng user. Ang extension sa konteksto ng user ay natapos na kung nag-log out ang user, at ang pandaigdigang system extension ay maaaring tumatakbo pa, ngunit ang pagtakbo ay hindi katulad ng paghawak sa mga kredensyal na kailangan ng iyong VPN.

Pagkatapos ay dumarating ang sesyon, kung saan ang isang normal na client ay maaaring basahin ang keychain ng login, humiling ng pangalawang salik at ilapat ang mga itinulak na ruta. Karamihan sa mga tampok na inilalarawan ng mga tao bilang bago mag-log in ay talagang ang yugtong ito, na na-trigger sa simula ng sesyon at hindi bago ito.

Bakit hindi makapag-log in ang isang launch daemon para sa isang user na wala

Ang mataas na pribilehiyo ay tila dapat lutasin ang problema, at hindi ito nilulutas. Ang launch daemon ay tumatakbo bilang proseso ng system na walang sesyon ng user sa likod nito, kaya walang keychain na i-unlock at walang tao na sasagot sa isang kahilingan. Maaari nitong buksan ang isang socket at basahin ang isang file; ang hindi nito magagawa ay maging ang user na nagmamay-ari ng mga kredensyal. Ang pribilehiyo ay hindi pagkakakilanlan, at dito mismo napagbabaliktad ang dalawa.

Ang itinatayo ng mga tao sa puwang na iyon ay isang script na may password sa loob, na isang mas malubhang problema kaysa sa sinimulan nila.

Ang tapat na bersyon ng pangangailangan ay mas makitid. Kung kailangang maabot ng makina ang isang protektadong mapagkukunan habang walang tao, ang pagkakakilanlan na tinatanggap ng mapagkukunang iyon ay dapat isa na kayang hawakan ng makina nang walang tao: isang sertipiko ng device, isang kredensyal sa keychain ng system o isang account na ang pangalawang salik ay hindi isang push sa isang telepono sa bulsa ng isang tao. Disenyuhin ang pagkakakilanlang iyon nang sadya, at ang tanong ng yugto ay kadalasang sumasagot sa sarili nito.

Ang tampok ng Windows bago mag-log in ay hindi naililipat

Ang Windows ay may dokumentadong mekanismo ng pag-access bago mag-log in para sa ilang produkto ng remote access, at ang pangalan ay naglalakbay nang mas mahusay kaysa sa kakayahan. Ang isang tampok na inilarawan sa isang gabay sa deployment ng Windows ay walang sinasabi tungkol sa kung ang parehong vendor ay nagpapatupad ng katumbas sa macOS.

Humingi ng pahayag na sumasaklaw sa hardware ng Mac, release ng macOS, bersyon ng client at paraan ng pagpapatotoo na aktwal mong ginagamit. Ang pangkalahatang pag-aangkin ng suporta ay hindi sapat, dahil ang pagkakaiba sa pagitan ng gumagana at hindi gumagana ay madalas na nasa isa sa apat na iyon.

Kung hindi makasagot ang vendor, iyon ang sagot. Planuhin ang yugto ng sesyon at magdisenyo ng alternatibo para sa kaso na walang nagbabantay, sa halip na matuklasan ang puwang habang nagde-deploy.

Ano ang hihilingin sa halip

Isulat ang pangangailangan sa wika ng mga yugto. Aling mapagkukunan, kailangan ng sino, sa anong konteksto, at may anong katanggap-tanggap na pagkaantala kapag wala pa ang koneksyon?

Kung ang sagot ay isang user na nag-log in at pagkatapos ay kailangan ang tunnel, ang kumonekta kapag kinakailangan at isang startup item ay sapat at mura. Kung ang sagot ay isang makinang nag-reboot magdamag at kailangang mag-ulat, ang disenyo ay nangangailangan ng sinusuportahang landas ng pag-unlock ng disk, pagkakakilanlan ng device at proseso ng pagbawi na gumagana kapag hindi kailanman umangat ang network. Kung ang sagot ay login ng organisasyon na umaasa sa tunnel, kung gayon ang mga disenyo ng login, pagkakakilanlan at VPN ay dapat itayo nang magkasama at hindi bilhin nang hiwalay.

Ang dokumentasyon ng FileVault ng Apple ang tamang panimulang punto para sa yugto ng pag-unlock. Lahat ng sumusunod ay tanong ng client at pagkakakilanlan na dapat ayusin ng pahayag ng vendor bago ka bumili.