VPN przed logowaniem w macOS: odblokowanie, okno logowania, sesja
Odblokowanie FileVault, okno logowania i sesja użytkownika to osobne etapy. Klient pulpitu uruchamiany przy logowaniu rozwiązuje tylko ostatni z nich.
Oto przekonanie, które kosztuje ludzi tydzień: że Mac ma jeden moment zwany przed logowaniem i że klient VPN albo wtedy startuje, albo nie. Maszyna ma w rzeczywistości co najmniej trzy momenty, w których dostęp do sieci ma znaczenie, rozdzielone przez to, kto w danym punkcie może trzymać poświadczenia. Klient uruchomiony z elementu logowania obejmuje dokładnie jeden z nich i jest to ostatni.
Mit, że jedno ustawienie obejmuje cały rozruch
Przeczytaj ponownie stronę produktu i sprawdź, który etap nazywa funkcja. Pole wyboru z etykietą uruchom przy logowaniu oznacza element logowania, który działa po powstaniu sesji użytkownika. Pole wyboru z etykietą połącz na żądanie oznacza, że klient otwiera połączenie, gdy ruch pasuje do reguły, co nadal wymaga dostępności klienta i jego poświadczeń.
Żadne z nich nie sięga procesu rozruchu. To nie ograniczenie, o którym dostawca zapomniał usunąć; to jest to, na co pozwala system operacyjny. Zanim wolumin zostanie odblokowany, nie ma działającego systemu, z którego można uruchomić klienta, a po wylogowaniu sekrety użytkownika odchodzą z sesją. Dwie osobne ściany i żadna nie ustępuje innemu polu wyboru.
Gdy rozdzielisz etapy, pierwotne pytanie zmienia kształt. Zamiast pytać, czy VPN startuje przed logowaniem, pytasz, który z trzech konkretnych momentów musi działać, i wtedy odkrywasz, że każdy ma innego właściciela: stos szyfrowania, rozszerzenie sieciowe albo sesję użytkownika.
Co faktycznie dzieje się na każdym etapie
Rozruch zaczyna się zaszyfrowanym woluminem, który trzeba odblokować, zanim powstanie system nadający się do czegokolwiek ogólnego. To odblokowanie odbywa się w ograniczonym kontekście z ograniczonym zestawem poświadczeń, a Apple jasno dokumentuje, że zaszyfrowane dane pozostają niedostępne bez ważnego odblokowania.
Następnie pojawia się okno logowania, w którym system działa, ale sesji użytkownika jeszcze nie ma. Rozszerzenie w kontekście użytkownika już się zakończyło, jeśli użytkownik się wylogował, a globalne rozszerzenie systemowe może nadal działać, ale działanie to nie to samo co trzymanie poświadczeń potrzebnych twojemu VPN.
Potem przychodzi sesja, w której zwykły klient może odczytać pęk kluczy logowania, poprosić o drugi czynnik i zastosować wypchnięte trasy. Większość funkcji, które ludzie opisują jako przed logowaniem, to w rzeczywistości ten etap, uruchamiany wcześnie w sesji, a nie przed nią.
| 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 |
Dlaczego launch daemon nie może zalogować się za nieobecnego użytkownika
Podniesione uprawnienia wydają się rozwiązywać problem, ale go nie rozwiązują. Launch daemon działa jako proces systemowy bez sesji użytkownika za sobą, więc nie ma pęku kluczy do odblokowania ani człowieka, który odpowie na prośbę. Może otworzyć gniazdo i odczytać plik; tym, czego nie może, jest stanięcie się użytkownikiem, do którego należą poświadczenia. Uprawnienie to nie tożsamość i dokładnie w tym miejscu oba się mylą.
To, co ludzie budują w tej luce, to skrypt z hasłem w środku, co jest gorszym problemem niż ten, z którym zaczęli.
Uczciwa wersja wymagania jest węższa. Jeśli maszyna musi dotrzeć do chronionego zasobu, gdy nikogo nie ma, tożsamość akceptowana przez ten zasób musi być taka, którą maszyna może utrzymać bez osoby: certyfikat urządzenia, poświadczenie w pęku kluczy systemu albo konto, którego drugim czynnikiem nie jest powiadomienie push na telefon w czyjejś kieszeni. Zaprojektuj tę tożsamość świadomie, a pytanie o etap zwykle odpowiada samo.
Funkcja Windows przed logowaniem nie przenosi się
Windows ma udokumentowany mechanizm dostępu przed logowaniem dla niektórych produktów zdalnego dostępu, a nazwa podróżuje lepiej niż zdolność. Funkcja opisana w przewodniku wdrożeniowym Windows nie mówi nic o tym, czy ten sam dostawca implementuje odpowiednik w macOS.
Poproś o oświadczenie obejmujące sprzęt Maca, wydanie macOS, wersję klienta i metodę uwierzytelniania, której naprawdę używasz. Ogólne twierdzenie o wsparciu nie wystarcza, bo różnica między działaniem a niedziałaniem często leży w jednym z tych czterech.
Jeśli dostawca nie potrafi odpowiedzieć, to jest odpowiedź. Zaplanuj etap sesji i zaprojektuj alternatywę dla przypadku bez nadzoru, zamiast odkrywać lukę podczas wdrożenia.
O co prosić zamiast tego
Napisz wymaganie językiem etapów. Który zasób, komu potrzebny, w jakim kontekście i z jakim akceptowalnym opóźnieniem, gdy połączenia jeszcze nie ma?
Jeśli odpowiedzią jest użytkownik, który się loguje, a potem potrzebuje tunelu, połączenie na żądanie i element startowy wystarczą i są tanie. Jeśli odpowiedzią jest maszyna, która restartuje się w nocy i musi raportować, projekt potrzebuje obsługiwanej ścieżki odblokowania dysku, tożsamości urządzenia i procesu odzyskiwania, który działa, gdy sieć nigdy nie wstaje. Jeśli odpowiedzią jest logowanie organizacji zależne od tunelu, to projekty logowania, tożsamości i VPN trzeba zbudować razem, a nie kupować osobno.
Dokumentacja FileVault firmy Apple to właściwy punkt wyjścia dla etapu odblokowania. Wszystko po nim to kwestia klienta i tożsamości, którą oświadczenie dostawcy powinno rozstrzygnąć przed zakupem.