systemd-socket-proxyd gali pergyventi savo SSH SOCKS tunelį

Suderinkite ligzdos pāradresācijas palīga gyvavimo ciklą su SSH priklausomybe, kad miręs tunelis nepaliktų sveikai atrodančios priekinės dalies.

Jei priekinis portas priima jungtis po to, kai SSH baigia darbą, patikrinkite visus tris vienetus. Aktyvavimo lizdas, systemd-socket-proxyd pagalbininkas ir SSH sukurtas SOCKS klausytojas turi skirtingą gyvavimo laiką:

LizdasPagalbininkasSSHAiškinimas
KlausosiNeveikusNeveikusGali normaliai laukti paklausos
KlausosiVeikusVeikusProcesai egzistuoja; tolesnio tikslo būklė neįrodyta
KlausosiVeikusNeveikusPriekinė dalis gali priimti darbą be savo užnugario

Pagalbininko ir SSH paleidimas kartu neapibrėžia vėlesnio sustabdymo perėjimo. Pagalbininkui, kuris neturi likti aktyvus be savo tunelio, systemd dokumentuoja tvirtesnį ryšį:

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

Taikykite jį atitinkamam vienetui faktinėje konstrukcijoje. Requires= ir eiliškumas sprendžia tik dalį ryšio. Jau aktyvi priekinė dalis kitaip gali niekada vėl nesuaktyvinti po to, kai jos užnugaris išnyksta. Taip pat tikrinkite nepavykusių vienetų būseną ir paleidimo dažnio ribas; priklausomybės tų ribų nepanaikina.

Toliau užtikrinkite paleidimo pasirengimą. After= išdėsto užduotis, o ne Type=simple SSH klausytojo pasirengimą. Fiksuotas miegojimas gali nepavykti lėtos autentifikacijos metu. Naudokite paleidimo sutartį, kuri užtikrina reikiamą klausytoją; ExitOnForwardFailure=yes pagauna persiuntimo sąrankos gedimą, o ne vėlesnį tikslo pasiekiamumą.

Galiausiai apibrėžkite tuščiosios eigos išėjimą ir pakartotinį aktyvavimą. Persiuntimo tarnybinės programos tuščiosios eigos parinktis susijusi su aktyvių jungčių nebuvimu, o ne su baitų trūkumu atviroje jungtyje. Tylioji sesija gali ją išlaikyti aktyvią. Kita paklausa turėtų suaktyvinti reikiamas paslaugas, o perkrovimo ciklai turėtų likti riboti ir matomi. Klausytojo atkūrimas priima naujas jungtis; jis neatkuria senų perduotų TCP sesijų.

Susiję straipsniai