Ponowne łączenie klienta OpenVPN: trzy mechanizmy, trzy zakresy

Ktoś prosi o ponowne połączenie klienta VPN, a ta prośba może znaczyć trzy różne rzeczy. Może znaczyć odrzucenie jednej uwierzytelnionej sesji, powiadomienie każdego klienta, że serwer UDP znika, albo restart samego demona. Każda ma inny promień rażenia, a zły wybór zamienia poprawkę dla jednego użytkownika w awarię. Zakres jest decyzją, a polecenie z niej wynika.

Zapytaj, kogo to ma dotyczyć, zanim zapytasz, którego mechanizmu użyć.

Jedna instancja: interfejs zarządzania

Skonfigurowany interfejs zarządzania może wylistować połączone instancje i odrzucić dokładnie jedną z nich. Każda sesja niesie identyfikator klienta, a client-kill CID celuje w ten identyfikator, a nie we wspólną nazwę. Czytaj żywy identyfikator z bieżącego wyjścia stanu, ponieważ wartość skopiowana ze starszego logu odnosi się do sesji, która już nie istnieje. Odrzucenie instancji kończy to połączenie i nic więcej.

To nie gwarantuje nowego połączenia. Czy klient wróci, zależy od jego ustawień ponawiania, pozostałych wpisów zdalnych, wymagań uwierzytelniania i od tego, czy aplikacja nadzorująca nadal działa. Wracający klient otrzymuje nowy identyfikator, dlatego porównywanie identyfikatorów jest jedynym niezawodnym sposobem odróżnienia starego od nowego.

Powiadomienie o wyjściu UDP nie jest poleceniem dla pojedynczego klienta

explicit-exit-notify to dyrektywa konfiguracyjna dotycząca zdarzeń wyjścia i restartu. Na kliencie UDP informuje drugą stronę, że sesja się kończy, a argument liczbowy kontroluje, ile razy powiadomienie jest powtarzane. Gdy serwer działa przez UDP, wysyła komunikat sterujący restartem do połączonych klientów, a udokumentowane wartości odróżniają ponowne połączenie z tym samym serwerem od przejścia na inny wpis zdalny. To sygnał cyklu życia o szerokim odbiorze.

Nic w nim nie wybiera dowolnego klienta w dowolnym momencie. Traktowanie go jako przycisku ponownego połączenia dociera do wszystkich połączonych sesji naraz.

Sygnały działają na proces, a nie na sesję

SIGUSR1 prosi działający proces o restart połączenia bez ponownego czytania konfiguracji, a opcje trwałości decydują, co przetrwa ten restart. SIGHUP idzie dalej: ponownie czyta plik konfiguracji i ponownie otwiera swoje zasoby. SIGTERM i SIGINT proszą o uporządkowane wyłączenie. To operacje na poziomie procesu: na serwerze z wieloma klientami dotyczą każdej sesji, którą niesie proces, a nie tej wskazanej w zgłoszeniu.

Gdy proces działa pod menedżerem usług, użyj jego własnego sterowania zamiast wysyłać sygnał do PID znalezionego na liście procesów. Przeczytaj unit, aby zobaczyć, który sygnał wysyła menedżer, ponieważ restart i przeładowanie robią różne rzeczy z tym samym demonem.

Ustal zakres, zanim wybierzesz mechanizm

Trzy pytania to rozstrzygają. Kogo ma dotyczyć: jednego użytkownika, wszystkich klientów jednego serwera czy demona i wszystkiego, co niesie. Co ma przetrwać: konfiguracja, stan tunelu czy nic. Kto jest do tego uprawniony: integracja zarządzania, właściciel usługi czy operator sieci, który kontroluje powiadomienie o wyjściu. Odpowiedz na to, a pasuje tylko jeden mechanizm.

Dodanie nieuwierzytelnionego nasłuchu zarządzania, aby dostać przycisk ponownego połączenia, oddaje każdemu, kto dotrze do portu, znacznie więcej niż ten przycisk.

Zweryfikuj nową sesję, a nie rozłączenie

Zdarzenie rozłączenia dowodzi, że stara sesja się skończyła. Nie mówi nic o nowej, która się uwierzytelnia, otrzymuje adres, instaluje trasy lub dociera do zasobu, którego użytkownik potrzebował. Sprawdź nowy identyfikator, potem stan tunelu, potem jeden rzeczywisty zasób. Te trzy kroki to różnica między ponownym połączeniem a działającym połączeniem.

Zapisz zakres w rejestrze zmian. „Ponownie połączyłem klienta” nie jest opisem, gdy klient był jednym z czterdziestu na współdzielonym serwerze.