Mac પર Cisco Secure Client: વિન્ડો, સ્વયં કનેક્ટ કે ફરી કનેક્ટ?

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

તમે ખરેખર જે વર્તન જોઈ રહ્યા છો તેનું નામ આપો

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

scutil --nc list
ps aux | grep -i [v]pnagentd
ifconfig | grep -A3 utun

ત્રણેય આઉટપુટ સાથે વાંચો, કારણ કે scutil --nc list સિસ્ટમના VPN રૂપરેખાંકનોની યાદી આપે છે અને ખાલી યાદીનો અર્થ ફક્ત એટલો છે કે કોઈ સિસ્ટમ VPN સેવા ટનલ ધરાવતી નથી. Cisco Secure Client એક પણ નોંધતું નથી: તે vpnagentd અને utun ઇન્ટરફેસ દ્વારા સમાપ્ત થાય છે, તેથી પ્રક્રિયા અને ઇન્ટરફેસ એ પુરાવા છે જે તેને જુએ છે. જ્યારે vpnagentd ચાલી રહ્યું છે અને utun ઇન્ટરફેસ પાસે સરનામું છે, ત્યારે વિન્ડો બંધ હોવા છતાં ટનલ અસ્તિત્વમાં છે; જ્યારે બંનેમાંથી કોઈ ન હોય, ત્યારે સ્વયં કનેક્શન બંધ છે અને વિન્ડો જ ચર્ચાનો વિષય છે. ફ્રન્ટ એન્ડ ત્યારે પણ ચાલી શકે છે જ્યારે અલગ બેકગ્રાઉન્ડ સેવા ટનલ ધરાવે છે, તેથી માલિકીનો પ્રશ્ન પ્રોફાઇલ વિભાગોનો છે, આનો નહીં.

લોગિન વખતની વિન્ડો એ લોન્ચ પ્રશ્ન છે

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

મેનેજ કરેલા Mac પર, વર્તનને સ્થાનિક પસંદગી તરીકે ગણતા પહેલાં તે સ્થાપિત રૂપરેખાંકન પ્રોફાઇલ દ્વારા આવે છે કે નહીં તે ચકાસો. સિસ્ટમ પાસેની પ્રોફાઇલોની યાદી આપી શકે છે અને મેનેજ કરેલી લોગિન આઇટમ તમારી કાઢી નાખવાની નથી:

profiles show -type configuration

જ્યાં સેટિંગ વપરાશકર્તા દ્વારા નિયંત્રિત છે ત્યાં તેને ક્લાયન્ટ પસંદગીઓમાં બદલો અને પરીક્ષણ માટે લોગ આઉટ કરો. જ્યાં તે લોક છે ત્યાં ફક્ત પ્રોફાઇલનો માલિક જ તેને બદલી શકે. સ્થાનિક રીતે ફાઇલો દૂર કરવાથી એવી ભિન્નતા ઊભી થાય છે જે આગલું અપડેટ ચૂપચાપ સુધારે છે, જે તેને ઉપલબ્ધ સૌથી ઓછું ટકતું સમાધાન બનાવે છે. ધૂંધળું ચેકબોક્સ તૂટેલો ક્લાયન્ટ નથી; તે નીતિનું નિવેદન છે.

Auto Connect on Start એ અલગ પસંદગી છે

Cisco ની કનેક્શન માર્ગદર્શિકા Auto Connect on Start ને એ પસંદગી તરીકે ઓળખાવે છે જે ક્લાયન્ટ શરૂ થાય ત્યારે કનેક્શન પ્રયાસને નિયંત્રિત કરે છે અને તેને મૂળભૂત રીતે બંધ તરીકે વર્ણવે છે. તૈનાત પ્રોફાઇલ તેને સક્ષમ કરી શકે છે, તેથી જ એક જ ક્લાયન્ટ ધરાવતા બે Mac લોગિન વખતે અલગ વર્તે છે. લોન્ચ આઇટમો વિશે કંઈપણ ધારવા પહેલાં ક્લાયન્ટની સેટિંગ્સમાં તે પસંદગી શોધો.

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

Auto Reconnect ત્રીજા સેટિંગનો છે

ફરી કનેક્શન નક્કી કરે છે કે સ્થાપિત સત્ર તેનો માર્ગ ગુમાવ્યા પછી શું થાય: ઢાંકણ બંધ થવું, Wi-Fi નેટવર્ક બદલાવું, વાયરવાળી લિંક તૂટવી. Cisco તેને સ્ટાર્ટઅપ વર્તનથી અલગ દસ્તાવેજીકરણ કરે છે, તેથી સ્ટાર્ટઅપ ફેરફાર તેને સ્પર્શશે નહીં. નેટવર્કને ક્ષણભર ડિસ્કનેક્ટ કરીને અને ટનલ ઇનપુટ વિના પાછી આવે છે કે નહીં તે જોઈને તેનું પરીક્ષણ કરો.

જાણીજોઈને કરેલા ડિસ્કનેક્ટને અવગણતું ફરી કનેક્શન સામાન્ય રીતે બગ નહીં પણ નીતિ હોય છે. કેટલાક તૈનાતીઓ હંમેશા ચાલુ રહેવાની ગોઠવણ માગે છે, જે વર્કઅરાઉન્ડને બદલે નીતિ ચર્ચામાં આવે છે. તેને લાગુ કરતું ઘટક દૂર કરવાથી પોસ્ચર ચકાસણીઓ તૂટી શકે છે અને પછી આગલા મેનેજમેન્ટ પુશ દ્વારા પુનઃસ્થાપિત થઈ શકે છે. જો જરૂરિયાત વાજબી હોય, તો પૂછો કે તે શું બાંયધરી આપવા માટે છે અને શું સાંકડી સેટિંગ તેને સંતોષે છે; જો ન હોય, તો પ્રોફાઇલનો માલિક તેને એક જગ્યાએ બદલી શકે છે, તમે ચાલીસ લેપટોપ પર બદલવાને બદલે.

સૌથી નાનું પરિવર્તન માગો, પછી તેને ચકાસો

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

પરિવર્તન પછી, લોગ આઉટ કરીને ફરી લોગિન કરો, પછી તમે જેના પર આધાર રાખો છો તે મેન્યુઅલ કનેક્શન વર્કફ્લો ચલાવો. જો ફરી કનેક્શન અવકાશમાં હતું, તો તમારા એડમિનિસ્ટ્રેટર જે પ્રક્રિયા માન્ય કરે તેના હેઠળ તેને અલગથી ચકાસો.

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