Եթե SSH-ի դուրս գալուց հետո ճակատային պորտը դեռ ընդունում է միացումներ, ստուգեք բոլոր երեք միավորները։ Ակտիվացման socket-ը, systemd-socket-proxyd օժանդակողը և SSH-ի ստեղծած SOCKS լսողը տարբեր կյանքի տևողություններ ունեն․

SocketՕժանդակողSSHՄեկնաբանություն
Լսում էԱնգործունԱնգործունՀնարավոր է՝ սովորաբար սպասում է պահանջի
Լսում էԳործունԳործունԳործընթացներ կան․ նպատակակետի առողջությունը դեռ ապացուցված չէ
Լսում էԳործունԱնգործունՃակատը կարող է աշխատանք ընդունել առանց իր հետին մասի

Օժանդակողի և SSH-ի միասին մեկնարկը չի սահմանում հետագա կանգառի անցումը։ Այն օժանդակողի համար, որը չպետք է գործուն մնա առանց թունելի, systemd-ը փաստագրում է ավելի ամուր կապը․

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

Կիրառեք այն իրական նախագծման համապատասխան միավորի վրա։ Requires=-ը և հերթականությունը լուծում են կապի միայն մի մասը։ Արդեն գործուն ճակատը հակառակ դեպքում կարող է այլևս երբեք ակտիվացում չհրահրել, երբ նրա հետին մասը անհետանա։ Ստուգեք նաև ձախողված միավորների վիճակը և մեկնարկի արագության սահմանները․ կախվածությունները չեն վերացնում այդ սահմանները։

Այնուհետև ապահովեք մեկնարկի պատրաստվածությունը։ After=-ը դասավորում է աշխատանքները, ոչ թե Type=simple SSH լսողի պատրաստվածությունը։ Հաստատուն սպասումը կարող է ձախողվել դանդաղ նույնականացման ժամանակ։ Օգտագործեք մեկնարկի պայմանագիր, որը ստեղծում է պահանջվող լսողը․ ExitOnForwardFailure=yes-ը բռնում է փոխանցման կարգավորման ձախողումը, ոչ թե նպատակակետի հետագա հասանելիությունը։

Վերջապես սահմանեք պարապուրդի ելքը և վերաակտիվացումը։ Փոխանցման դեմոնի պարապուրդի ելքի ընտրանքը վերաբերում է գործուն միացումների բացակայությանը, ոչ թե բաց միացման վրա բայթերի պակասին։ Հանգիստ նստաշրջանը կարող է պահել այն գործուն։ Հաջորդ պահանջը պետք է ակտիվացնի անհրաժեշտ ծառայությունները, և վերագործարկման օղակները պետք է մնան սահմանափակ և տեսանելի։ Լսողի վերստեղծումը թույլ է տալիս նոր միացումներ․ այն չի վերականգնում հին պրոքսի արված TCP նստաշրջանները։

Առնչվող հոդվածներ