systemd-socket-proxyd może przeżyć swój tunel SSH SOCKS

Dopasuj cykl życia pomocnika przekazywania gniazd do zależności SSH, aby martwy tunel nie pozostawił zdrowo wyglądającego frontu.

Jeśli port frontowy przyjmuje połączenia po zakończeniu SSH, sprawdź wszystkie trzy jednostki. Gniazdo aktywacji, pomocnik systemd-socket-proxyd i nasłuchiwacz SOCKS utworzony przez SSH mają różne czasy życia:

GniazdoPomocnikSSHInterpretacja
NasłuchujeNieaktywnyNieaktywnyMoże normalnie czekać na żądanie
NasłuchujeAktywnyAktywnyProcesy istnieją; kondycja kolejnego celu pozostaje nieudowodniona
NasłuchujeAktywnyNieaktywnyFront może przyjmować pracę bez swojego zaplecza

Wspólne uruchomienie pomocnika i SSH nie definiuje późniejszego przejścia zatrzymania. Dla pomocnika, który nie może pozostać aktywny bez swojego tunelu, systemd dokumentuje silniejszą relację:

[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.service

Zastosuj to do odpowiedniej jednostki w rzeczywistym projekcie. Requires= i kolejność rozwiązują tylko część relacji. Już aktywny front może w przeciwnym razie nigdy nie wyzwolić ponownej aktywacji po zniknięciu zaplecza. Sprawdź też stan nieudanych jednostek i limity szybkości uruchamiania; zależności nie unieważniają tych limitów.

Następnie ustal gotowość startową. After= porządkuje zadania, a nie gotowość Type=simple nasłuchiwacza SSH. Stałe opóźnienie może zawieść przy wolnej autoryzacji. Użyj kontraktu startowego ustalającego wymagany nasłuchiwacz; ExitOnForwardFailure=yes wychwytuje błąd konfiguracji przekazywania, a nie późniejszą osiągalność celu.

Na koniec zdefiniuj wyjście bezczynności i ponowną aktywację. Opcja wyjścia bezczynności demona przekazywania dotyczy braku aktywnych połączeń, a nie braku bajtów na otwartym połączeniu. Cicha sesja może utrzymywać go aktywnym. Kolejne żądanie powinno aktywować wymagane usługi, a pętle restartów powinny pozostać ograniczone i widoczne. Odtworzenie nasłuchiwacza przyjmuje nowe połączenia; nie przywraca starych sesji TCP przez proxy.

Powiązane artykuły