systemd-socket-proxyd можа перажыць свой SSH-тунэль SOCKS
Узгадніце жыццёвы цыкл памочніка перасылкі сокета з яго залежнасцю ад SSH, каб мёртвы тунэль не пакідаў здаровы з выгляду фронтэнд.
Калі ўваходны порт прымае злучэнні пасля выхаду SSH, праверце ўсе тры юніты. Сокет актывацыі, памочнік systemd-socket-proxyd і SOCKS-слухач, створаны SSH, маюць розныя тэрміны жыцця:
| Сокет | Памочнік | SSH | Тлумачэнне |
|---|---|---|---|
| Слухае | Неактыўны | Неактыўны | Магчыма, нармальна чакае запыту |
| Слухае | Актыўны | Актыўны | Працэсы ёсць; здароўе далейшага прызначэння не даказана |
| Слухае | Актыўны | Неактыўны | Фронтэнд можа прымаць працу без свайго бэкэнда |
Сумесны запуск памочніка і SSH не вызначае наступны пераход спынення. Для памочніка, які не павінен заставацца актыўным без тунэля, systemd дакументуе мацнейшую сувязь:
[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.serviceУжыце гэта да адпаведнай юніты ў рэальным дызайне. Requires= і парадак ахопліваюць толькі частку сувязі. Ужо актыўны фронтэнд інакш можа больш ніколі не выклікаць актывацыю пасля знікнення бэкэнда. Праверце таксама стан няўдалых юнітаў і ліміты частаты запуску; залежнасці не адмяняюць гэтыя ліміты.
Далей забяспечце гатоўнасць запуску. After= упарадкоўвае заданні, а не гатоўнасць SSH-слухача Type=simple. Фіксаваная паўза можа не спрацаваць пры павольнай аўтэнтыфікацыі. Выкарыстоўвайце кантракт запуску, які стварае патрэбны слухач; ExitOnForwardFailure=yes ловіць збой наладкі перасылкі, а не наступную даступнасць прызначэння.
Нарэшце вызначце выхад па прастоі і паўторную актывацыю. Опцыя выхаду па прастоі дэмана перасылкі датычыцца адсутнасці актыўных злучэнняў, а не адсутнасці байтаў у адкрытым злучэнні. Ціхая сесія можа трымаць яго актыўным. Наступны запыт павінен актываваць патрэбныя сэрвісы, а цыклы перазапуску павінны заставацца абмежаванымі і бачнымі. Перастварэнне слухача дапускае новыя злучэнні; яно не аднаўляе старыя праксіраваныя TCP-сесіі.