AnyConnect rozłącza się po zamknięciu terminala: kontrole sesji

Tunel działa, zamykasz zapasowy terminal i VPN pada bez jednego naciśnięcia klawisza w kliencie. W kliencie AnyConnect dla Linuksa zgłaszaną przyczyną jest rozliczanie sesji, a nie routing: klient zapisuje, które sesje logowania istniały w chwili podniesienia tunelu, i koniec każdej z nich traktuje jako powód do zerwania. Poniższe kontrole wykonuje się po kolei, a pierwsza nieudana mówi, czy w ogóle patrzysz na to zachowanie. W zwykłym wyjściu klienta nie ma słowa o terminalu, dlatego pierwszy odruch, obwinianie koncentratora, jest zwykle stratą czasu.

Nie zaczynaj od edycji plików systemowych. Każdy krok albo wyjaśnia zerwanie, albo usuwa kandydata, a tanie kroki są pierwsze.

Oddziel zerwanie sesji od zerwania warstwy nośnej

Połącz się ponownie natychmiast po rozłączeniu. Tunel, który wraca w kilka sekund, w tej samej sieci i bez nowych poświadczeń, wskazuje na lokalny wyzwalacz, jak zamknięta sesja, a nie na martwy uplink, roaming Wi-Fi czy limit bezczynności na koncentratorze. Tunel, który wisi na Connecting albo zawodzi aż do zmiany sieci, to inny artykuł.

Zapisz, co było otwarte, gdy tunel się podnosił: terminal, z którego uruchomiłeś klienta, każdą drugą powłokę, logowanie graficzne i każdą sesję SSH z innej maszyny. Ta lista zaraz będzie potrzebna, a odtwarzanie jej z pamięci po kolejnym zerwaniu jest zawodne.

Sprawdź, co klient zapisał w chwili łączenia

Klient nie bada procesów nadrzędnych ani własności terminala. Robi zrzut zbioru sesji logowania obecnych w chwili łączenia i później porównuje ten zbiór; gdy element znika, porównanie zawodzi i tunel idzie z nim. Dlatego zamknięcie okna, z którego się połączyłeś, może być nieszkodliwe, a zamknięcie niezwiązanego zapasowego terminala zabija połączenie: liczy się to, czy ta sesja była w pierwotnym zbiorze. To porównanie zbiorów, a nie liczenie, więc zastąpienie sesji może być równie zgubne jak utrata jednej.

Wypisz, co klient mógł zobaczyć, zanim cokolwiek zmienisz:

who
w
last -n 10
sudo ls -l /run/utmp

Każdy wiersz z who to wpis procesu użytkownika w utmp. Jeśli twoja sesja pojawia się dwa razy, raz dla logowania graficznego i raz dla terminala, oba wpisy istniały w chwili łączenia i oba są kandydatami.

Usuń z utmp tylko własny wpis

Opublikowany sposób obejścia czyni sesję, której zaraz użyjesz, niewidoczną w utmp przed startem klienta. Mały program w C przechodzi przez getutent(), znajduje rekord, którego ut_line równa się TTY standardowego wejścia, i przepisuje ten rekord. Kolejność jest celowa: setutent(), odczyt wpisu, skopiowanie jego ut_id, ustawienie ut_type na DEAD_PROCESS, wyczyszczenie pól użytkownika i linii, zapis z powrotem przez pututline(), a potem endutent().

Skompiluj go, a potem uruchom jako root z powłoki, która uruchomi klienta:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

Dwa tryby awarii wyjaśniają większość zgłoszeń, że narzędzie nic nie robi. Działa ono na TTY przypisanym do standardowego wejścia, więc uruchomienie ze skryptu lub zadania cron bez terminala nie zostawia nic do dopasowania. A /run/utmp nie jest zapisywalny dla zwykłych użytkowników, więc uruchomienie bez roota kończy się po cichu, chyba że sprawdzisz kod wyjścia.

Sprawdź, czy tunel przetrwa zamknięcie

Przetestuj mechanizm, zamiast go zakładać. Połącz się z sesji, którą chcesz zachować, otwórz drugi terminal, zamknij ten drugi, a potem potwierdź poleceniem vpn state i spojrzeniem na listę interfejsów, że tunel nadal działa. Jeśli tunel przetrwa, wyzwalaczem był konkretny typ sesji, a nie każda sesja, i znalazłeś sesję, która musi pozostać otwarta.

Jeśli nadal pada, obserwowana sesja była gdzie indziej, najczęściej jest to logowanie graficzne, które utworzyło twój terminal, a usunięcie jednego wpisu TTY nie pomoże. Powtórz obserwację z pełną listą z pierwszego kroku, zamiast dodawać kolejne operacje.

Kiedy przepisywanie utmp jest złą odpowiedzią

utmp to wspólna ewidencja, a nie prywatna tabela. Przepisanie wpisu żywej jeszcze sesji sprawia, że who, w i niektóre narzędzia audytowe raportują ją zaniżoną, a program, który później zamknie ten sam wpis, może w ogóle zawieść. Ogranicz narzędzie do własnej sesji, zachowaj kopię oryginalnego pliku i nie rób z niego usługi startowej, która usuwa każdy wpis.

Jeśli twoja organizacja zbiera ewidencję sesji na potrzeby zgodności, to obejście koliduje z tym wymogiem, a wspieraną odpowiedzią jest wersja klienta lub inna metoda dostępu, nie załatany utmp. Dla większości najmniej inwazyjnym rozwiązaniem jest po prostu uruchomienie klienta z sesji, która pozostanie otwarta przez cały dzień, i nie ruszanie tego okna.

Zanim zamkniesz zgłoszenie, zapisz, którą sesję klient obserwował w chwili podniesienia tunelu. Ten jeden wiersz zamienia tajemnicze rozłączenie w powtarzalny warunek dla następnej osoby przy tej maszynie.