Вопрос или проблема
В школе, где я работаю, я подключаю свой ноутбук к общедоступной сети Wi-Fi, в которой я должен идентифицироваться через веб-страницу (это продукт StormShield Network Security, если не ошибаюсь).
На этом ноутбуке при загрузке я настраиваю autossh туннель к одному из устройств дома (Intel NUC, который я использую для нескольких целей). Autossh запускается сразу после загрузки через системную службу systemd (–user), когда я вхожу в систему ноутбука. В основном он работает без проблем (если я уже идентифицирован в школьной сети), но я сталкиваюсь с странным поведением, когда ноутбук все еще не идентифицирован (обычно, во время загрузки). Я хотел бы понять.
- Логи autossh показывают, что я подключен к удаленному (домашнему) серверу. Как это возможно, учитывая, что у ноутбука все еще нет доступа к интернету, хотя он уже подключен к локальной сети?
myuser@mylaptop ~ $ autossh -M 0 -N -vvv -oServerAliveInterval=60 -oServerAliveCountMax=3 > -o ExitOnForwardFailure=yes -L localhost:22000:localhost:22000 -R localhost:22003:localhost:22003 kdomserv.mynetwork
[...]
debug3: ssh_connect_direct: entering debug1: Connecting to 82.65.XXX.XXX [82.65.XXX.XXX] port 2202.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.
- в то же время, autossh не удается установить ssh-туннель (что логично, так как я все еще не подключен):
myuser@mylaptop ~ $ sudo lsof -Pi -n | grep -E '<ssh>'
ssh 594 myuser 3u IPv4 7456 0t0 TCP 172.20.XXX.XXX:56762->82.65.XXX.XXX:2202 (ESTABLISHED)
- НО: насколько я понимаю, часть моей команды autossh “-o ExitOnForwardFailure=yes” (см. пункт 1) должна заставить autossh выйти и попытаться подключиться снова, пока он не создаст успешный туннель. Что не происходит (в логах нет ничего). Это также не происходит, когда я наконец идентифицирую свой ноутбук в школьной сети.
Таким образом, мой вопрос:
-
как autossh может говорить, что он подключен к удаленному серверу, с которым фактически не может общаться?
-
почему ExitOnForwardFailure не заставляет autossh остановиться/перезапуститься?
Ответ или решение
Анализ ситуации с autossh и SSH: Проблемы с настройкой туннеля и "ExitOnForwardFailure=yes"
Введение
Вы сталкиваетесь с нестандартной ситуацией, когда используете autossh для установки SSH туннеля через сеть школы. На фоне вашей архитектуры соединения возникают вопросы о том, как SSH может "подключиться", но не установить туннель, а также почему параметр "-o ExitOnForwardFailure=yes" не работает ожидаемым образом. Давайте разберёмся в деталях.
Возможности подключения к серверу
-
Подключение без идентификации в сети: SSH может сообщать о "подключении", потому что ваш ноутбук подключен к локальной сети, и начальная фаза соединения может происходить без полной идентификации в сети StormShield.
-
Отправка TCP пакетов: Возможно установление TCP-соединения, но это не означает, что будет полная передача данных. Речь может идти лишь о "предварительном" соединении, которое теряет ограничения на уровне сетевого экрана.
-
Кэширование DNS или сетевых ответов: Ваше устройство может кэшировать предыдущие успешные запросы, что создаёт иллюзию успешного соединения.
-
-
Роль firewall и инспекции пакетов: StormShield, подобно другим огненным стенам, может блокировать специфические порты или типы трафика, что не позволяет завершить туннельное соединение, даже при успешном установлении TCP-сессии.
Проблемы с "ExitOnForwardFailure"
-
Логика работы и отслеживание событий: Параметр "-o ExitOnForwardFailure=yes" предназначен для завершения ssh при невозможности установить туннель, но его использование с autossh может быть не так очевидно. autossh продолжает перезапускать ssh при потере соединения, но сам не управляет логикой завершения ssh, если туннель не построен.
-
Реакция на изменения сети: Когда ваше устройство, наконец, подключается к интернету, autossh уже может не отслеживать статус или не успешно реагировать на изменение условий сети, если изначальная сессия SSH всё ещё активна.
Рекомендации
-
Работа с systemd: Рассмотрите возможность модификации вашего systemd-сервиса, чтобы реализовать периодическую проверку доступности соединения перед запуском autossh.
-
Отладка и логирование: Включите расширенное логирование на уровне Cloud или используйте дополнительные утилиты мониторинга сети, чтобы понимать, какие этапы проходят успешно.
-
Динамическая реакция: Используйте скрипты оболочки для проверки доступности ресурса или сети, что позволит более гибко запускать autossh только тогда, когда сеть полностью функциональна.
Заключение
Решение проблемы с неудачами в построении туннеля требует внимательного подхода к настройке сети и поведения приложений. Убедитесь, что ёмко конфигурированы параметры доступа, уделите внимание особенностям функционирования системы в контейнеризированной или изолированной сети. Этот подход позволит снизить количество неудачных подключений и улучшить устойчивость работы с сетью в подобных условиях.