Po zalogowaniu pojawia się coś związanego z Cisco i może, ale nie musi, coś łączyć. Okno, automatyczne połączenie i ponowne łączenie po zmianie sieci to trzy odrębne zachowania z trzema odrębnymi właścicielami. Większość sfrustrowanych prób usunięcia elementu startowego zaczyna się od stopienia tych trzech w jedną skargę. Najpierw je rozdziel, a wniosek o zmianę napisze się sam.

Nazwij zachowanie, które faktycznie widzisz

Obserwuj jedno logowanie, niczego nie dotykając, i zapisz po kolei, co się dzieje. Okno otwierające się bez połączenia to jeden przypadek, okno, które otwiera się i łączy, to drugi, a połączenie wracające po zmianie sieci to trzeci. Pytaj, co faktycznie ustanawia tunel, a nie co widać na ekranie, bo okno i tunel mają różnych właścicieli. Odpowiadają na to dwa rodzaje dowodów, a tylko jeden z nich widzi tego klienta:

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

Przeczytaj trzy wyniki razem, bo scutil --nc list wymienia konfiguracje VPN systemu i pusta lista oznacza tylko, że żadna usługa VPN systemu nie ma tunelu. Cisco Secure Client nie rejestruje takiego: kończy się przez vpnagentd i interfejs utun, więc proces i interfejs są dowodami, które go widzą. Gdy vpnagentd działa i interfejs utun ma adres, tunel istnieje nawet przy zamkniętym oknie; gdy nie ma żadnego z nich, automatyczne połączenie jest wyłączone i okno jest jedynym tematem rozmowy. Front end może też działać, gdy tunel należy do osobnej usługi w tle, więc kwestia własności należy do sekcji profilu, a nie do tej.

Okno przy logowaniu to kwestia uruchamiania

Okno logowania pochodzi od agenta uruchamiania lub od własnej preferencji aplikacji otwierania przy logowaniu, i żadne nie jest tym samym mechanizmem co polityka połączeń. Przed edycją czegokolwiek ustal zainstalowany produkt i wersję, bo dokumentacja starszych wydań opisuje pliki, których bieżąca instalacja może nie używać. Wyłączenie automatycznego połączenia niekoniecznie zatrzymuje otwieranie okna, a zatrzymanie okna nie zatrzymuje ponownego łączenia. Użyj obsługiwanej kontroli uruchamiania klienta lub procesu oprogramowania administratora, w tej kolejności.

Na zarządzanym Macu potwierdź, czy zachowanie przychodzi przez zainstalowany profil konfiguracji, zanim potraktujesz je jako lokalną preferencję. System może wyświetlić posiadane profile, a zarządzany element logowania nie jest twoim do usunięcia:

profiles show -type configuration

Tam, gdzie ustawienie jest kontrolowane przez użytkownika, zmień je w preferencjach klienta i wyloguj się, aby przetestować. Tam, gdzie jest zablokowane, tylko właściciel profilu może je zmienić. Usuwanie plików lokalnie tworzy rozbieżność, którą następna aktualizacja po cichu naprawia, co czyni je najmniej trwałym dostępnym rozwiązaniem. Wyszarzony checkbox nie jest zepsutym klientem; to deklaracja polityki.

Auto Connect on Start to osobna preferencja

Przewodnik Cisco po połączeniu nazywa Auto Connect on Start preferencją sterującą próbą połączenia przy starcie klienta i opisuje ją jako domyślnie wyłączoną. Wdrożony profil może ją włączyć, dlatego dwa Maki z tym samym klientem zachowują się przy logowaniu różnie. Szukaj tej preferencji w ustawieniach klienta, zanim cokolwiek założysz o elementach startowych.

Zmień ją przez obsługiwaną kontrolę i przetestuj pełnym wylogowaniem, a nie ponownym uruchomieniem, bo niektóre komponenty startują tylko z sesją logowania. Potem potwierdź, że ręczne połączenie nadal działa, ponieważ preferencja tłumiąca automatyczną próbę nie powinna odbierać ci możliwości łączenia. Jeśli klient i tak natychmiast łączy się ponownie, patrzysz na zachowanie ponownego łączenia. To następne pytanie i ma innego właściciela.

Auto Reconnect należy do trzeciego ustawienia

Ponowne łączenie rządzi tym, co dzieje się, gdy ustanowiona sesja traci ścieżkę: zamknięcie pokrywy, zmiana sieci Wi-Fi, zerwanie łącza przewodowego. Cisco dokumentuje je oddzielnie od zachowania startowego, więc zmiana startu go nie dotknie. Przetestuj je, odłączając sieć na chwilę i obserwując, czy tunel wraca bez udziału użytkownika.

Ponowne łączenie ignorujące świadome rozłączenie to zwykle polityka, a nie błąd. Niektóre wdrożenia wymagają układu zawsze włączonego, który należy do rozmowy o polityce, a nie do obejścia. Usunięcie komponentu, który to wymusza, może złamać kontrole postawy, a potem zostanie przywrócone przez następne pchnięcie zarządzania. Jeśli wymóg jest uzasadniony, zapytaj, co ma gwarantować i czy węższe ustawienie go spełnia; jeśli nie, właściciel profilu może zmienić je w jednym miejscu, zamiast ty zmieniać je na czterdziestu laptopach.

Poproś o najmniejszą zmianę, a potem ją sprawdź

Napisz prośbę z czterema faktami: jaką kompilację klienta uruchamiasz, jaką kompilację macOS uruchamiasz, co pojawia się po zalogowaniu i czy tunel powstaje bez udziału użytkownika. Następnie podaj pożądany wynik w jednym zdaniu, które współpracownik mógłby wdrożyć, nie pytając cię. Utrzymanie klienta dostępnym, ale zamknięcie jego okna to inna prośba niż zapobieżenie automatycznemu połączeniu. Precyzyjna prośba dostaje zmianę polityki, a niejasna obejście, którego nikt nie posiada.

Po zmianie wyloguj się i zaloguj ponownie, a następnie uruchom ręczny przepływ połączenia, od którego zależysz. Jeśli ponowne łączenie było w zakresie, przetestuj je osobno według procedury, na którą pozwala administrator.

Sprawdź, czy moduły bezpieczeństwa wymagane przez organizację nadal działają, bo ciche usunięcie łatwo przeoczyć, dopóki audyt go nie znajdzie. Wynik, którego chcesz, to zamówione zachowanie startowe z działającym klientem, a nie brakująca ikona i tajemnica. Zapisz, które z trzech zachowań się zmieniło, aby następna osoba mogła odróżnić prawdziwą poprawkę od przypadku.

Powiązane artykuły