Определение источника блокируемого SSH-трафика

Вопрос или проблема

ssh -vvv -p 55555 XX.XX.XX.XX
OpenSSH_9.2p1 Debian-2+deb12u3, OpenSSL 3.0.15 3 Sep 2024
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config строка 19: include /etc/ssh/ssh_config.d/*.conf не совпало ни с одним файлом
debug1: /etc/ssh/ssh_config строка 21: Применение параметров для *
debug2: resolve_canonicalize: имя хоста XX.XX.XX.XX является адресом
debug3: развернуто UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/mansomean/.ssh/known_hosts'
debug3: развернуто UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/mansomean/.ssh/known_hosts2'
debug3: ssh_connect_direct: входим
debug1: Подключение к XX.XX.XX.XX [XX.XX.XX.XX] порт 55555.
debug3: set_sock_tos: установлен сокет 3 IP_TOS 0x10
debug1: подключение к адресу XX.XX.XX.XX порт 55555: Время подключения истекло
ssh: подключение к хосту XX.XX.XX.XX порт 55555: Время подключения истекло

Ответ или решение

Определение источника блокировки SSH-трафика

Проблема, с которой вы столкнулись, касается блокировки SSH-трафика между вашим рабочим местом и jump-хостом. Рассмотрим детали ситуации и возможные пути её решения.

Анализ ситуации

Произошло нагромождение факторов, влияющих на устойчивость соединения по протоколу SSH на порту 55555. Первые две недели соединение работало исправно, а затем неожиданно стало недоступным без использования прокси. Это может указывать на проблемы, связанные как с вашей локальной сетью, так и с действиями провайдеров (ISP A и ISP B).

Скорее всего, один из провайдеров — либо ISP A, через который проходит ваш jump-хост, либо ISP B, предоставляющий доступ к вашему рабочему месту — начал блокировать или фильтровать SSH-трафик. Ваша уверенность в том, что порты настроены корректно, поддерживается тем фактом, что соединение работает по VPN, указывая на то, что сам jump-хост доступен через другие маршруты.

Шаги для диагностики и возможные решения

1. Тестирование подключения:

   • Используйте telnet или nc (netcat) для проверки доступности порта 55555.

     telnet XX.XX.XX.XX 55555

     или

     nc -zv XX.XX.XX.XX 55555

     Эти команды помогут убедиться в том, что порт действительно не доступен.

2. Проверка маршрутов:

   • Выполните команду traceroute (или tracert на Windows) для определения, на каком этапе теряется соединение. Это может дать понимание того, блокирует ли трафик ISP B или ISP A.

     traceroute XX.XX.XX.XX

3. Логи вашего jump-хоста:

   • Просмотрите логи SSH на jump-хосте, чтобы определить, есть ли попытки подключений, которые могут блокироваться. Например:

     sudo tail -f /var/log/auth.log

4. Обратитесь к провайдерам:

   • Если проблема сохраняется, свяжитесь с обеими вашими интернет-провайдерами (ISP A и ISP B) и уточните, не происходит ли блокировка/фильтрация трафика по порту 55555. Опишите ситуацию и предоставьте данные о том, что соединение работает через VPN. Это поможет выяснить, может ли быть причина в политике провайдеров.

5. Использование дополнительных инструментов:

   • Программное обеспечение для мониторинга сети, такое как Wireshark, может помочь вам анализировать пакеты и выявить, где трафик блокируется или теряется.

6. Проверка на наличие изменений в конфигурациях:

   • Проанализируйте, не было ли изменений в конфигурациях на уровне вашего роутера или firewall, которые могли бы повлиять на настройки NAT/Port Forwarding.

Возможные причины недоступности

• Политика провайдера: Возможно, ISP B начал блокировку определённого трафика, чтобы сократить нагрузку на сеть или ввести ограничения для определённых типов соединений.

• Изменение трафика: Увеличение объёма трафика или изменение поведения пользователей на сети ISP A могло привести к изменению в маршрутизации или блокировке.

• Проблемы с географической маршрутизацией: Если IP-адрес вашего рабочего места или jump-хоста попал в черный список или имеет плохую репутацию, это также может вызывать проблемы.

Обсуждая вашу ситуацию, важно системно подойти к диагностике и мониторингу, чтобы определить корень проблемы. Удачи в поиске решения!