Ето едно убеждение, което струва на хората една седмица: че Mac има един момент, наречен „преди вход“, и че VPN клиентът или стартира тогава, или не. Всъщност машината има поне три момента, в които достъпът до мрежата е важен, разделени от това кой има право да държи удостоверения в този момент. Клиент, стартиран от елемент за вход, покрива точно един от тях и това е последният.

Митът, че една настройка покрива цялото зареждане

Прочетете отново продуктовата страница и вижте кой етап назовава функцията. Отметка с надпис „стартиране при вход“ означава елемент за вход, който работи след като съществува потребителска сесия. Отметка с надпис „свързване при нужда“ означава, че клиентът отваря връзка, когато трафикът съвпадне с правило, което все още изисква клиентът и неговите удостоверения да са налични.

Нито едно от тях не стига до процеса на зареждане. Това не е ограничение, което доставчикът е забравил да премахне; това е, което операционната система позволява. Преди томът да бъде отключен, няма работеща система, от която да се стартира клиент, а след изход тайните на потребителя си тръгват със сесията. Две отделни стени и нито една не отстъпва пред друга отметка.

След като разделите етапите, първоначалният въпрос променя формата си. Вместо да питате дали VPN стартира преди вход, питате кой от три конкретни момента трябва да работи, и после откривате, че всеки има различен собственик: слоят за шифроване, мрежовото разширение или потребителската сесия.

Какво всъщност се случва на всеки етап

Зареждането започва със шифрован том, който трябва да бъде отключен, преди да има използваема система за каквато и да е обща работа. Това отключване става в ограничен контекст с ограничен набор удостоверения и Apple документира ясно, че шифрованите данни остават недостъпни без валидно отключване.

Следва прозорецът за вход, където системата работи, но потребителска сесия още няма. Разширение в потребителски контекст вече е приключило, ако потребителят е излязъл, а глобално системно разширение може все още да работи, но да работи не е същото като да държи удостоверенията, от които вашият VPN се нуждае.

После идва сесията, където нормален клиент може да прочете ключодържателя за вход, да поиска втори фактор и да приложи изпратени маршрути. Повечето функции, които хората описват като „преди вход“, всъщност са този етап, задействан рано в сесията, а не преди нея.

StageWhat it can useWhat it cannot do
FileVault unlockCredentials supplied at the console to unlock the volumeRun an ordinary VPN app or read a user keychain
Login windowSystem context, possibly a joined networkUse a user secret that only exists after login
User sessionLogin keychain, interactive MFA, full client featuresExist before the volume unlocks

Защо launch daemon не може да влезе вместо отсъстващ потребител

Повишените привилегии изглеждат като решение на проблема, но не са. Launch daemon работи като системен процес без потребителска сесия зад него, така че няма ключодържател за отключване и няма човек, който да отговори на подкана. Той може да отвори сокет и да прочете файл; това, което не може, е да стане потребителят, който притежава удостоверенията. Привилегията не е идентичност и точно тук двете се объркват.

Това, което хората строят в тази празнина, е скрипт с парола вътре, а това е по-лош проблем от този, с който са започнали.

Честната версия на изискването е по-тесна. Ако машината трябва да достигне до защитен ресурс, докато няма никой, идентичността, която този ресурс приема, трябва да бъде такава, която машината може да поддържа без човек: сертификат на устройство, удостоверение в системния ключодържател или акаунт, чийто втори фактор не е известие до телефон в нечий джоб. Проектирайте тази идентичност умишлено и въпросът за етапа обикновено се решава сам.

Функцията на Windows „преди вход“ не се пренася

Windows има документиран механизъм за достъп преди вход за някои продукти за достъп от разстояние и името пътува по-добре от способността. Функция, описана в ръководство за внедряване на Windows, не ви казва нищо за това дали същият доставчик реализира еквивалент на macOS.

Поискайте становище, обхващащо хардуера на Mac, версията на macOS, версията на клиента и метода за удостоверяване, който действително използвате. Общо твърдение за поддръжка не е достатъчно, защото разликата между работещо и неработещо често се крие в едно от тези четири.

Ако доставчикът не може да отговори, това е отговорът. Планирайте етапа на сесията и проектирайте алтернатива за случая без присъствие, вместо да откривате празнината по време на внедряването.

Какво да поискате вместо това

Напишете изискването на езика на етапите. Кой ресурс, нужен на кого, в какъв контекст и с какво допустимо закъснение, когато връзката още я няма?

Ако отговорът е потребител, който влиза и след това се нуждае от тунела, свързване при нужда и елемент за стартиране са достатъчни и евтини. Ако отговорът е машина, която се рестартира през нощта и трябва да докладва, проектът се нуждае от поддържан път за отключване на диска, идентичност на устройството и процес за възстановяване, който работи, когато мрежата така и не се появи. Ако отговорът е вход в организация, който зависи от тунела, тогава проектите за вход, идентичност и VPN трябва да се изградят заедно, а не да се купуват поотделно.

Документацията на Apple за FileVault е правилната отправна точка за етапа на отключване. Всичко след нея е въпрос за клиент и идентичност, който становище на доставчика трябва да реши преди покупка.

Подобни статии