macOS પર લૉગિન પહેલાં VPN: અનલૉક, લૉગિન વિન્ડો, સેશન
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 દસ્તાવેજીકરણ અનલૉક તબક્કા માટે યોગ્ય શરૂઆતનું સ્થાન છે. એના પછીનું બધું ક્લાયન્ટ અને ઓળખનો પ્રશ્ન છે જે ખરીદતા પહેલાં વિક્રેતાના નિવેદનથી નક્કી થવો જોઈએ.