VPN bejelentkezés előtt macOS-en: feloldás, bejelentkező ablak, munkamenet

Itt egy hiedelem, amely egy hétbe kerül: hogy a Macnek egyetlen pillanata van, amelyet bejelentkezés előttnek neveznek, és hogy a VPN kliens vagy akkor indul, vagy nem. A gépnek valójában legalább három pillanata van, amikor a hálózati hozzáférés számít, és ezeket az választja el, hogy abban a pontban ki jogosult hitelesítő adatokat tartani. A bejelentkezési elemként indított kliens pontosan egyet fed le közülük, és az az utolsó.

A mítosz, hogy egyetlen beállítás lefedi a teljes indítást

Olvassa újra a termékoldalt, és keresse meg, melyik szakaszt nevezi meg a funkció. A bejelentkezéskor indítás feliratú jelölőnégyzet bejelentkezési elemet jelent, amely a felhasználói munkamenet létezése után fut. Az igény szerinti kapcsolódás feliratú jelölőnégyzet azt jelenti, hogy a kliens kapcsolatot nyit, amikor a forgalom egy szabálynak megfelel, ami továbbra is megköveteli, hogy a kliens és hitelesítő adatai elérhetők legyenek.

Egyik sem éri el az indítási folyamatot. Ez nem olyan korlátozás, amelyet a szállító elfelejtett eltávolítani; ez az, amit az operációs rendszer enged. A kötet feloldása előtt nincs futó rendszer, ahonnan klienst lehetne indítani, kijelentkezés után pedig a felhasználó titkai a munkamenettel távoznak. Két külön fal, és egyik sem hajol meg egy másik jelölőnégyzet előtt.

Ahogy szétválasztja a szakaszokat, az eredeti kérdés alakot vált. Ahelyett, hogy azt kérdezné, elindul-e a VPN bejelentkezés előtt, azt kérdezi, a három konkrét pillanat közül melyiknek kell működnie, és akkor felfedezi, hogy mindegyiknek más a tulajdonosa: a titkosítási réteg, a hálózati kiterjesztés vagy a felhasználói munkamenet.

Mi történik valójában az egyes szakaszokban

Az indítás egy titkosított kötettel kezdődik, amelyet fel kell oldani, mielőtt bármilyen általános célra használható rendszer létezne. Ez a feloldás korlátozott környezetben, korlátozott hitelesítő adatokkal történik, és az Apple egyértelműen dokumentálja, hogy a titkosított adatok érvényes feloldás nélkül elérhetetlenek maradnak.

Ezután jön a bejelentkező ablak, ahol a rendszer fut, de felhasználói munkamenet még nincs. A felhasználói környezetű kiterjesztés már befejeződött, ha a felhasználó kijelentkezett, és egy globális rendszerkiterjesztés még futhat, de futni nem ugyanaz, mint a VPN-jéhez szükséges hitelesítő adatokat tartani.

Aztán jön a munkamenet, ahol egy normál kliens olvashatja a bejelentkezési kulcskarika tartalmát, második tényezőt kérhet és alkalmazhatja a továbbított útvonalakat. A legtöbb funkció, amelyet az emberek bejelentkezés előttiként írnak le, valójában ez a szakasz, amely a munkamenet elején aktiválódik, nem előtte.

Miért nem tud bejelentkezni egy launch daemon egy távollévő felhasználó helyett

Az emelt jogosultság úgy tűnik, meg kellene oldania a problémát, és nem oldja meg. A launch daemon rendszerfolyamatként fut felhasználói munkamenet nélkül, így nincs feloldható kulcskarika, és nincs ember, aki válaszoljon egy kérésre. Tud socketet nyitni és fájlt olvasni; amit nem tud, az az, hogy a hitelesítő adatok tulajdonosává váljon. A jogosultság nem identitás, és pontosan itt keveredik a kettő.

Amit az emberek ebben a résben építenek, az egy jelszót tartalmazó szkript, ami rosszabb probléma annál, amivel kezdték.

A követelmény őszinte változata szűkebb. Ha a gépnek védett erőforrást kell elérnie, miközben senki sincs jelen, akkor az identitásnak, amelyet az az erőforrás elfogad, olyannak kell lennie, amelyet a gép személy nélkül is tud tartani: eszköztanúsítvány, hitelesítő adat a rendszer kulcskarikájában, vagy olyan fiók, amelynek második tényezője nem valakinek a zsebében lévő telefonra küldött értesítés. Tervezze meg ezt az identitást szándékosan, és a szakasz kérdése általában magától megválaszolódik.

A Windows bejelentkezés előtti funkciója nem vihető át

A Windowsnak van dokumentált bejelentkezés előtti hozzáférési mechanizmusa bizonyos távoli hozzáférési termékekhez, és a név jobban utazik, mint a képesség. A Windows telepítési útmutatójában leírt funkció semmit sem mond arról, hogy ugyanaz a szállító megvalósít-e megfelelőt macOS-en.

Kérjen olyan nyilatkozatot, amely lefedi a Mac hardverét, a macOS kiadását, a kliens verzióját és a ténylegesen használt hitelesítési módszert. Egy általános támogatási állítás nem elég, mert a működés és a nem működés közötti különbség gyakran e négy valamelyikében rejlik.

Ha a szállító nem tud válaszolni, az a válasz. Tervezze meg a munkamenet szakaszát, és dolgozzon ki alternatívát a felügyelet nélküli esetre, ahelyett hogy a telepítés során fedezné fel a rést.

Mit kérjen helyette

Írja le a követelményt a szakaszok nyelvén. Melyik erőforrás, kinek kell, milyen környezetben, és mekkora elfogadható késleltetéssel, amikor a kapcsolat még nincs meg?

Ha a válasz egy felhasználó, aki bejelentkezik, majd szüksége van az alagútra, az igény szerinti kapcsolódás és egy indítási elem elegendő és olcsó. Ha a válasz egy gép, amely éjszaka újraindul és jelentést kell adnia, a tervezéshez támogatott lemezfeloldási útvonalra, eszközidentitásra és olyan helyreállítási folyamatra van szükség, amely akkor is működik, ha a hálózat soha nem jön fel. Ha a válasz az alagúttól függő szervezeti bejelentkezés, akkor a bejelentkezési, identitás- és VPN-terveket együtt kell megépíteni, nem külön megvásárolni.

Az Apple FileVault dokumentációja a megfelelő kiindulópont a feloldási szakaszhoz. Minden, ami utána jön, kliens- és identitáskérdés, amelyet a szállító nyilatkozatának a vásárlás előtt kell eldöntenie.