Maaaring mabuhay nang mas matagal ang systemd-socket-proxyd kaysa sa SSH SOCKS tunnel nito
Itugma ang siklo ng buhay ng socket-forwarding helper sa dependency sa SSH, upang ang patay na tunnel ay hindi mag-iwan ng mukhang malusog na harapan.
Kung tumatanggap pa ng mga koneksyon ang front port pagkatapos lumabas ng SSH, siyasatin ang lahat ng tatlong unit. Ang activation socket, ang systemd-socket-proxyd helper at ang SOCKS listener na ginawa ng SSH ay may magkaibang tagal ng buhay:
| Socket | Helper | SSH | Pagpapakahulugan |
|---|---|---|---|
| Nakikinig | Hindi aktibo | Hindi aktibo | Maaaring normal na naghihintay ng pangangailangan |
| Nakikinig | Aktibo | Aktibo | May mga proseso; hindi pa napatunayan ang kalusugan ng susunod na destinasyon |
| Nakikinig | Aktibo | Hindi aktibo | Maaaring tumanggap ng trabaho ang harapan nang walang backend nito |
Ang pagsisimula ng helper at SSH nang sabay ay hindi tumutukoy sa huling paglipat ng paghinto. Para sa helper na hindi dapat manatiling aktibo nang walang tunnel, idinodokumento ng systemd ang mas matibay na ugnayan:
[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.serviceIlapat ito sa angkop na unit sa aktwal na disenyo. Ang Requires= at pagkakasunud-sunod ay tumutugon lamang sa bahagi ng ugnayan. Ang harapang aktibo na ay maaaring hindi na kailanman mag-trigger ng activation pagkatapos mawala ang backend nito. Suriin din ang estado ng nabigong unit at ang mga limitasyon sa rate ng pagsisimula; hindi binabalewala ng mga dependency ang mga limitasyong iyon.
Pagkatapos, itatag ang kahandaan sa pagsisimula. Ang After= ay nag-aayos ng mga trabaho, hindi ang kahandaan ng isang Type=simple SSH listener. Ang nakapirming pagtulog ay maaaring mabigo sa mabagal na pagpapatunay. Gumamit ng kontrata sa pagsisimula na nagtatatag ng kinakailangang listener; hinuhuli ng ExitOnForwardFailure=yes ang pagkabigo sa pag-set up ng pagpapasa, hindi ang susunod na maabot ng destinasyon.
Sa wakas, tukuyin ang paglabas kapag walang ginagawa at ang muling pag-activate. Ang opsyon sa paglabas kapag walang ginagawa ng forwarding daemon ay tungkol sa kawalan ng aktibong koneksyon, hindi sa kakulangan ng mga byte sa bukas na koneksyon. Maaaring panatilihin itong aktibo ng tahimik na sesyon. Dapat i-activate ng susunod na pangangailangan ang mga kinakailangang serbisyo, at ang mga loop ng restart ay dapat manatiling may hangganan at nakikita. Ang muling paggawa ng listener ay tumatanggap ng mga bagong koneksyon; hindi nito ibinabalik ang mga lumang TCP session na na-proxy.