vpn.persistent wciąż próbuje, ale nie utrzymuje połączenia

NetworkManager udostępnia jedną właściwość, vpn.persistent, a ludzie proszą ją o odpowiedź na cztery różne pytania naraz. Jej dokumentacja źródłowa jest ostrożna: trwałość obowiązuje, gdy usługa VPN ją obsługuje, a profil ją włącza, i wtedy połączenie ma przetrwać zmiany łącza i przerwy aż do jawnego rozłączenia. Ta sama dokumentacja pokazuje też, że właściwość domyślnie ma wartość false, czego większość planów odzyskiwania nie zakłada. Czytaj to jako prośbę o próbę, a nie obietnicę wyniku.

Do czego ustawienie naprawdę zobowiązuje

Wartość zapisana w profilu jest instrukcją dla menedżera, a menedżer musi przekazać tę instrukcję wtyczce VPN, która wie, co z nią zrobić. Jeśli zainstalowana wtyczka ignoruje właściwość, profil i tak się aktywuje, a dziennik pozostaje cichy, co jest najgorszym z obu światów dla każdego, kto będzie później debugował. Nic w profilu nie może zmusić wtyczki do zaimplementowania zachowania, którego ona nie ma, więc jedynym widocznym wynikiem jest brak.

Dlatego warunek w dokumentacji jest ważniejszy niż przełącznik. Sprawdź, którą wtyczkę i które wydanie naprawdę masz, i zapisz wersję obok opisu połączenia, aby następna osoba nie musiała odkrywać jej od nowa. Polityka odzyskiwania zbudowana na niezaimplementowanej fladze zawodzi w produkcji dokładnie raz i zawsze w najmniej dogodnym momencie.

Traktowanie właściwości jako próby ustawia też właściwe oczekiwanie wobec testów. Nie sprawdzasz, czy flaga jest ustawiona; sprawdzasz, czy coś się stało, gdy łącze padło. To różne eksperymenty i tylko jeden z nich jest wart popołudnia.

Cztery pytania scalone w jedno

Aktywacja pyta, co w ogóle podnosi VPN. Profil NetworkManager można powiązać z połączeniem bazowym, osobno zarządzana usługa OpenVPN ma własny start, a dodanie trzeciego programu uruchamiającego do tego układu daje dwóch właścicieli o różnych poglądach na to, kto rządzi. Zdecyduj, który komponent jest właścicielem startu, zanim dodasz kolejny wyzwalacz.

Odzyskiwanie pyta, co się dzieje, gdy łącze się zmienia lub znika, i to jest wąskie pytanie, którym zajmuje się vpn.persistent. Żywotność pyta, czy klient potrafi rozpoznać, że druga strona przestała odpowiadać, a zamiast tego odpowiada na to zachowanie keepalive lub restartu OpenVPN; oba mechanizmy są często opisywane tym samym słowem i implementowane w różnych miejscach. Testuj je osobno, różnymi narzędziami, inaczej przypiszesz jedno zachowanie drugiemu.

Intencja pyta, czy ponowne połączenie jest w ogóle pożądane, i to jest pytanie, na które sondowanie stanu nie potrafi odpowiedzieć. Celowe zatrzymanie i awaria dają ten sam stan nieaktywny, więc wszystko, co łączy się ponownie przy braku, zgaduje ludzką decyzję. Zgadywanie jest w porządku aż do chwili, gdy kogoś pomija.

Lista kontrolna, która je rozdziela

Wykonuj zdarzenia po kolei, zamiast czytać konfigurację i rozumować o niej, i zapisuj, co pokazuje każde z nich, ze znacznikiem czasu.

Po pierwsze, aktywuj zamierzone połączenie bazowe i potwierdź, że VPN podniósł się przez oczekiwany wyzwalacz, a nie przez mechanizm, o którym zapomniałeś, że jest zainstalowany. Po drugie, podczas zatwierdzonej przerwy porównaj zdarzenia VPN menedżera, stan odzyskiwania klienta będącego właścicielem i nowe żądanie do prywatnego zasobu. Po trzecie, rozłącz się celowo, odczekaj i potwierdź, że nic nie restartuje profilu za twoimi plecami.

Trzeci krok jest tym, który ludzie pomijają, i to on najczęściej znajduje prawdziwy defekt. Watchdog, który sonduje aktywny profil i łączy się ponownie, gdy go nie ma, wesoło cofnie celowe rozłączenie użytkownika. Z perspektywy użytkownika to nie odporność; to maszyna, która nie będzie posłuszna. Zapytaj ich, zanim taką dodasz.

Zapisz wyniki w tym samym dokumencie co opis połączenia. Polityka odzyskiwania jest warta tyle, ile ostatni raz, gdy ktoś zobaczył, jak celowo zawodzi. Znaczniki czasu czynią różnicę widoczną dla każdego, kto przeczyta notatki następnym razem.

Uwierzytelnianie jest częścią odzyskiwania

Ponowne łączenie nie jest czysto sieciową czynnością. Jeśli zatwierdzony przepływ wymaga nowego wyzwania, jednorazowego kodu lub sekrety, do której kontekst aktywacji nie może dotrzeć, żadne ustawienie trwałości nie wytworzy jej z niczego.

To wyjaśnia znany schemat: połączenie odzyskuje się na maszynie z odblokowanym pękiem kluczy i zawodzi na tej samej maszynie po restarcie. Warstwa sieciowa zrobiła dokładnie to, o co proszono, a warstwa danych uwierzytelniających nie miała nic do zaoferowania.

Napraw przepływ danych uwierzytelniających zamiast skracać interwał ponowień. Szybsze ponowienia wobec monitu, na który nikt nie potrafi odpowiedzieć, generują szum w dzienniku i fałszywe wrażenie, że coś jest próbowane.

Trwałość nie jest kill switchem

Właściwość próbuje zachować lub przywrócić relację VPN. Nie decyduje, co mogą robić aplikacje, gdy VPN jest wyłączony, i sama niczego nie blokuje.

Jeśli wymaganiem jest, aby żaden ruch nie wychodził poza tunel, to jest osobna polityka z własnym mechanizmem, własnymi testami i własnymi trybami awarii. Założenie, że trwałość to obejmuje, zamienia decyzję bezpieczeństwa w wypadek.

Zapisz obie połowy w notatkach odzyskiwania: czego próbował VPN i jaki ruch aplikacji był dozwolony podczas próby.