VPN antaŭ ensaluto en macOS: malŝloso, ensaluta fenestro, sesio
La malŝloso de FileVault, la ensaluta fenestro kaj uzanta sesio estas apartaj etapoj. Labortabla kliento, kiu startas ĉe ensaluto, solvas nur la lastan el ili.
Jen kredo, kiu kostas al homoj semajnon: ke Mac havas unu momenton nomatan antaŭ ensaluto, kaj ke VPN-kliento aŭ startas tiam aŭ ne. La maŝino efektive havas almenaŭ tri momentojn, kiam reta aliro gravas, apartigitajn per tio, kiu rajtas teni legitimilojn en tiu punkto. Kliento lanĉita el ensaluta ero kovras precize unu el ili, kaj ĝi estas la lasta.
La mito, ke unu agordo kovras la tutan praŝargon
Relutu la produktan paĝon kaj serĉu, kiun etapon la trajto nomas. Markobutono nomata starti ĉe ensaluto signifas ensalutan eron, kiu ruliĝas post kiam uzanta sesio ekzistas. Markobutono nomata konekti laŭbezone signifas, ke la kliento malfermas konekton, kiam trafiko kongruas kun regulo, kio ankoraŭ postulas, ke la kliento kaj ĝiaj legitimiloj estu disponeblaj.
Neniu el tiuj atingas la praŝargan procezon. Tio ne estas limigo, kiun la vendisto forgesis forigi; ĝi estas tio, kion la operaciumo permesas. Antaŭ ol la volumo estas malŝlosita, mankas ruliĝanta sistemo, el kiu lanĉi klienton, kaj post elsaluto la sekretoj de la uzanto foriras kun la sesio. Du apartaj muroj, kaj neniu el ili cedas al alia markobutono.
Kiam vi apartigas la etapojn, la originala demando ŝanĝas formon. Anstataŭ demandi, ĉu la VPN startas antaŭ ensaluto, vi demandas, kiun el tri konkretaj momentoj devas funkcii, kaj tiam vi malkovras, ke ĉiu havas alian posedanton: la ĉifrada stako, la reta etendaĵo aŭ la uzanta sesio.
Kio efektive okazas en ĉiu etapo
Praŝargo komenciĝas per ĉifrita volumo, kiun oni devas malŝlosi antaŭ ol ekzistas uzebla sistemo por io ajn ĝenerala. Tiu malŝloso okazas en limigita kunteksto kun limigita aro de legitimiloj, kaj Apple klare dokumentas, ke ĉifritaj datumoj restas neatingeblaj sen valida malŝloso.
Poste venas la ensaluta fenestro, kie la sistemo ruliĝas sed uzanta sesio ankoraŭ ne ekzistas. Etendaĵo en uzanta kunteksto jam finiĝis, se la uzanto elsalutis, kaj tutmonda sistema etendaĵo eble ankoraŭ ruliĝas, sed ruliĝi ne samas kiel teni la legitimilojn, kiujn via VPN bezonas.
Tiam venas la sesio, kie normala kliento povas legi la ensalutan ŝlosilaron, peti duan faktoron kaj apliki puŝitajn itinerojn. Plej multaj trajtoj, kiujn homoj priskribas kiel antaŭ ensaluto, efektive estas ĉi tiu etapo, ekigita frue en la sesio kaj ne antaŭ ĝi.
| Stage | What it can use | What it cannot do |
|---|---|---|
| FileVault unlock | Credentials supplied at the console to unlock the volume | Run an ordinary VPN app or read a user keychain |
| Login window | System context, possibly a joined network | Use a user secret that only exists after login |
| User session | Login keychain, interactive MFA, full client features | Exist before the volume unlocks |
Kial launch daemon ne povas ensaluti por forestanta uzanto
Altigita privilegio ŝajnas, ke ĝi solvus la problemon, kaj ĝi ne solvas. Launch daemon ruliĝas kiel sistema procezo sen uzanta sesio malantaŭ ĝi, do mankas ŝlosilaro por malŝlosi kaj homo por respondi al peto. Ĝi povas malfermi ingon kaj legi dosieron; kion ĝi ne povas, estas fariĝi la uzanto, kiu posedas la legitimilojn. Privilegio ne estas identeco, kaj ĝuste ĉi tie la du konfuziĝas.
Kion homoj konstruas en tiu breĉo estas skripto kun pasvorto ene, kio estas pli malbona problemo ol tiu, kun kiu ili komencis.
La honesta versio de la postulo estas pli mallarĝa. Se la maŝino devas atingi protektitan rimedon dum neniu ĉeestas, tiam la identeco, kiun tiu rimedo akceptas, devas esti tia, kiun la maŝino povas teni sen persono: aparata atestilo, legitimilo en la sistema ŝlosilaro aŭ konto, kies dua faktoro ne estas puŝo al telefono en ies poŝo. Projektu tiun identecon intence, kaj la demando pri la etapo kutime respondas sin mem.
La Windows-traĵto antaŭ ensaluto ne transiĝas
Windows havas dokumentitan alirmekanismon antaŭ ensaluto por kelkaj foraĵaj produktoj, kaj la nomo vojaĝas pli bone ol la kapablo. Trajto priskribita en Windows-enkonduka gvidilo diras al vi nenion pri tio, ĉu la sama vendisto realigas ekvivalenton en macOS.
Petu deklaron pri la Mac-aparataro, la macOS-eldono, la klienta versio kaj la aŭtentiga metodo, kiun vi efektive uzas. Ĝenerala aserto pri subteno ne sufiĉas, ĉar la diferenco inter funkcii kaj ne funkcii ofte kuŝas en unu el tiuj kvar.
Se la vendisto ne povas respondi, tio estas la respondo. Planu la etapon de la sesio kaj projektu alternativon por la senhoma kazo, anstataŭ malkovri la breĉon dum enkonduko.
Kion peti anstataŭe
Skribu la postulon en la lingvo de la etapoj. Kiu rimedo, bezonata de kiu, en kiu kunteksto kaj kun kiu akceptebla prokrasto, kiam la konekto ankoraŭ mankas?
Se la respondo estas uzanto, kiu ensalutas kaj poste bezonas la tunelon, konekti laŭbezone kaj starta ero sufiĉas kaj malmultekostas. Se la respondo estas maŝino, kiu relanĉiĝas nokte kaj devas raporti, la projekto bezonas subtenatan diskmalŝlosan vojon, aparatan identecon kaj reakiran procezon, kiu funkcias, kiam la reto neniam leviĝas. Se la respondo estas organiza ensaluto dependa de la tunelo, tiam la projektoj de ensaluto, identeco kaj VPN devas esti konstruitaj kune, ne aĉetitaj aparte.
La dokumentaro de Apple pri FileVault estas la ĝusta komenca punkto por la etapo de malŝloso. Ĉio post tio estas demando pri kliento kaj identeco, kiun deklaro de la vendisto devus solvi antaŭ ol vi aĉetas.