Connect પર એક ક્લિકથી એક સાઇન-ઇન વિન્ડો આવવી જોઈએ. Mac પર તે ઘણી વાર ત્રણ આપે છે, અને તેઓ ભાગ્યે જ એક જ માલિક વહેંચે છે: સ્થાનિક ઓળખપત્ર પ્રોમ્પ્ટના માલિક Keychain છે, VPN ગેટવે પ્રમાણીકરણનો માલિક છે, અને ક્લાયન્ટ પોતાની સૂચનાઓનો માલિક છે. બધું શાંત કરી દે તેવું સ્વિચ શોધવાને બદલે, દરેક વિન્ડોને તેના પોતાના ઉપાય સાથે અલગ ખામી તરીકે ગણો. નીચેની માર્ગદર્શિકા એક જાણી જોઈને કરેલા કનેક્શન પ્રયાસમાંથી પસાર થાય છે અને એવી ચકાસણી પર પૂરી થાય છે જે તમે પુનરાવર્તિત કરી શકો.

કોઈ સેટિંગ બદલતા પહેલાં દરેક સંવાદના માલિકનું નામ આપો

પહેલું પગલું હિસાબ છે, રૂપરેખાંકન નહીં. એક કનેક્શન પ્રયાસ કરો અને દેખાતી દરેક વિન્ડો માટે ચાર ક્ષેત્રો લખો: સંવાદમાં દેખાતું એપનું નામ, ગુપ્ત કંઈ પણ વગરનું ચોક્કસ લખાણ, તે જે તબક્કે આવ્યું અને તમે તેને રદ કર્યું ત્યારે શું થયું. આવી ત્રણ પંક્તિઓથી મેં જોયેલા લગભગ દરેક રિપોર્ટ આવરી લેવાય છે.

માલિકી સાચો ઉપાય નક્કી કરે છે, અને ખોટો ઉપાય જ સામાન્ય રીતે એક પ્રોમ્પ્ટને ત્રણમાં ફેરવે છે:

WindowWho owns itCorrect fixWhat not to do
“wants to use your confidential information stored in…”The item's access control list in your login keychainApprove the specific client helper, once, after checking the nameResetting the login keychain, or granting Always Allow to every application
“Sign in to <organization>” or an MFA pushThe gateway's identity providerUse the client's supported session renewal, or re-authenticateScripting a fixed password or code into the client
“Connection failed”, “Update required”, a policy bannerThe client or your organizationRead the first error and fix its causeHiding notices by editing a preference file the client rewrites

એક જ પ્રયાસમાં પાછો આવતો પ્રોમ્પ્ટ આગલા પ્રયાસમાં પાછો આવતા પ્રોમ્પ્ટ કરતાં અલગ સંકેત છે. પહેલાનો અર્થ સામાન્ય રીતે એ કે કનેક્શન તમારા નીચે ફરી શરૂ થયું; બીજાનો અર્થ સામાન્ય રીતે એ કે સંગ્રહિત ઓળખપત્ર ફરી માંગવામાં આવે છે. Keychain ને સ્પર્શ કરતા પહેલાં નોંધો કે તમારી પાસે કયો છે, કારણ કે બંનેમાં લગભગ કંઈ સામ્ય નથી.

કેટલી વસ્તુઓ ટનલ શરૂ કરે છે તે શોધો

Mac પર એક જ VPN ચાર માળખા શરૂ કરી શકે છે: મેનૂ બારની ક્રિયા, લૉગિન આઇટમ, On Demand નિયમ, અને સ્ક્રિપ્ટ કે એજન્ટ. જ્યારે તેમાંથી બે સક્રિય થાય, ત્યારે બીજી શરૂઆત ત્યારે આવી શકે જ્યારે પહેલી હજી પ્રમાણીકરણની રાહ જોતી હોય, જે ડુપ્લિકેટ વિન્ડો અને કોઈ પ્રગતિ નથી આપતું. પહેલાં યાદી બનાવો કે શું રૂપરેખાંકિત છે: scutil --nc list સિસ્ટમ સેટિંગ્સ જાણે છે તે VPN સેવાઓ તેમની વર્તમાન સ્થિતિ સાથે છાપે છે. જે ક્લાયન્ટ પોતાનું નેટવર્ક એક્સ્ટેન્શન સાથે લાવે છે તેઓ પ્રોફાઇલ એપની અંદર રાખે છે અને ત્યાં દેખાય નહીં, તેથી ક્લાયન્ટની પોતાની કનેક્શન યાદી પણ તપાસો.

પછી હરીફ સ્ટાર્ટર્સ શોધો. scutil --nc show "Work VPN" બિલ્ટ-ઇન સેવાની રૂપરેખાંકન શબ્દકોશ છાપે છે, જેમાં On Demand નિયમોનો સમાવેશ થાય છે; કોઈ પણ ઇન્ટરફેસ ફેરફાર પર ફરી જોડાતો નિયમ દર વખતે Wi-Fi ખસે કે ડિસ્પ્લે નેટવર્ક સ્ટેકને જગાડે ત્યારે ટનલ ફરી શરૂ કરશે — અને પ્રમાણીકરણ પ્રોમ્પ્ટ ફરી ખોલશે. સિસ્ટમ સેટિંગ્સ > સામાન્ય > લૉગિન આઇટમ્સ હેઠળ લૉગિન આઇટમ્સ તપાસો, અને વપરાશકર્તા દીઠ એજન્ટોની યાદી આનાથી બનાવો ls ~/Library/LaunchAgents. MDM-સંચાલિત સુરક્ષા સ્ટેકની માલિકીની કોઈપણ વસ્તુને અડ્યા વગર રહેવા દો; તેને દૂર કરવું સામાન્ય રીતે આગલી ચકાસણીમાં પાછું ધકેલાય છે.

પ્રયાસ દરમિયાન ખરેખર શું ચાલી રહ્યું છે તે જોવા માટે: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. જ્યાં એકની અપેક્ષા હોય ત્યાં બે ક્લાયન્ટ સહાયકો હોવા "મને બે પ્રોમ્પ્ટ કેમ મળ્યા" કોઈ પણ ઓળખપત્ર સમસ્યા કરતાં ઘણી વાર સમજાવે છે.

કીચેઈન રીસેટ કર્યા વિના Keychain ઍક્સેસ સુધારો

પ્રોમ્પ્ટ સંગ્રહિત આઇટમની ઍક્સેસ કંટ્રોલ યાદીમાંથી આવે છે, VPN પ્રોટોકોલમાંથી નહીં. દરેક આઇટમ નોંધે છે કે કઈ એપ્લિકેશનો પૂછ્યા વગર તેને વાંચી શકે. ક્લાયન્ટ અપડેટ પછી, પૂછતો સહાયક અલગ નામ કે સહી ધરાવી શકે જ્યારે આઇટમ હજી જૂનીની યાદી બતાવે, તેથી macOS દરેક કનેક્શન પર ફરી પૂછે છે. તે એક જ આઇટમ માટે નવા સહાયકને મંજૂર કરવું એ આખો ઉપાય છે; દરેક એપ્લિકેશનને મંજૂર કરવું તે નથી.

VPN ને સ્પર્શ કર્યા વિના તમે ખાતરી કરી શકો છો કે ACL જ કારણ છે: security find-generic-password -s "service-name" -g ટર્મિનલમાંથી એ જ આઇટમ વાંચે છે. જો તે આદેશ પણ પ્રોમ્પ્ટ ઉપાડે, તો સંવાદ કીચેઈનનો છે અને ટનલ ફક્ત ટ્રિગર છે. Apple ની ત્રણ બટનો વિશેની માર્ગદર્શિકા — એક વાર મંજૂર કરો, હંમેશાં મંજૂર કરો, નકારો — એક વાર વાંચવા લાયક છે, કારણ કે નકારવું જ પ્રોમ્પ્ટને આગલા પ્રયાસને બદલે તરત જ પાછો લાવે છે.

જો તમે ખોટા સહાયકને મંજૂર કર્યો હોય, તો Keychain Access માં આઇટમ ખોલો, Access Control પર જાઓ અને તે એન્ટ્રી દૂર કરો; તે જ પાછું ખેંચવું છે. લૉગિન કીચેઈન કાઢી નાખવું, અથવા તેને ફરી બનાવતું સમારકામ સાધન ચલાવવું, અસંબંધિત પાસવર્ડ પણ ફેંકી દે છે અને સમસ્યા કરતાં ઘણું મોટું ફેરફાર છે.

લૉગિન અને નીતિના પગલાંને તેમના પોતાના પ્રવાહોમાં રાખો

બ્રાઉઝર લૉગિન કે MFA પડકાર ગેટવેનો છે. જો તમારી સંસ્થા સેશન ચાલુ રાખવાનું કે પ્રમાણપત્ર-આધારિત પ્રમાણીકરણ આપે છે, તો તેનો ઉપયોગ કરો, કારણ કે ઓછી વાર પ્રમાણીકરણ કરવાનો તે જ સમર્થિત માર્ગ છે. ક્લાયન્ટમાં નિશ્ચિત કોડ લખવો, અથવા પ્રોમ્પ્ટ કદી ન આવે તે માટે સ્ક્રિપ્ટમાં પાસવર્ડ સંગ્રહવો, એક પરસ્પર ક્રિયાશીલ પરિબળને સ્થિર રહસ્યથી બદલે છે અને આગલી વાર નીતિ બદલાય ત્યારે નિષ્ફળ જાય છે.

સંસ્થાની સૂચનાઓ એ જ એક શ્રેણી છે જેને તમારે દબાવવી ન જોઈએ. તેઓ સામાન્ય રીતે પોશ્ચર ચકાસણી કે સ્વીકાર્ય ઉપયોગની સ્વીકૃતિ લાગુ કરે છે, અને તેમને છુપાવવાથી ટનલ ચાલુ હોય તો પણ ઉપકરણ અનુપાલનની બહાર જઈ શકે. ભૂલના સંવાદો બીજી શ્રેણી છે: પહેલી ભૂલનું લખાણ રાખો, કારણ કે બીજો સંવાદ ઘણી વાર ફરી પ્રયાસ પછી નોંધાયેલી એ જ નિષ્ફળતા હોય છે.

એક પ્રયાસથી ચકાસો, પછી રીબૂટ પછી

ડુપ્લિકેટ સ્ટાર્ટર્સ દૂર કર્યા પછી અને કીચેઈન એન્ટ્રી સુધાર્યા પછી, એક જ પ્રયાસ કરો: મેનૂ બાર સહાયક સહિત દરેક ક્લાયન્ટ ઇન્સ્ટન્સ બંધ કરો, એક વાર જોડાઓ અને વિન્ડો ગણો. તમારે કીચેઈન મંજૂરી જોઈએ, જો આઇટમ ફરી બન્યું હોય, અને એક પ્રમાણીકરણ પગલું. વધુ નહીં. scutil --nc status "Work VPN" બિલ્ટ-ઇન સેવા માટે Connected જાણ કરવું જોઈએ.

પછી એક વાર રીબૂટ કરો અને પુનરાવર્તન કરો. ફક્ત રીબૂટ પછી પાછો આવતો પ્રોમ્પ્ટ લૉગિન આઇટમ કે On Demand નિયમ તરફ સંકેત કરે છે, ઓળખપત્રો તરફ નહીં; સેશનની અંદર પાછો આવતો ACL કે બીજા સ્ટાર્ટર તરફ સંકેત કરે છે. જો બંને પાસ પછી પણ તે પુનરાવર્તિત થાય, તો તમારા વ્યવસ્થાપકને આપવા જેવી ઉપયોગી વસ્તુ પહેલા પ્રયાસનું ત્રણ-પંક્તિ કોષ્ટક છે — માલિક, ચોક્કસ લખાણ, તબક્કો — સંવાદનો સ્ક્રીનશોટ નહીં.

ધ્યેય ઓછા પ્રોમ્પ્ટ છે, શાંત પ્રોમ્પ્ટ નહીં. જે કનેક્શન તેના અધિકૃતિ પગલાં છુપાવે છે તે કનેક્શન તમે હવે ઓડિટ કરી શકતા નથી, અને આગલું પ્રમાણપત્ર ફેરવણી તમને કયો ઘટક નિષ્ફળ જાય છે તે જાણ્યા વિના પકડશે.

સંબંધિત લેખો