Іноді SSH перестає працювати, хоча сервер доступний, вебсайт відкривається, а сам SSH-сервіс активний.
У такій ситуації причина може бути не в збої сервера, а в захисних правилах firewall.
Один із практичних сценаріїв - автоматичні SSH-тунелі після втрати з’єднання намагаються відновити його занадто часто. Якщо сервер використовує UFW із правилом LIMIT для SSH, серія повторних спроб може призвести до відхилення нових підключень з тієї самої IP-адреси.
1. Перевірка блокувань UFW
sudo journalctl -k --since "1 hour ago" --no-pager \ | grep 'UFW LIMIT BLOCK' \ | grep 'DPT=22' \ | tail -20Повідомлення [UFW LIMIT BLOCK] для порту 22 підтверджують, що firewall відхиляє нові підключення через обмеження частоти.
Це важлива межа діагностики: сервер не "впав", а захист свідомо не приймає частину нових спроб.
2. Перевірка автоматичних SSH-тунелів
systemctl --user show my-ssh-tunnel.service \ -p ActiveState \ -p NRestarts \ -p RestartUSecВелика кількість перезапусків разом із коротким інтервалом між ними може пояснювати постійні спроби підключення.
Кожна спроба окремо є нормальною, але серія дуже швидких перепідключень починає конфліктувати із захисним обмеженням сервера.
Автоматичне відновлення саме може створити проблему
Автоматичний тунель потрібен саме для надійності: якщо з’єднання розірвалося, служба повинна підняти його знову.
Але без достатньої паузи короткий мережевий збій може створити цикл: тунель падає, systemd майже одразу запускає SSH знову, мережа ще не відновилася, служба знову падає, а наступна спроба приходить через кілька секунд.
Після серії таких підключень UFW LIMIT може почати блокувати вже й ручний адміністративний вхід.
3. Збільшення інтервалу перепідключення
[Service]Restart=on-failureRestartSec=90sТут важливі не конкретні 90 секунд, а сам принцип: повторні спроби не повинні йти настільки часто, щоб конфліктувати з серверним обмеженням частоти.
Перечитування конфігурації без зайвого перезапуску тунелю
systemctl --user daemon-reloaddaemon-reload дозволяє systemd перечитати змінені unit-файли без примусового перезапуску активного тунелю.
Новий RestartSec буде використаний під час наступного автоматичного перезапуску служби.
Перевірка результату
Після збільшення інтервалу потрібно перевірити дві окремі речі: нові адміністративні SSH-підключення знову проходять, а автоматичні тунелі залишаються активними.
Виправлення не повинно полягати у вимкненні самого механізму, заради якого тунелі були створені.
systemctl --user is-active \ my-ssh-tunnel.service ss -lntНе починайте з послаблення firewall
Якщо UFW LIMIT спрацював через агресивний цикл перепідключення, послаблення захисту лікує симптом, а не причину.
У такому сценарії не потрібно вимикати UFW, прибирати захисне правило або перезавантажувати сервер лише для того, щоб відновити SSH.
Спочатку варто зменшити частоту автоматичних спроб і перевірити результат.
Для складніших сценаріїв використовуйте поступове збільшення затримки
Фіксований RestartSec добре підходить для простого тунелю.
Якщо з’єднання може бути недоступним довше, корисно поступово збільшувати паузу після кожної невдалої спроби, наприклад 10, 30, 60 і 120 секунд із верхньою межею.
Це зменшує навантаження під час тривалого збою і не створює нескінченного потоку нових SSH-підключень.
Головний висновок
Автоматичне відновлення з’єднання теж потребує обмежень.
Надто агресивні повторні спроби можуть конфліктувати із захистом сервера і фактично заблокувати адміністратора.
Для SSH-тунелів варто налаштовувати достатню затримку між спробами, а для складніших сценаріїв - поступове збільшення цієї затримки.
Механізм автоматичного відновлення не повинен створювати більше повторних підключень, ніж захисний шар сервера готовий прийняти.
