లాగిన్ చేసిన తర్వాత 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 బిల్డ్ నడుపుతున్నారు, లాగిన్ తర్వాత ఏమి కనిపిస్తుంది, ఇన్పుట్ లేకుండా టన్నెల్ ఏర్పడుతుందా. తర్వాత కావలసిన ఫలితాన్ని సహోద్యోగి మిమ్మల్ని అడగకుండా అమలు చేయగల ఒక వాక్యంలో చెప్పండి. క్లయింట్ను అందుబాటులో ఉంచి దాని విండోను మూయడం ఆటోమేటిక్ కనెక్షన్ను నిరోధించడం కంటే వేరే అభ్యర్థన. ఖచ్చితమైన అభ్యర్థన విధాన మార్పును పొందుతుంది, అస్పష్టమైనది ఎవరికీ యాజమాన్యం లేని పరిష్కారాన్ని పొందుతుంది.

మార్పు తర్వాత లాగ్ అవుట్ అయ్యి మళ్లీ లాగిన్ అవ్వండి, తర్వాత మీరు ఆధారపడే మాన్యువల్ కనెక్షన్ వర్క్ఫ్లోను అమలు చేయండి. తిరిగి కనెక్షన్ పరిధిలో ఉంటే, మీ నిర్వాహకుడు అనుమతించే విధానం కింద దాన్ని విడిగా పరీక్షించండి.

సంస్థ కోరే భద్రతా మాడ్యూల్లు ఇంకా నడుస్తున్నాయో లేదో తనిఖీ చేయండి, ఎందుకంటే నిశ్శబ్ద తొలగింపును ఆడిట్ కనుగొనే వరకు మిస్ అవ్వడం సులభం. మీకు కావలసిన ఫలితం పనిచేసే క్లయింట్తో కోరిన స్టార్టప్ ప్రవర్తన, కనిపించని ఐకాన్ మరియు ఒక రహస్యం కాదు. మూడింటిలో ఏ ప్రవర్తన మారిందో రాయండి, తద్వారా తదుపరి వ్యక్తి నిజమైన సవరణను యాదృచ్ఛికం నుండి వేరు చేయగలరు.

సంబంధిత వ్యాసాలు