Ако предниот порт прима врски откако SSH ќе излезе, проверете ги сите три единици. Активацискиот сокет, systemd-socket-proxyd помошникот и SOCKS слушачот создаден од SSH имаат различен животен век:

СокетПомошникSSHТолкување
СлушаНеактивенНеактивенМоже нормално да чека побарувачка
СлушаАктивенАктивенПроцесите постојат; здравјето на следната дестинација останува недокажано
СлушаАктивенНеактивенПредниот дел може да прифати работа без својот заден дел

Заедничкото стартување на помошникот и SSH не ја дефинира подоцнежната транзиција на запирање. За помошник што не смее да остане активен без својот тунел, systemd документира посилна врска:

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

Применете го на соодветната единица во вистинскиот дизајн. Requires= и редоследот покриваат само дел од врската. Веќе активниот преден дел инаку може никогаш повторно да не активира откако неговиот заден дел ќе исчезне. Проверете ја и состојбата на неуспешни единици и ограничувањата на стапката на стартување; зависностите не ги надминуваат тие ограничувања.

Следно, воспоставете подготвеност за стартување. After= подредува задачи, а не подготвеност на Type=simple SSH слушач. Фиксно спиење може да пропадне при бавна автентикација. Користете договор за стартување што го воспоставува потребниот слушач; ExitOnForwardFailure=yes фаќа неуспех при поставување на преносот, а не подоцнежна достапност на дестинацијата.

Конечно, дефинирајте излез при мирување и повторно активирање. Опцијата за излез при мирување на демонот за пренос се однесува на отсуство на активни врски, а не на недостаток на бајти на отворена врска. Тихата сесија може да го одржува активен. Следната побарувачка треба да ги активира потребните услуги, а циклусите за рестартирање треба да останат ограничени и видливи. Повторното создавање на слушачот прифаќа нови врски; тоа не ги враќа старите проксирани TCP сесии.

Поврзани статии