Cisco Secure Client på Mac: fönster, automatisk anslutning eller återanslutning?

Något Cisco-relaterat dyker upp efter att du loggat in, och det kan ansluta något eller inte. Fönstret, den automatiska anslutningen och återanslutningen efter ett nätverksbyte är tre separata beteenden med tre separata ägare. De flesta frustrerade försök att ta bort ett startobjekt börjar med att dessa tre slås ihop till ett enda klagomål. Separera dem först, så skriver ändringsbegäran sig själv.

Namnge beteendet du faktiskt ser

Observera en inloggning utan att röra något och skriv ned vad som händer, i ordning. Ett fönster som öppnas utan anslutning är ett fall, ett fönster som öppnas och ansluter är ett annat, och en anslutning som återkommer efter nätverksbytet är ett tredje. Fråga vad som faktiskt upprättar tunneln i stället för vad som syns på skärmen, eftersom fönstret och tunneln har olika ägare. Två slags bevis svarar på det, och bara ett av dem ser den här klienten:

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

Läs de tre utskrifterna tillsammans, eftersom scutil --nc list listar systemets VPN-konfigurationer och en tom lista betyder bara att ingen system-VPN-tjänst äger en tunnel. Cisco Secure Client registrerar ingen: den avslutas via vpnagentd och ett utun-gränssnitt, så processen och gränssnittet är bevisen som ser den. När vpnagentd körs och ett utun-gränssnitt har en adress finns tunneln även med fönstret stängt; när inget av dem finns är den automatiska anslutningen av och fönstret är det enda att prata om. Front end kan också köra medan en separat bakgrundstjänst äger tunneln, så ägarfrågan hör till profilavsnitten och inte till detta.

Fönstret vid inloggning är en startfråga

Ett inloggningsfönster kommer från en startagent eller från appens egen inställning att öppnas vid inloggning, och ingen av dem är samma mekanism som anslutningspolicyn. Identifiera installerad produkt och version innan du redigerar något, eftersom dokumentation för äldre versioner beskriver filer som en nuvarande installation kanske inte använder. Att stänga av den automatiska anslutningen stoppar inte nödvändigtvis fönstret från att öppnas, och att stoppa fönstret stoppar inte en återanslutning. Använd klientens stödda startkontroll eller administratörens programvaruprocess, i den ordningen.

På en hanterad Mac, bekräfta om beteendet kommer via en installerad konfigurationsprofil innan du behandlar det som en lokal inställning. Systemet kan lista de profiler det har, och ett hanterat inloggningsobjekt är inte ditt att radera:

profiles show -type configuration

Där inställningen är användarstyrd, ändra den i klientens inställningar och logga ut för att testa. Där den är låst är det bara profilens ägare som kan ändra den. Att ta bort filer lokalt ger en avvikelse som nästa uppdatering tyst reparerar, vilket gör det till den minst hållbara lösningen som finns. En gråad kryssruta är inte en trasig klient; det är en policyförklaring.

Auto Connect on Start är en separat inställning

Ciscos anslutningsguide anger Auto Connect on Start som den inställning som styr ett anslutningsförsök när klienten startar, och beskriver den som av som standard. En utrullad profil kan slå på den, och därför beter sig två Macar med samma klient olika vid inloggning. Leta efter den inställningen i klientens inställningar innan du antar något om startobjekt.

Ändra den via den stödda kontrollen och testa med full utloggning i stället för omstart, eftersom vissa komponenter bara startar med inloggningssessionen. Bekräfta sedan att den manuella anslutningen fortfarande fungerar, eftersom en inställning som dämpar det automatiska försöket inte ska ta bort din förmåga att ansluta. Om klienten ändå återansluter direkt tittar du på återanslutningsbeteendet. Det är nästa fråga, och den har en annan ägare.

Auto Reconnect hör till en tredje inställning

Återanslutning styr vad som händer efter att en etablerad session tappar sin väg: locket stängs, Wi-Fi-nätet byts, en trådbunden länk faller. Cisco dokumenterar den separat från startbeteendet, så en startändring rör den inte. Testa den genom att koppla från nätet ett ögonblick och se om tunneln kommer tillbaka utan inmatning.

En återanslutning som ignorerar en avsiktlig frånkoppling är oftast policy, inte en bugg. Vissa utrullningar kräver en alltid-på-uppsättning, vilket hör hemma i ett policysamtal och inte i en kringgående lösning. Att ta bort komponenten som upprätthåller den kan bryta kontroller av enhetens skick och sedan återställas av nästa hanteringsknuff. Om kravet är legitimt, fråga vad det ska garantera och om en snävare inställning uppfyller det; om inte kan profilens ägare ändra det på ett ställe i stället för att du ändrar det på fyrtio bärbara datorer.

Be om den minsta ändringen och verifiera den sedan

Skriv begäran med fyra fakta: vilken klientversion du kör, vilken macOS-version du kör, vad som visas efter en inloggning och om en tunnel bildas utan inmatning. Ange sedan önskat resultat i en mening som en kollega skulle kunna genomföra utan att fråga dig. Att hålla klienten tillgänglig men stänga dess fönster är en annan begäran än att förhindra en automatisk anslutning. En precis begäran får en policyändring, medan en vag får en kringgående lösning som ingen äger.

Efter ändringen, logga ut och in igen och kör sedan det manuella anslutningsflöde du är beroende av. Om återanslutning ingick i omfånget, testa det separat enligt den procedur din administratör tillåter.

Kontrollera att säkerhetsmodulerna organisationen kräver fortfarande körs, eftersom en tyst borttagning är lätt att missa tills en revision hittar den. Resultatet du vill ha är det begärda startbeteendet med en fungerande klient, inte en saknad ikon och en gåta. Skriv ned vilket av de tre beteendena som ändrades, så att nästa person kan skilja en riktig rättelse från ett sammanträffande.