VPN до входу в систему на macOS: розблокування, вікно входу, сеанс
Розблокування FileVault, вікно входу та сеанс користувача — окремі етапи. Клієнт для робочого столу, що запускається під час входу, вирішує лише останній із них.
Ось переконання, яке коштує людям тижня: що Mac має єдиний момент під назвою до входу і що клієнт VPN або запускається тоді, або ні. Насправді машина має щонайменше три моменти, коли доступ до мережі важливий, і їх розділяє те, кому в цей момент дозволено тримати облікові дані. Клієнт, запущений з елемента входу, покриває рівно один із них, і це останній.
Міф про те, що одне налаштування покриває все завантаження
Перечитайте сторінку продукту і подивіться, який етап називає функція. Прапорець із написом запускати під час входу означає елемент входу, який працює після появи сеансу користувача. Прапорець із написом підключатися на вимогу означає, що клієнт відкриває з'єднання, коли трафік відповідає правилу, а це все ще потребує доступності клієнта та його облікових даних.
Жодне з них не досягає процесу завантаження. Це не обмеження, яке постачальник забув прибрати; це те, що дозволяє операційна система. До розблокування тому немає працюючої системи, з якої можна запустити клієнт, а після виходу секрети користувача йдуть разом із сеансом. Дві окремі стіни, і жодна не поступається іншому прапорцю.
Щойно ви розділите етапи, початкове питання змінює форму. Замість того щоб питати, чи запускається VPN до входу, ви питаєте, який із трьох конкретних моментів має працювати, і потім виявляєте, що кожен має іншого власника: стек шифрування, мережеве розширення або сеанс користувача.
Що насправді відбувається на кожному етапі
Завантаження починається із зашифрованого тому, який треба розблокувати до появи системи, придатної для будь-якої загальної роботи. Це розблокування відбувається в обмеженому контексті з обмеженим набором облікових даних, і Apple ясно документує, що зашифровані дані залишаються недоступними без дійсного розблокування.
Далі з'являється вікно входу, де система працює, але сеансу користувача ще немає. Розширення в контексті користувача вже завершилося, якщо користувач вийшов, а глобальне системне розширення може ще працювати, але працювати не те саме, що тримати облікові дані, потрібні вашому VPN.
Потім настає сеанс, де звичайний клієнт може прочитати зв'язку ключів входу, попросити другий фактор і застосувати передані маршрути. Більшість функцій, які люди описують як до входу, насправді цей етап, запущений на початку сеансу, а не до нього.
| 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 |
Чому launch daemon не може увійти за відсутнього користувача
Підвищені привілеї здаються вирішенням проблеми, але ними не є. Launch daemon працює як системний процес без сеансу користувача за ним, тому немає що розблоковувати і немає кому відповісти на запит. Він може відкрити сокет і прочитати файл; чого він не може — стати користувачем, якому належать облікові дані. Привілей не є ідентичністю, і саме тут ці двоє плутаються.
Те, що люди будують у цій прогалині, — скрипт із паролем усередині, а це проблема гірша за ту, з якої вони почали.
Чесна версія вимоги вужча. Якщо машина має досягти захищеного ресурсу, поки нікого немає, ідентичність, яку приймає цей ресурс, має бути такою, яку машина може тримати без людини: сертифікат пристрою, облікові дані в системній зв'язці ключів або обліковий запис, другий фактор якого не є сповіщенням на телефон у чиїйсь кишені. Проєктуйте цю ідентичність свідомо, і питання про етап зазвичай відповідає саме собі.
Функція Windows до входу не переноситься
Windows має документований механізм доступу до входу для деяких продуктів віддаленого доступу, і назва подорожує краще за можливість. Функція, описана в посібнику з розгортання Windows, нічого не говорить про те, чи реалізує той самий постачальник еквівалент на macOS.
Запросіть заяву, що охоплює обладнання Mac, версію macOS, версію клієнта та метод автентифікації, який ви справді використовуєте. Загального твердження про підтримку недостатньо, бо різниця між працюючим і непрацюючим часто криється в одному з цих чотирьох.
Якщо постачальник не може відповісти, це і є відповідь. Плануйте етап сеансу і проєктуйте альтернативу для випадку без присутності, а не виявляйте прогалину під час розгортання.
Що просити натомість
Напишіть вимогу мовою етапів. Який ресурс, кому потрібен, у якому контексті і з якою прийнятною затримкою, коли з'єднання ще немає?
Якщо відповідь — користувач, який входить і потім потребує тунелю, підключення на вимогу та елемент запуску достатні й недорогі. Якщо відповідь — машина, що перезавантажується вночі і має звітувати, проєкту потрібні підтримуваний шлях розблокування диска, ідентичність пристрою та процес відновлення, який працює, коли мережа так і не піднімається. Якщо відповідь — вхід в організацію, що залежить від тунелю, то проєкти входу, ідентичності й VPN треба будувати разом, а не купувати окремо.
Документація Apple щодо FileVault — правильна відправна точка для етапу розблокування. Усе після цього — питання клієнта та ідентичності, яке заява постачальника має вирішити до покупки.