VPN prieš prisijungimą „macOS“: atrakinimas, prisijungimo langas, sesija
„FileVault“ atrakinimas, prisijungimo langas ir naudotojo sesija yra atskiri etapai. Darbalaukio klientas, paleidžiamas prisijungiant, išsprendžia tik paskutinį jų.
Štai įsitikinimas, kuris žmones kainuoja savaitę: kad „Mac“ turi vieną momentą, vadinamą prieš prisijungimą, ir kad VPN klientas arba tada startuoja, arba ne. Iš tikrųjų įrenginyje yra bent trys momentai, kai tinklo prieiga svarbi, ir juos skiria tai, kam tuo metu leidžiama laikyti prisijungimo duomenis. Klientas, paleistas iš prisijungimo elemento, apima lygiai vieną iš jų, ir tai paskutinis.
Mitas, kad vienas nustatymas apima visą įkrovimą
Dar kartą perskaitykite produkto puslapį ir pažiūrėkite, kurį etapą įvardija funkcija. Žymimasis laukelis „paleisti prisijungiant“ reiškia prisijungimo elementą, kuris veikia po to, kai egzistuoja naudotojo sesija. Žymimasis laukelis „jungtis pagal poreikį“ reiškia, kad klientas atidaro ryšį, kai srautas atitinka taisyklę, o tam vis tiek reikia, kad klientas ir jo prisijungimo duomenys būtų prieinami.
Nė vienas iš jų nepasiekia įkrovimo proceso. Tai ne apribojimas, kurį tiekėjas pamiršo pašalinti; tai, ką leidžia operacinė sistema. Kol tomas neatrakintas, nėra veikiančios sistemos, iš kurios paleisti klientą, o po atsijungimo naudotojo paslaptys išeina su sesija. Dvi atskiros sienos, ir nė viena nepasiduoda kitam laukeliui.
Kai atskiriate etapus, pradinis klausimas keičia formą. Užuot klausę, ar VPN startuoja prieš prisijungimą, klausiate, kuris iš trijų konkrečių momentų turi veikti, ir tada atrandate, kad kiekvienas turi kitą savininką: šifravimo sluoksnis, tinklo plėtinys arba naudotojo sesija.
Kas iš tikrųjų vyksta kiekviename etape
Įkrovimas prasideda užšifruotu tomu, kurį reikia atrakinti prieš atsirandant bet kokiam bendram darbui tinkamai sistemai. Tas atrakinimas vyksta ribotame kontekste su ribotu prisijungimo duomenų rinkiniu, ir „Apple“ aiškiai dokumentuoja, kad užšifruoti duomenys lieka neprieinami be galiojančio atrakinimo.
Toliau ateina prisijungimo langas, kuriame sistema veikia, bet naudotojo sesijos dar nėra. Naudotojo konteksto plėtinys jau pasibaigė, jei naudotojas atsijungė, o globalus sistemos plėtinys gali dar veikti, bet veikti nėra tas pats, kas laikyti prisijungimo duomenis, kurių reikia jūsų VPN.
Tada ateina sesija, kurioje įprastas klientas gali perskaityti prisijungimo raktų rinkinį, paprašyti antrojo faktoriaus ir pritaikyti stumiamus maršrutus. Dauguma funkcijų, kurias žmonės apibūdina kaip prieš prisijungimą, iš tikrųjų yra šis etapas, suaktyvintas sesijos pradžioje, o ne prieš ją.
| 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 |
Kodėl „launch daemon“ negali prisijungti už nesančio naudotojo
Padidintos privilegijos atrodo turėtų išspręsti problemą, bet neišsprendžia. „launch daemon“ veikia kaip sistemos procesas be naudotojo sesijos, todėl nėra raktų rinkinio, kurį atrakinti, ir nėra žmogaus, kuris atsakytų į užklausą. Jis gali atidaryti lizdą ir perskaityti failą; ko negali, tai tapti naudotoju, kuriam priklauso prisijungimo duomenys. Privilegija nėra tapatybė, ir būtent čia šie du dalykai sumaišomi.
Tai, ką žmonės stato toje spragoje, yra scenarijus su slaptažodžiu viduje, o tai yra blogesnė problema nei ta, su kuria jie pradėjo.
Sąžininga reikalavimo versija yra siauresnė. Jei įrenginys turi pasiekti apsaugotą išteklių, kai niekas nėra, tapatybė, kurią tas išteklius priima, turi būti tokia, kurią įrenginys gali išlaikyti be žmogaus: įrenginio sertifikatas, prisijungimo duomuo sistemos raktų rinkinyje arba paskyra, kurios antrasis faktorius nėra pranešimas į telefoną kažkieno kišenėje. Suprojektuokite tą tapatybę sąmoningai, ir etapo klausimas paprastai atsako pats.
„Windows“ funkcija prieš prisijungimą neperkeliama
„Windows“ turi dokumentuotą prieigos prieš prisijungimą mechanizmą kai kuriems nuotolinės prieigos produktams, ir pavadinimas keliauja geriau nei galimybė. Funkcija, aprašyta „Windows“ diegimo vadove, nieko nesako apie tai, ar tas pats tiekėjas įgyvendina atitikmenį „macOS“.
Paprašykite pareiškimo, apimančio „Mac“ aparatinę įrangą, „macOS“ leidimą, kliento versiją ir autentifikavimo metodą, kurį iš tikrųjų naudojate. Bendras palaikymo teiginys nepakanka, nes skirtumas tarp veikiančio ir neveikiančio dažnai slypi viename iš tų keturių.
Jei tiekėjas negali atsakyti, tai ir yra atsakymas. Planuokite sesijos etapą ir suprojektuokite alternatyvą atvejui be priežiūros, o ne atraskite spragą diegimo metu.
Ko prašyti vietoj to
Parašykite reikalavimą etapų kalba. Kuris išteklius, kam reikalingas, kokiame kontekste ir su kokiu priimtinu delsimu, kai ryšio dar nėra?
Jei atsakymas yra naudotojas, kuris prisijungia ir tada jam reikia tunelio, jungtis pagal poreikį ir paleidimo elementas yra pakankami ir pigūs. Jei atsakymas yra įrenginys, kuris naktį persikrauna ir turi atsiskaityti, projektui reikia palaikomo disko atrakinimo kelio, įrenginio tapatybės ir atkūrimo proceso, kuris veikia, kai tinklas niekada nepakyla. Jei atsakymas yra organizacijos prisijungimas, priklausantis nuo tunelio, tada prisijungimo, tapatybės ir VPN projektai turi būti statomi kartu, o ne perkami atskirai.
„Apple“ „FileVault“ dokumentacija yra tinkamas atspirties taškas atrakinimo etapui. Viskas, kas ateina po to, yra kliento ir tapatybės klausimas, kurį tiekėjo pareiškimas turėtų išspręsti prieš perkant.