Подтвердить что ты не робот

Тоннель над HTTPS

На моем рабочем месте блокировщик трафика/межсетевой экран постепенно ухудшался. Я не могу подключиться к своей домашней машине на порту 22, и отсутствие доступа к ssh меня огорчает. Ранее я мог использовать SSH, переместив его на порт 5050, но я думаю, что некоторые последние фильтры теперь рассматривают этот трафик как IM и, возможно, перенаправляют его через другой прокси. Это мое лучшее предположение; в любом случае, мои ssh-соединения теперь заканчиваются, прежде чем я войду в систему.

В наши дни я использую Ajaxterm через HTTPS, так как порт 443 по-прежнему без проблем, но это далеко не идеальный. (Эмуляция терминала Sucky, отсутствие переадресации портов, мой браузер теряет память с невероятной скоростью...) Я попытался настроить mod_proxy_connect поверх mod_ssl, с идеей, что я могу отправить запрос CONNECT localhost:22 HTTP/1.1 через HTTPS, и тогда все будет готово. К сожалению, это, похоже, не работает; соединение HTTPS работает, пока я не закончу отправку моего запроса; то SSL дерьмо. Похоже, что mod_proxy_connect берет на себя все соединение вместо того, чтобы продолжать транслировать через mod_ssl, сбивая с толку клиента HTTPS.

Есть ли способ заставить это работать? Я не хочу делать это по простому HTTP, по нескольким причинам:

  • Оставив большой толстый открытый прокси, как будто просто воняет
  • Большой толстый открытый прокси-сервер тоже не хорош по HTTPS, но с проверкой подлинности он чувствует себя хорошо для меня.
  • HTTP проходит через прокси - я не слишком беспокоюсь о том, что мой трафик обнюхивается, так как это ssh, который будет проходить "открытый текст" через туннель, но он гораздо более правдоподобен, чем HTTPS, которые в принципе не могут быть проксимированы.

Требования:

  • Должен работать над портом 443, не нарушая другого трафика HTTPS (т.е. я не могу просто поместить ssh-сервер на порт 443, потому что я больше не смогу обслуживать страницы через HTTPS)
  • У меня есть или могу написать простой клиент пересылки портов, который работает под Windows (или Cygwin)

Изменить

DAG: туннелирование SSH через HTTP (S) было указано мне, но это не помогает: в конце статьи, они упоминают Ошибка 29744 - CONNECT не работает над существующим SSL-соединением, предотвращая туннелирование через HTTPS, в точности именно такую ​​проблему, с которой я столкнулся. На данный момент я, вероятно, смотрю на CGI script, но я не хочу перечислять это как требование, если есть лучшие доступные решения.

4b9b3361

ОТВЕТЫ

Ответ 1

Узнайте, почему компания имеет такую ​​ограничительную политику. Это может быть по уважительной причине.

Если вы все же обнаружите, что хотите обходить политику, вы можете написать небольшой прокси-сервер, который будет прослушивать ваш сервер на порту 443, а затем, в зависимости от запроса, пересылает трафик либо на ваш веб-сервер, либо на SSH-демон. Однако есть два улова.

  • Чтобы определить, является ли это HTTPS-запрос или SSH-запрос, вам нужно попытаться прочитать некоторые данные с небольшим таймаутом, это связано с тем, что квитирование TLS/SSL начинается с того, что клиент отправляет некоторые данные, тогда как SSH-квитирование начинается с отправки сервером некоторых данных. Тайм-аут должен быть достаточно большим, чтобы задерживать доставку исходных данных от клиента в квитировании TLS/SSL, поэтому он замедляет установление соединений SSH.

  • Если прокси-сервер HTTP в вашей компании является интеллектуальным, он фактически подслушивает ожидаемое TLS/SSL "рукопожатие", когда вы CONNECT на порт 443, и, когда он обнаруживает, что это не TLS/SSL, он может прекратить попытку подключения SSH. Чтобы решить эту проблему, вы можете обернуть демон SSH в туннель TLS/SSL (например, stunnel), но вам нужно будет различать запросы на основе версии TLS/SSL в запросе клиента, чтобы определить, следует ли маршрутизировать TLS/SSL-соединение с веб-сервером или с туннелированным SSH-демоном TLS/SSL.

Ответ 2

Вы должны иметь возможность использовать iptables для пересылки ssh-трафика с ваших рабочих машин на ssh, в то время как все остальные машины, подключенные к вашему домашнему серверу на порту 443, получают сервер Apache.

Попробуйте следующее правило:

iptables -t nat -A PREROUTING -p tcp -s 111.111.111.111 --dport 433 -j REDIRECT --to-port 22

Где 111.111.111.111 - ваш IP-адрес вашего офиса.

Все предполагает, что вы используете Linux >= 2.4, к которому вы должны быть к настоящему времени. Это было почти десять лет.

Документация для iptables находится в http://www.netfilter.org.

Ответ 3

Настройте сервер OpenVPN 2.1 дома, используйте порт 443 (если вы настроили свой домашний сервис HTTPS на порту 443, включите опцию OpenVPN port-share для обработки транзакций OpenVPN и HTTPS на порту 443, эта функция доступна только для не-ОС Windows)

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

Ответ 4

Как насчет использования 2 IP-адресов на вашем компьютере?

Свяжите apache/https на одном IP_1: 443 и ваш sshd на другом IP_2: 443?

Ответ 5

Не могли бы вы создать среднего человека?

Запустите небольшой/свободный/дешевый экземпляр в облаке, прослушивающий 443 для SSH, затем, хотя этот туннель облачного экземпляра в ваш домашний ящик на вашем любимом порту - 22 или что-то еще.

Это добавит некоторую задержку, я уверен, но она решает проблему сохранения исходной домашней установки.

Ответ 6

Я думаю, вам нужно будет найти порт, который вы не используете в настоящее время, на котором вы можете выйти, и слушать это. 443 является очевидным кандидатом, но вы говорите, что это невозможно. Что касается почты (25, 110, 143), telnet (23), ftp (21), DNS (53) или даже whois (43)?

Ответ 7

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

Теперь, если у вас есть разрешение открыть туннель от вашего босса, это прекрасно, но если что-то случится, ЧТО-НИБУДЬ, и они выясняют, что у вас есть туннель, я могу почти заверить вас, вы станете козлом отпущения. Поэтому, если бы я был вами, я бы не открывал туннели на работе, если они настраивают брандмауэры против него.

Ответ 8

Прокси-туннель может быть вашим ответом

http://proxytunnel.sourceforge.net/

позволяет сказать, что мой ssh-сервер - host.domain.tld, а мой прокси-сервер работает 10.2.4.37

Я бы добавил это к моей локальной конфигурации ssh

Host host.domain.tld   ProxyCommand/usr/local/bin/proxytunnel -q -p 10.2.4.37:3128 -d% h:% p   ProtocolKeepAlives 30

Ответ 10

Так как у apache нет проблемы с CONNECT, когда не задействован SSL, я отключу функции SSL, и я использую stunnel для обслуживания https-версии моего сайта. Это не требует перекомпиляции и позволяет вашему сайту нормально обслуживать https. Пока что самый чистый обходной путь, который я знаю.

Подробнее см. http://chm.duquesne.free.fr/blog/?p=281.

Ответ 11

Должен работать над портом 443, не нарушая другого трафика HTTPS (т.е. я не могу просто поместить ssh-сервер на порт 443, потому что я больше не мог бы обслуживать страницы через HTTPS)

Возможно ли связать ваш HTTPS-сервер с другим портом? В зависимости от того, для чего он используется, вы даже можете обойти проблему неспособности напрямую получить доступ к ней с работы, просто используя SSHing домой, а затем используя lynx.

Ответ 13

Мне удалось обойти брандмауэр моей компании, используя следующий проект через AjaxTerm, он работает для меня.

ПК в сети компании → прокси-сервер компании через https → ИНТЕРНЕТ → Мой домашний обратный прокси-сервер Apache на SSL +.htpasswd защита → Сервер AjaxTerm (отсюда в палате я могу использовать SSH для любого другого серверов).

Все еще не идеальный мир... было бы хорошо, если бы я мог туннелировать в мою домашнюю сеть через HTTPS.