VPN înainte de autentificare pe macOS: deblocare, fereastră de autentificare, sesiune

Iată o convingere care costă pe cineva o săptămână: că un Mac are un singur moment numit înainte de autentificare și că un client VPN fie pornește atunci, fie nu. Mașina are de fapt cel puțin trei momente în care accesul la rețea contează, separate de cine are voie să dețină credențiale în acel punct. Un client lansat dintr-un element de autentificare acoperă exact unul dintre ele, și acela este ultimul.

Mitul că o singură setare acoperă întreaga pornire

Recitiți pagina produsului și căutați ce etapă numește funcția. O casetă etichetată pornește la autentificare înseamnă un element de autentificare, care rulează după ce există o sesiune de utilizator. O casetă etichetată conectează la cerere înseamnă că clientul deschide o conexiune când traficul corespunde unei reguli, ceea ce încă necesită ca clientul și credențialele sale să fie disponibile.

Niciuna dintre ele nu ajunge la procesul de pornire. Aceasta nu este o limitare pe care furnizorul a uitat să o elimine; este ceea ce permite sistemul de operare. Înainte ca volumul să fie deblocat nu există un sistem care rulează din care să lansezi un client, iar după deconectare secretele utilizatorului pleacă împreună cu sesiunea. Doi pereți separați, și niciunul nu cedează în fața altei casete.

Când separați etapele, întrebarea originală își schimbă forma. În loc să întrebați dacă VPN-ul pornește înainte de autentificare, întrebați care dintre cele trei momente concrete trebuie să funcționeze, apoi descoperiți că fiecare are alt proprietar: stiva de criptare, extensia de rețea sau sesiunea de utilizator.

Ce se întâmplă de fapt în fiecare etapă

Pornirea începe cu un volum criptat care trebuie deblocat înainte să existe un sistem utilizabil pentru orice scop general. Acea deblocare are loc într-un context restricționat, cu un set restricționat de credențiale, iar Apple documentează clar că datele criptate rămân inaccesibile fără o deblocare validă.

Apoi vine fereastra de autentificare, unde sistemul rulează dar nu există încă o sesiune de utilizator. O extensie în contextul utilizatorului s-a încheiat deja dacă utilizatorul s-a deconectat, iar o extensie globală de sistem poate încă rula, dar a rula nu este același lucru cu a deține credențialele de care are nevoie VPN-ul dumneavoastră.

Apoi vine sesiunea, unde un client normal poate citi brelocul de autentificare, cere un al doilea factor și aplica rutele împinse. Majoritatea funcțiilor pe care oamenii le descriu ca înainte de autentificare sunt de fapt această etapă, activată la începutul sesiunii și nu înaintea ei.

De ce un launch daemon nu se poate autentifica pentru un utilizator absent

Privilegiul ridicat pare că ar trebui să rezolve problema, și nu o rezolvă. Un launch daemon rulează ca proces de sistem fără o sesiune de utilizator în spate, deci nu există breloc de deblocat și nici o persoană care să răspundă unei cereri. Poate deschide un socket și poate citi un fișier; ceea ce nu poate este să devină utilizatorul care deține credențialele. Privilegiul nu este identitate, și exact aici cele două se confundă.

Ce construiesc oamenii în acel gol este un script cu o parolă înăuntru, ceea ce este o problemă mai rea decât cea cu care au început.

Versiunea onestă a cerinței este mai îngustă. Dacă mașina trebuie să atingă o resursă protejată în timp ce nimeni nu este prezent, identitatea pe care o acceptă acea resursă trebuie să fie una pe care mașina o poate deține fără o persoană: un certificat de dispozitiv, o credențială în brelocul sistemului sau un cont al cărui al doilea factor nu este o notificare push către un telefon din buzunarul cuiva. Proiectați acea identitate deliberat, iar întrebarea etapei de obicei răspunde singură.

Funcția Windows dinainte de autentificare nu se transferă

Windows are un mecanism documentat de acces înainte de autentificare pentru unele produse de acces la distanță, iar numele călătorește mai bine decât capacitatea. O funcție descrisă într-un ghid de implementare Windows nu vă spune nimic despre dacă același furnizor implementează un echivalent pe macOS.

Cereți o declarație care să acopere hardware-ul Mac, versiunea macOS, versiunea clientului și metoda de autentificare pe care o folosiți efectiv. O afirmație generală de suport nu este suficientă, pentru că diferența dintre funcționare și nefuncționare stă adesea în unul dintre acele patru.

Dacă furnizorul nu poate răspunde, acesta este răspunsul. Planificați etapa sesiunii și proiectați o alternativă pentru cazul fără supraveghere, în loc să descoperiți golul în timpul unei implementări.

Ce să cereți în schimb

Scrieți cerința în limbajul etapelor. Ce resursă, necesară cui, în ce context și cu ce întârziere acceptabilă atunci când conexiunea încă nu există?

Dacă răspunsul este un utilizator care se autentifică și apoi are nevoie de tunel, conectarea la cerere și un element de pornire sunt suficiente și ieftine. Dacă răspunsul este o mașină care repornește peste noapte și trebuie să raporteze, proiectarea are nevoie de o cale de deblocare a discului acceptată, de o identitate de dispozitiv și de un proces de recuperare care funcționează atunci când rețeaua nu apare niciodată. Dacă răspunsul este autentificarea organizației care depinde de tunel, atunci proiectele de autentificare, identitate și VPN trebuie construite împreună și nu cumpărate separat.

Documentația FileVault a Apple este punctul de plecare corect pentru etapa de deblocare. Tot ce urmează este o chestiune de client și identitate pe care o declarație a furnizorului ar trebui să o lămurească înainte de cumpărare.