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

СокетПомощникSSHТълкуване
СлушаНеактивенНеактивенВъзможно е нормално да чака заявка
СлушаАктивенАктивенИма процеси; здравето на крайната дестинация остава недоказано
СлушаАктивенНеактивенФронтендът може да приема работа без своя бекенд

Съвместното стартиране на помощника и SSH не определя по-късния преход към спиране. За помощник, който не бива да остава активен без тунела си, systemd документира по-силната връзка:

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

Приложете я към подходящия unit в реалния дизайн. Requires= и подредбата покриват само част от връзката. Вече активен фронтенд иначе може никога повече да не задейства активиране, след като бекендът му изчезне. Проверете също състоянието на неуспешните unit-и и ограниченията за скорост на стартиране; зависимостите не отменят тези ограничения.

След това осигурете готовност при стартиране. After= подрежда задачи, а не готовността на SSH слушател Type=simple. Фиксирано изчакване може да се провали при бавна автентикация. Използвайте договор за стартиране, който установява нужния слушател; ExitOnForwardFailure=yes улавя провал при настройка на препращането, а не последващата достъпност на дестинацията.

Накрая определете изход при бездействие и повторно активиране. Опцията за изход при бездействие на демона за препращане засяга липсата на активни връзки, а не липсата на байтове по отворена връзка. Тих сеанс може да го държи активен. Следващото търсене трябва да активира нужните услуги, а циклите на рестартиране трябва да останат ограничени и видими. Пресъздаването на слушателя допуска нови връзки; то не възстановява стари проксирани TCP сеанси.

Подобни статии