OpenVPN uruchamiany przed siecią to nie awaria

Uruchamiasz klienta przy starcie, jednostka zgłasza aktywność, a tunelu nie ma. Naturalny wniosek jest taki, że usługa nie wystartowała, a naturalną naprawą jest uruchomienie jej ponownie. Oba są błędne dość często, by zasługiwać na regułę: działający klient, który ponawia próby, wygląda z zewnątrz dokładnie jak zepsuty. Różnica tkwi w tym, co robi proces, a nie w stanie jednostki.

Mit: uruchomiona usługa oznacza działający tunel

Aktywna jednostka dowodzi, że proces został uruchomiony i nie zakończył się. Nie dowodzi, że profil się wczytał, certyfikat został przyjęty ani że druga strona odpowiedziała. Spakowany klient może minutami siedzieć w pętli ponowień, podczas gdy systemd nie zgłasza nic poza sukcesem. Ta luka między stanem a zachowaniem to cały temat.

Przypadek odwrotny jest równie częsty. Proces mógł zakończyć się po nieudanym odczycie klucza, a jednostka zgłasza wtedy stan błędu, który nic nie mówi o przyczynie. Oba stany wymagają dziennika, by je rozróżnić.

Czytaj dziennik tej instancji, a nie stan jednostki. Wiersz przyczyny jest w logu, nie w etykiecie statusu.

Mit: ustawienia ponowień obejmują każdą awarię

Rozwiązywanie nazw i ponowienia transportu to osobne elementy sterujące z osobnymi wartościami domyślnymi. resolv-retry rządzi powtarzanym wyszukiwaniem zdalnej nazwy hosta, a udokumentowana wartość domyślna próbuje bez końca. connect-retry ustala odstęp między próbami, natomiast connect-retry-max może ograniczyć, ile razy próbowany jest każdy zdalny wpis. Sprawdź, który etap wskazuje log, zanim zmienisz którykolwiek z nich.

Nic z tego nie dotyczy uszkodzonego profilu, nieczytelnego klucza prywatnego ani odrzuconego konta. One wymagają poprawki, a klient, który wciąż je ponawia, nie robi postępu.

Ponawianie niezatwierdzonego certyfikatu w nieskończoność nie jest powodem, by usuwać weryfikację. To powód, by przeczytać błąd.

Mit: jeden launcher wystarczy, więc dodaj drugi

Połączenie obsługiwane już przez NetworkManager albo spakowaną jednostkę nie potrzebuje drugiego launchera. Dwa procesy walczące o te same trasy dają zduplikowane interfejsy, mylące logi i tunel, który migocze z powodów, których nikt nie widzi. Druga kopia zwykle pojawia się jako obejście dla wolnego pierwszego.

Zdecyduj, który komponent jest właścicielem tunelu, zanim cokolwiek dodasz. Potem usuń drugi launcher, zamiast go wyłączać i mieć nadzieję.

Właściciel decyduje też, skąd pochodzą ponowienia i poświadczenia, dlatego ta decyzja wypada przed jakimkolwiek strojeniem. Własność jest pierwsza dokładnie z tego powodu.

Co naprawdę wymaga kolejności

Kolejność może poczekać na skonfigurowany adres i tylko to gwarantuje. network-online.target opóźnia aktywację, aż menedżer uzna sieć za gotową, a definicja gotowości zależy od menedżera. Nie mówi nic o tym, czy nazwa hosta VPN się rozwiązuje, czy nasłuch odpowiada ani czy portal przechwytujący wpuścił urządzenie.

Przeczytaj zainstalowaną jednostkę i wszelkie drop-iny, zanim dodasz zależności. Szeroki After= na każdej usłudze sieciowej opóźnia start, nie tworząc połączenia, którego naprawdę potrzebujesz.

Uporządkuj zależność, którą możesz przetestować, a wszystko inne sprawdź sondą gotowości. Sonda, która otwiera tunel, bije timer, który zgaduje.

Co się dzieje po pierwszym podniesieniu tunelu

Start to jedno z wielu zdarzeń. Łącze dostępowe się zmienia, sesja portalu wygasa, peer restartuje. Odróżnij wewnętrzne ponowne połączenie od wyjścia procesu, które obsługuje menedżer usług, bo oba mają innych właścicieli i zostawiają inne dowody.

Uwierzytelnianie interaktywne ogranicza odzyskiwanie bez nadzoru. Jednostka w tle nie odblokuje pęku kluczy pulpitu ani nie odpowie na prośbę MFA, więc stosuj zatwierdzony układ poświadczeń dla kontekstu usługi.

Osobno zdecyduj, co aplikacje mogą robić, gdy tunel leży. Ponowienie przywraca połączenie, a polityka blokowania decyduje, czy w tej luce dozwolony jest ruch bezpośredni.