Не удается подключиться по SSH через VPN (Windows 8, Cisco Client), но пинг работает, и SSH с других машин тоже работает.

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

На моем рабочем месте с Ubuntu Linux у меня правильно работает SSH-сервер. Я могу войти на эту машину с других машин в той же (физической) сети.

Моя цель – войти на это рабочее место с моего ноутбука на Windows 8.1, который не подключен к той же сети. С моего ноутбука я могу подключиться к VPN моего университета с использованием Cisco AnyConnect Secure Mobility Client. Это, кажется, работает в целом. Я также могу ping мою рабочую станцию после настройки VPN-соединения. Обратите внимание, что я уверен, что пингую правильный компьютер (исключая конфликты IP и т. д.), так как, когда я отслеживаю входящие ICMP-запросы там, пинги с моего Windows-компьютера проходят.

Теперь проблема в том, что SSH (с использованием Putty) через туннель, похоже, не работает. Putty продолжает выдавать мне “Ошибка сети: тайм-аут соединения”.

SSH-сервер слушает как на IPv4, так и на IPv6:

eelke@eelkebox:/var/log$ sudo netstat -tulpn | grep ssh
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      21436/sshd      
tcp6       0      0 :::22                   :::*                    LISTEN      21436/sshd   

(Клиент Cisco, как я думаю, настроен на блокировку всего трафика IPv6, поэтому я проверил, разрешены ли также соединения IPv4.)

Также фаервол не запущен:

eelke@eelkebox:/var/log$ sudo ufw status
Статус: неактивен

Есть идеи, как заставить мой Windows-ноутбук подключиться к SSH-серверу через VPN?

Быстрый тест, чтобы проверить, доступен ли порт, – это попробовать подключиться к нему через telnet. Если успешно, вы должны увидеть что-то вроде этого:

# telnet 127.0.0.1 22
Попытка подключения к 127.0.0.1...
Подключено к 127.0.0.1.
Символ выхода - '^>'.
SSH-2.0-OpenSSH_6.1

В противном случае это может быть фаервол где-то по пути, блокирующий соединение.

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

Проблема, с которой вы столкнулись, связана с невозможностью установить SSH-соединение через VPN, несмотря на успешные пинги к вашей рабочей станции. Давайте разберемся с каждым элементом, чтобы выявить причину несоответствия.

  1. Проверка настроек SSH-сервера: У вас уже есть информация о том, что SSH-сервер слушает на порту 22 и доступен как для IPv4, так и для IPv6. Это правильно, и у вас нет активного межсетевого экрана на сервере (по состоянию на вывод sudo ufw status).

  2. Проверка подключаемого порта: Как вы уже предложили, можно сделать проверку через telnet. На вашем Windows-ноутбуке откройте командную строку и выполните следующую команду:

    telnet <IP-адрес вашей рабочей станции> 22

    Если соединение успешно, то вы увидите сообщение о подключении. Если нет, это указывает на то, что что-то блокирует соединение на уровне сети.

  3. Настройки VPN: Убедитесь, что ваш клиент Cisco AnyConnect действительно настроен для маршрутизации трафика к IP-адресу вашей рабочей станции. Иногда VPN-клиенты могут блокировать определенные порты или протоколы. Попробуйте также временно отключить VPN и проверить, сможете ли вы подключиться к SSH (это важный тест, чтобы проверить, где именно проблема).

  4. Межсетевые экраны и маршрутизация: Хотя вы уже проверили, что на вашем сервере нет межсетевых экранов, проверьте, нет ли активных фильтров на уровне сети (возможно, на уровне роутера или межсетевого экрана вашего провайдера), которые могут блокировать трафик SSH (порт 22). Также убедитесь, что ваше локальное сетевое оборудование позволяет проксировать запросы к серверу.

  5. IPv6 и настройки Cisco: Если клиент Cisco AnyConnect настроен на блокирование IPv6, это может вызвать проблемы при установлении соединений, если IP-адрес вашей рабочей станции имеет как IPv4, так и IPv6. Попробуйте явно использовать IPv4-адрес вашей рабочей станции в PuTTY, чтобы обойти потенциальные проблемы с IPv6.

  6. Логи SSH: Проверьте логи SSH на вашей Ubuntu-машине для получения более детальной информации о попытках подключения. Вы можете найти логи в /var/log/auth.log. Это может дать представление о том, удается ли от клиенки проходить в SSH-сервер или соединение отклоняется.

Если все вышеперечисленное не решает вашу проблему, напишите о своих находках, и мы сможем продолжить поиск решения.

Оцените материал
Добавить комментарий

Капча загружается...