OpenVPN: lokalne bindowanie zawodzi przy starcie — czekać czy ponawiać

Dla serwera OpenVPN, który nie startuje przy bootowaniu, proponuje się dwa rozwiązania: czekać na adres albo pozwolić usłudze ponawiać próbę, aż bindowanie się powiedzie. Oba rozwiązują ten sam objaw z innym zachowaniem przy awarii. Oczekiwanie koduje konkretny warunek wstępny i głośno zawodzi, gdy go brakuje; ponawianie ukrywa warunek i próbuje dalej. To, które należy do twojej jednostki, zależy od tego, czy adres jest zaprojektowaną zależnością, czy przypadkiem timingu.

Oba są lepsze od stałego snu, który na nic nie czeka i nie informuje, na co czekał.

Czego naprawdę wymaga opcja local

local wskazuje adres, do którego demon binduje swój socket, a bindowanie do jeszcze nieistniejącego adresu od razu zawodzi z błędem o żądanym adresie. Gdy opcji brakuje, demon nasłuchuje na wszystkich adresach, dlatego ten sam profil działa na maszynie, której interfejs jeszcze się nie podniósł: nasłuchuje wszędzie zamiast na jednym adresie, który podałeś. Ta różnica to cała awaria i pozostaje niewidoczna do restartu.

Wymaganie nie polega na tym, by interfejs był podniesiony w ogólnym sensie. Adres musi być przypisany do właściwego interfejsu w momencie bindowania i musi to być interfejs bazowy, a nie tunel, który ten sam demon utworzyłby później. Sprawdzenie wykonane kilka minut po zalogowaniu niczego nie dowodzi o sekwencji bootowania.

Czekać na adres czy ponawiać bindowanie

Oczekiwanie oznacza ExecStartPre, który odpytuje, aż adres się pojawi, z ograniczoną liczbą prób i niezerowym wyjściem, gdy czas się skończy. Ponawianie oznacza pozwolenie procesowi głównemu na porażkę i poproszenie menedżera usług o ponowne uruchomienie, na przykład Restart=on-failure z RestartSec=5. Pierwszy zgłasza brakujący warunek wstępny jako nieudaną jednostkę, drugi zgłasza go jako serię restartów, która w końcu się zatrzymuje, co jest głośniejsze w dzienniku, ale przetrwa adres, który przychodzi późno z przyczyn, których nie możesz przewidzieć.

Preferuj oczekiwanie, gdy adres jest zaprojektowaną zależnością, a ponawianie, gdy adres zwykle się pojawia, ale jego timing się zmienia. Łączenie ich jest rozsądne: ograniczone oczekiwanie pokrywa zwykły przypadek, a polityka restartu wyjątek. Żadne z nich nie powinno działać wiecznie, bo jednostka, która ponawia bez końca, ukrywa błędną konfigurację zamiast ją zgłaszać.

Dlaczego network-online.target nie wystarcza

network-online.target obiecuje to, co aktywna implementacja sieci rozumie przez online, i nic więcej. W systemd-networkd systemd-networkd-wait-online decyduje, kiedy ten cel zostanie osiągnięty, a jego domyślne pojęcie online może być spełnione, zanim twój konkretny adres istnieje. W NetworkManager usługa wait-online stosuje własne reguły. Ustawianie kolejności po celu to solidna podstawa, a nie gwarancja, że jeden adres, odpowiedź DNS lub zdalny partner jest gotowy.

To samo rozumowanie wyklucza zwykłe alternatywy. Wpis autostartu na pulpicie czeka na sesję użytkownika, która na serwerze może nigdy się nie otworzyć, a opóźnione polecenie cron dodaje upływ czasu bez wskazania zasobu, którego pojawienia się oczekiwało. Oba mogą przez miesiące wyglądać na udane, a potem zawieść przy jednym jedynym starcie, który ma znaczenie.

Sprawdź bindowanie po zimnym starcie

Weryfikuj prawdziwym zimnym startem, a nie restartem usługi, bo restart dziedziczy adres, który sekwencja bootowania musiała utworzyć. Po starcie ss -lntp lub ss -lunp pokazuje lokalny adres, do którego każdy nasłuchujący faktycznie się zbindował, a journalctl -b -u openvpn-server@server pokazuje, czy pierwsza próba nie powiodła się. Porównaj zbindowany adres z tym z profilu, a następnie powtórz porównanie po ponownym połączeniu z siecią.

Jeśli profil nigdy nie potrzebował stałego adresu, usunięcie local jest uzasadnionym uproszczeniem, ale zrób z tego decyzję bezpieczeństwa, a nie nawyk diagnostyczny.

Poszerzenie nasłuchu zmienia to, kto może do niego dotrzeć, więc połącz tę zmianę z polityką firewalla, która powinna była go ograniczać. Usługa, która niezawodnie startuje na każdym interfejsie, nie rozwiązała pierwotnego problemu; przeniosła problem na krawędź sieci.