VPN пред најава на macOS: отклучување, прозорец за најава, сесија

Еве едно уверување што ги чини луѓето една недела: дека Mac има еден момент наречен пред најава и дека VPN клиентот или стартува тогаш или не. Машината всушност има најмалку три моменти кога пристапот до мрежата е важен, одделени по тоа кому во тој момент му е дозволено да држи акредитиви. Клиент стартуван од ставка за најава покрива точно еден од нив, и тоа последниот.

Митот дека едно поставување ја покрива целата најава

Прочитајте ја повторно страницата на производот и погледнете која фаза ја именува функцијата. Поле со ознака стартувај при најава значи ставка за најава, која работи откако ќе постои корисничка сесија. Поле со ознака поврзи по барање значи дека клиентот отвора врска кога сообраќајот одговара на правило, што сепак бара клиентот и неговите акредитиви да бидат достапни.

Ниту едно од тоа не стигнува до процесот на подигање. Тоа не е ограничување што продавачот заборавил да го отстрани; тоа е она што оперативниот систем го дозволува. Пред да се отклучи томот нема работен систем од кој би се стартувал клиент, а по одјавата тајните на корисникот си одат со сесијата. Два одделни ѕида и ниту еден не попушта пред друго поле.

Кога ќе ги разделите фазите, првобитното прашање го менува обликот. Наместо да прашате дали VPN стартува пред најава, прашувате која од три конкретни моменти мора да работи, а потоа откривате дека секој има различен сопственик: слојот за шифрирање, мрежното проширување или корисничката сесија.

Што всушност се случува во секоја фаза

Подигањето започнува со шифриран том што мора да се отклучи пред да постои употреблив систем за каква било општа работа. Тоа отклучување се случува во ограничен контекст со ограничен сет акредитиви, и Apple јасно документира дека шифрираните податоци остануваат недостапни без валидно отклучување.

Потоа доаѓа прозорецот за најава, каде системот работи но корисничка сесија сè уште нема. Проширување во кориснички контекст веќе завршило ако корисникот се одјавил, а глобално системско проширување може сè уште да работи, но работењето не е исто што и држење на акредитивите што му требаат на вашиот VPN.

Потоа доаѓа сесијата, каде нормален клиент може да го прочита приврзокот со клучеви за најава, да побара втор фактор и да ги примени пратените рути. Повеќето функции што луѓето ги опишуваат како пред најава се всушност оваа фаза, активирана рано во сесијата а не пред неа.

Зошто launch daemon не може да се најави за отсутен корисник

Повишените привилегии изгледаат како да треба да го решат проблемот, а не го решаваат. Launch daemon работи како системски процес без корисничка сесија зад него, така што нема приврзок со клучеви за отклучување и нема човек да одговори на барање. Може да отвори сокет и да прочита датотека; она што не може е да стане корисникот што ги поседува акредитивите. Привилегијата не е идентитет и точно тука двете се помешуваат.

Она што луѓето го градат во тој јаз е скрипта со лозинка внатре, што е полош проблем од оној со кој започнале.

Чесната верзија на барањето е потесна. Ако машината мора да стигне до заштитен ресурс додека никој не е присутен, идентитетот што тој ресурс го прифаќа мора да биде оној што машината може да го држи без човек: сертификат на уред, акредитив во системскиот приврзок со клучеви или сметка чиј втор фактор не е известување до телефон во нечиј џеб. Дизајнирајте го тој идентитет намерно, и прашањето за фазата обично само се решава.

Функцијата на Windows пред најава не се пренесува

Windows има документиран механизам за пристап пред најава за некои производи за далечински пристап, и името патува подобро од способноста. Функција опишана во водич за распоредување на Windows не ви кажува ништо за тоа дали истиот продавач имплементира еквивалент на macOS.

Побарајте изјава што ги покрива хардверот на Mac, изданието на macOS, верзијата на клиентот и методот на автентикација што навистина го користите. Општо тврдење за поддршка не е доволно, бидејќи разликата помеѓу работа и неработа често лежи во една од тие четири.

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

Што да побарате наместо тоа

Напишете го барањето на јазикот на фазите. Кој ресурс, кому му треба, во кој контекст и со какво прифатливо доцнење кога врската сè уште ја нема?

Ако одговорот е корисник што се најавува и потоа му треба тунелот, поврзувањето по барање и ставката при стартување се доволни и евтини. Ако одговорот е машина што се рестартира преку ноќ и мора да извести, дизајнот бара поддржан пат за отклучување на дискот, идентитет на уред и процес на обновување што работи кога мрежата никогаш не се подига. Ако одговорот е најава во организација што зависи од тунелот, тогаш дизајните за најава, идентитет и VPN мора да се градат заедно, а не да се купуваат одделно.

Apple-овата документација за FileVault е вистинската почетна точка за фазата на отклучување. Сè потоа е прашање на клиент и идентитет што изјавата на продавачот треба да го реши пред купувањето.