Jak długo OpenConnect powinien ponawiać próby zerwanego VPN?

--reconnect-timeout odpowiada na jedno wąskie pytanie: po upadku tunelu jak długo ten proces klienta próbuje dalej, zanim się podda i zakończy. Strona podręcznika OpenConnect odnotowuje tę opcję z udokumentowaną wartością domyślną 300 sekund dla ponownych prób następujących po utracie łącza lub po peerze, który przestał odpowiadać, a liczba jest terminem dla jednego działającego klienta, nie dowodem, że VPN pozostaje osiągalny. To także nie polityka utrzymywania procesu przy życiu, i właśnie tam zaczyna się większość zamieszania.

Zamieszanie rośnie, gdy na wierzchu siedzi drugi mechanizm. Nadzorca restartujący klienta, próbnik pingujący bramę i wbudowane okno ponownych prób mogą wszyscy reagować na jedną awarię, a incydent daje wtedy trzy osie czasu, których nikt nie potrafi pogodzić.

Co faktycznie ogranicza okno ponownego połączenia

Wyobraź sobie, że sieć dostępowa znika na kilka sekund. Klient widzi zerwanie łącza albo przestaje słyszeć odpowiedzi martwego peera i zaczyna odbudowywać sesję, trzymając tyle stanu, ile może. Próby trwają, dopóki brama znowu nie zaakceptuje albo okno się nie skończy, a skończone okno kończy się wyjściem niezerowym. To właśnie to wyjście, a nie wartość limitu czasu, jest miejscem, w którym własność cyklu życia przechodzi na tego, kto nadzoruje proces.

Okno nic nie mówi o tym, jak często uruchamiany jest próbnik, i nie może przedłużyć uwierzytelniania. Jeśli brama unieważniła sesję albo konto wymaga teraz nowego drugiego czynnika, dłuższe czekanie nie sprawi, że stara sesja znów będzie ważna. Ponowna próba udaje się tylko wtedy, gdy ścieżka wraca, brama nadal rozpoznaje sesję i wymagane dane uwierzytelniające pozostają użyteczne, więc czytaj tę liczbę jako termin, a nie jako interwał żywotności.

Okno nie reguluje też tego, co robią aplikacje, gdy trwa. W zależności od platformy i od tego, jak daleko zaszła awaria, klient może łączyć się ponownie, gdy trasy są jeszcze zainstalowane, albo po ich wycofaniu. Dlatego żądanie wydane w środku przerwy zwykle wisi do limitu czasu, zamiast szybko zawodzić.

Restarty nadzorcy i ponowne próby klienta to dwie warstwy

Pozwól działającemu klientowi zużyć własne okno, a menedżerowi usług reagować na wyjście. Klient na pierwszym planie pod systemd z polityką restartu daje dokładnie taki podział: próby przez ograniczony czas, potem jedna decyzja o restarcie. Wynikiem jest jedna oś czasu, którą nadal można później odtworzyć.

Klient w tle plus niezależny próbnik, który uruchamia kolejną kopię, gdy nie widzi interfejsu, to wzorzec, który się psuje. Wtedy oba procesy rywalizują o ten sam węzeł urządzenia, trasy i ustawienia resolvera. Jeśli naprawdę chcesz demona, umieść opcję w wierszu poleceń, z którym klient faktycznie startuje:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Dwa szczegóły w tym wierszu mają wagę. --background odłącza proces, więc plik pid staje się jedynym pewnym uchwytem do niego, a limit czasu zużywa się tylko dopóki ten sam proces żyje; nadzorca, który go zabije, nie zostawia budżetu na kontynuację.

Celowe rozłączenia potrzebują własnego sygnału. Zaplanowana pauza i prawdziwa awaria wyglądają identycznie dla naiwnego obserwatora, obie są czytane jako „brak połączenia”. Prowadź pauzę przez operację zatrzymania nadzorcy albo znacznik rozumiany przez otoczkę, żeby celowe zatrzymanie nie wywołało restartu, o który nikt nie prosił.

Jak nie dopuścić, by przekazanie ścigało się z pętlą ponownych prób

Nienadzorowane odzyskiwanie zależy od danych uwierzytelniających odnawianych bez obecnej osoby. Pęk kluczy, który otwiera się tylko w interaktywnej sesji pulpitu, albo token, który zawsze wymaga wpisanego kodu, zostawi klienta uwięzionego na etapie uwierzytelniania, gdy ścieżka wróci. Uporządkuj ten przepływ pracy przed wydłużeniem okna, bo dłuższe okno daje tylko temu samemu zablokowanemu monitowi więcej czasu na porażkę.

Weryfikacji serwera nie należy łagodzić, by zmniejszyć liczbę monitów. Właśnie przypięcie lub kotwica zaufania, która waliduje bramę, czyni automatyczne ponowne połączenie bezpiecznym, a wyłączenie jej, by uniknąć pytania o certyfikat, zamienia widoczną przerwę na niewidoczną. Zachowaj zweryfikowaną tożsamość i zamiast tego napraw monit; klient gotów łączyć się z dowolną bramą jest gorszy od tego, który się zatrzymuje i czeka.

Obecność interfejsu również nie jest sygnałem zdrowia. Urządzenie tunelowe może istnieć z martwą sesją za nim, a proces uruchamiający może istnieć bez żadnego tunelu. Żadna z tych obserwacji nie wytrzymuje prawdziwego żądania. Zdrowie musi pochodzić z tego, czego potrzebuje użytkownik, na przykład z żądania, które przechodzi przez tunel do znanej usługi wewnętrznej.

Co weryfikować podczas awarii i po niej

Wykonaj cztery zdarzenia jako osobne testy: przerwę krótszą od okna, awarię dłuższą od niego, błąd uwierzytelniania i celowe zatrzymanie. Każde powinno skończyć się w innym, przewidywalnym stanie, a granica między pierwszymi dwoma jest całym powodem wyboru wartości.

Trzymaj kontrole skierowane na zewnątrz, bo tabela procesów sama w sobie dowodzi bardzo niewiele. Obserwuj, czy pid pozostaje stabilny podczas krótkiej przerwy, a potem potwierdź, że po długiej zniknął i został raz zastąpiony:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Podczas krótkiej przerwy potwierdź, że klient naprawdę ponowił próbę, a nie zakończył się wcześnie, i że trasy oraz wpisy resolvera wróciły bez duplikatów. Dla dłuższej awarii potwierdź czyste wyjście i dokładnie jeden restart po nim. Dla błędu uwierzytelniania potwierdź, że klient nie kręci się wobec bramy, która będzie go dalej odrzucać. Dodaj kontrolę, że pid wraca do jednej wartości, zamiast się gromadzić.

Dla celowego zatrzymania adres URL zdrowia powinien pozostać nieosiągalny, a proces powinien pozostać wyłączony. Następnie zamknij pętlę od strony aplikacji: to samo żądanie musi zawieść, gdy tunelu nie ma, i musi się udać po jego powrocie, z adresu źródłowego, którego oczekuje twoja polityka. Zielona ikona tunelu nie jest dowodem, ale ukończone żądanie jest.