Ваш комментарий об обратном ssh-туннеле через некоторое время, вероятно, связан с тем, что маршрутизатор NAT пытается слишком минимизировать свою таблицу открытых соединений и должен быть разрешен с помощью директивы ServerAliveInterval, как описано в FAQ по OpenSSH.
В некоторых случаях маршрутизатор / брандмауэр все равно агрессивно сокращает ваши сеансы (плохо!) когда ссылка долгое время простаивает, что заставляет вас понизить ServerAliveInterval (см. примечание).
Хитрость в этом случае заключается в том, чтобы использовать своего рода оболочку, отслеживающую демон ssh и перезапускающую его при необходимости, autossh делает именно это, что должно решить вашу проблему прямо сейчас!
примечание : это то, что вы хотите ограничить, потому что увеличение частоты пакетов keepalive на нестабильном канале повышает риск разрыва соединения; которые определяются как x пакетов ответа keepalive, в действительности пакеты TCP ACK терпели неудачу последовательно.
Если ваша ссылка надежна, не стесняйтесь понизить эту директиву для вашего удобства (будьте осторожны, вам не требуется пакет поддержки активности в секунду) для более быстрого обнаружения отключений от сервера.
PS: Чтобы объяснить мой комментарий по этому вопросу, меня немного отталкивает идея использования ping в качестве условия для перезапуска службы и ее использования на сервере, которым вы не владеете и, следовательно, не можете гарантировать доступность, возможно. завтра Google решит перестать отвечать на эхо-запросы, и ваш сервер будет перезагружаться бесконечно.
Другой проблемой является то, что вы определяете как "подключение к Интернету", так как по определению большая коллекция сетей и тестирование одной конечной точки могут быть слишком малы, чтобы понять ваше подключение к сети, поэтому службы мониторинга в Интернете используют различные ссылок для отслеживания времени отклика / времени работы / т. д.
