systemd-socket-proxyd může přežít svůj SSH SOCKS tunel
Slaďte životní cyklus pomocníka pro přesměrování socketu s jeho závislostí na SSH, aby mrtvý tunel nezanechal zdravě vypadající前端。
Pokud vstupní port po ukončení SSH stále přijímá spojení, prozkoumejte všechny tři unity. Aktivační socket, pomocník systemd-socket-proxyd a SOCKS naslouchač vytvořený SSH mají odlišné životnosti:
| Socket | Pomocník | SSH | Výklad |
|---|---|---|---|
| Naslouchá | Neaktivní | Neaktivní | Může normálně čekat na poptávku |
| Naslouchá | Aktivní | Aktivní | Procesy existují; zdraví cíle dál zůstává neprokázané |
| Naslouchá | Aktivní | Neaktivní | Frontend může přijímat práci bez svého backendu |
Společné spuštění pomocníka a SSH neurčuje pozdější přechod do zastavení. Pro pomocníka, který nesmí zůstat aktivní bez tunelu, systemd dokumentuje silnější vztah:
[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.serviceV reálném návrhu jej použijte na příslušný unit. Requires= a řazení řeší jen část vztahu. Již aktivní frontend už jinak nemusí nikdy znovu vyvolat aktivaci poté, co jeho backend zmizí. Zkontrolujte také stav selhaných unitů a limity rychlosti spouštění; závislosti tyto limity nepřekonávají.
Dále zajistěte připravenost při startu. After= řadí úlohy, ne připravenost SSH naslouchače Type=simple. Pevné čekání může při pomalé autentizaci selhat. Použijte startovní kontrakt, který vytvoří potřebný naslouchač; ExitOnForwardFailure=yes zachytí selhání nastavení přesměrování, nikoli pozdější dostupnost cíle.
Nakonec definujte ukončení při nečinnosti a reaktivaci. Volba ukončení při nečinnosti daemonu přesměrování se týká nepřítomnosti aktivních spojení, ne nedostatku bajtů na otevřeném spojení. Tiché sezení jej může udržet aktivní. Další poptávka by měla aktivovat potřebné služby a restartovací smyčky by měly zůstat omezené a viditelné. Znovuvytvoření naslouchače připustí nová spojení; neobnoví stará proxyovaná TCP sezení.