systemd-socket-proxyd può sopravvivere al suo tunnel SSH SOCKS
Allinea il ciclo di vita dell'ausiliario di inoltro socket alla sua dipendenza da SSH, così un tunnel morto non lasci un front end dall'aria sana.
Se la porta frontale accetta ancora connessioni dopo l'uscita di SSH, esamina tutte e tre le unità. Il socket di attivazione, l'ausiliario systemd-socket-proxyd e l'ascoltatore SOCKS creato da SSH hanno durate diverse:
| Socket | Ausiliario | SSH | Interpretazione |
|---|---|---|---|
| In ascolto | Inattivo | Inattivo | Forse attende normalmente la richiesta |
| In ascolto | Attivo | Attivo | I processi esistono; la salute della destinazione finale resta non provata |
| In ascolto | Attivo | Inattivo | Il front end può accettare lavoro senza il suo backend |
Avviare insieme l'ausiliario e SSH non definisce la successiva transizione di arresto. Per un ausiliario che non deve restare attivo senza il tunnel, systemd documenta la relazione più forte:
[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.serviceApplicala all'unità appropriata nel progetto reale. Requires= e l'ordinamento coprono solo una parte della relazione. Un front end già attivo potrebbe altrimenti non innescare mai più l'attivazione dopo la scomparsa del backend. Controlla anche lo stato delle unità fallite e i limiti di frequenza di avvio; le dipendenze non annullano quei limiti.
Poi stabilisci la prontezza all'avvio. After= ordina i lavori, non la prontezza di un ascoltatore SSH Type=simple. Un'attesa fissa può fallire durante un'autenticazione lenta. Usa un contratto di avvio che stabilisca l'ascoltatore richiesto; ExitOnForwardFailure=yes intercetta un errore di configurazione dell'inoltro, non la raggiungibilità successiva della destinazione.
Infine, definisci l'uscita per inattività e la riattivazione. L'opzione di uscita per inattività del demone di inoltro riguarda l'assenza di connessioni attive, non la mancanza di byte su una connessione aperta. Una sessione silenziosa può tenerlo attivo. La richiesta successiva dovrebbe attivare i servizi necessari, e i cicli di riavvio dovrebbero restare limitati e visibili. Ricreare l'ascoltatore ammette nuove connessioni; non ripristina le vecchie sessioni TCP proxate.