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-сессии.

Похожие статьи