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-сесії.