systemd-socket-proxyd povas postvivi sian SSH SOCKS-tunelon
Agordi la vivciklon de soket-plusendiga helpanto al ĝia SSH-dependeco, por ke morta tunelo ne lasu san-aspektan antaŭan parton.
Se la antaŭa pordo ankoraŭ akceptas konektojn post kiam SSH finiĝas, ekzamenu ĉiujn tri unuojn. La aktiviga soketo, la helpanto systemd-socket-proxyd kaj la SOCKS-aŭskultanto kreita de SSH havas apartajn vivdaŭrojn:
| Soketo | Helpanto | SSH | Interpretado |
|---|---|---|---|
| Aŭskultas | Neaktiva | Neaktiva | Eble normale atendas peton |
| Aŭskultas | Aktiva | Aktiva | Procesoj ekzistas; la sano de la fina celo restas nepruvita |
| Aŭskultas | Aktiva | Neaktiva | La antaŭa parto povas akcepti laboron sen sia malantaŭa parto |
Kune startigi la helpanton kaj SSH ne difinas la postan halttransiron. Por helpanto, kiu ne rajtas resti aktiva sen sia tunelo, systemd dokumentas la pli fortan rilaton:
[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.serviceApliku ĝin al la taŭga unuo en la reala dezajno. Requires= kaj la ordo traktas nur parton de la rilato. Jam aktiva antaŭa parto alie eble neniam plu ekigos aktivigon post kiam ĝia malantaŭa parto malaperas. Kontrolu ankaŭ la staton de fiaskintaj unuoj kaj la limojn de startrapideco; dependecoj ne superas tiujn limojn.
Poste starigu pretan starton. After= ordigas taskojn, ne la pretecon de SSH-aŭskultanto Type=simple. Fiksa atendo povas fiaski dum malrapida aŭtentikigo. Uzu startkontrakton, kiu starigas la postulatan aŭskultanton; ExitOnForwardFailure=yes kaptas fiaskon de la plusenda agordo, ne la postan atingeblon de la celo.
Fine difinu la eliron pro senaktiveco kaj la reaktivigon. La senaktiveca eliro de la plusenda demono temas pri manko de aktivaj konektoj, ne pri manko de bajtoj sur malfermita konekto. Silenta seanco povas teni ĝin aktiva. La sekva peto devus aktivigi la postulatajn servojn, kaj restartaj bukloj devus resti limigitaj kaj videblaj. Rekrei la aŭskultanton permesas novajn konektojn; ĝi ne restarigas malnovajn prokseitajn TCP-seancojn.