Туннель через HTTPS

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

В последнее время я использую Ajaxterm через HTTPS, так как порт 443 по-прежнему свободен, но это далеко не идеально. (Отстойная эмуляция терминала, отсутствие перенаправления портов, мой браузер с невероятной скоростью утекает из памяти...) Я попытался настроить 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, но я не хочу перечислять это как требование, если есть лучшие доступные решения.


ssh proxy https apache tunnel
person ephemient    schedule 08.10.2008    source источник
comment
Основная причина заключается в том, что программное обеспечение VPN, которое использует наша компания, имеет клиент только для Windows, поэтому я не могу работать из дома (5 из 5 компьютеров работают под управлением Linux, и мне не нужны проблемы с виртуальной Windows). Раньше я запускал ssh с обратным туннелем для удаленного рабочего стола, но теперь он не работает.   -  person ephemient    schedule 08.10.2008
comment
[поле комментария слишком короткое, я забыл закончить], и им не нравится, когда кто-либо использует какие-либо неутвержденные VPN, хотя они знают, что люди регулярно входят и выходят из WebEx... пожимают плечами системные администраторы, они не могут жить с ними, не может жить без них.   -  person ephemient    schedule 08.10.2008
comment
Это стало менее важным из-за того, что существует ветка vpnc, которая поддерживает Nortel VPN, поэтому мне больше не нужен собственный черный ход. Однако мне все еще неудобно полагаться на vpnc-nortel; раньше у него были проблемы с той же настройкой, и я недостаточно знаю, чтобы исправить это, если он сломается в будущем...   -  person ephemient    schedule 21.05.2009
comment
Быстрым решением для этого является webshell, которым я активно пользуюсь.   -  person Tim Post♦    schedule 04.02.2011
comment
Ошибка Apache 29744 была исправлена ​​в версии 2.4. Также есть патч для 2.2.22, который я применил к своей сборке Ubuntu 14.04 LTS, развернув только mod_proxy_connect.so.   -  person Mark    schedule 24.02.2016
comment
proxytunnel терпит неудачу, но действительно ужасная (echo -ne "CONNECT localhost:22 HTTP 1.1\r\nHost: proxy.fqdn\r\nProxy-Connection: Keep-Alive\r\n\r\n" && cat) | openssl s_client -quiet -connect proxy.fqdn:443 работала для меня как OpenSSH ProxyCommand   -  person Mark    schedule 24.02.2016

Ответы (13)


arrow_upward
7
arrow_downward

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

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

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

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

person Alexander    schedule 08.10.2008
comment
Это хак, но менее запутанный, чем все другие варианты, которые я вижу. Спасибо за подробности, они сэкономят мне много времени! - person ephemient; 09.10.2008
comment
Недавно я нашел rutschle.net/tech/sslh.shtml, который является воплощение этой идеи. К сожалению, кажется, что брандмауэр вводит пакеты RST в соединение SSH, даже если он работает на порту 443... - person ephemient; 21.05.2009

arrow_upward
6
arrow_downward

Вы должны иметь возможность использовать 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.

person Brian    schedule 08.10.2008
comment
Linux 2.4...десятилетие...LOL! Вы не упомянули, что вы также предполагаете, что у него достаточно мощный процессор для 2.4! - person Declan Shanaghy; 09.10.2008
comment
Умная идея! Я не думал об этом. - person ephemient; 09.10.2008

arrow_upward
6
arrow_downward

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

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

person Community    schedule 24.11.2008
comment
Хм, это похоже на принятое решение, но оно предварительно создано. Стоит посмотреть. - person ephemient; 24.11.2008

arrow_upward
2
arrow_downward

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

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

person Robert Gould    schedule 08.10.2008

arrow_upward
2
arrow_downward

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

Привязать apache/https к одному IP_1:443, а ваш sshd к другому IP_2:443?

person Huibert Gill    schedule 08.10.2008
comment
Было бы неплохо иметь многодомный доступ :D К сожалению, на мою домашнюю машину есть только один восходящий канал, и провайдер не раздает несколько IP-адресов. - person ephemient; 08.10.2008

arrow_upward
2
arrow_downward

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

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

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

person 11855589966    schedule 01.03.2012

arrow_upward
1
arrow_downward

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

person Harley Holcombe    schedule 08.10.2008
comment
5050 был единственным портом, который я нашел, который не был заблокирован моим интернет-провайдером (они не любят открытые почтовые ретрансляторы (25) и у них, вероятно, есть причины для других) и не был заблокирован брандмауэром на работе (кому что нужно кроме HTTP?). - person ephemient; 08.10.2008
comment
Насколько раздражающим было бы серверировать ваши HTTPS-материалы на другом порту? Запуск SSH-сервера на порту 443 — это то, как я делал это в прошлом, но тогда я не обслуживал ничего другого (точнее, я обслуживал намного больше, но все это было туннелировано). - person Harley Holcombe; 08.10.2008
comment
Лично меня бы это не напрягало, но я не один использую свой домашний сервер. Я, наверное, мог бы координировать такой переход, но это скорее крайний вариант. - person ephemient; 08.10.2008
comment
Другим еще более крайним вариантом может быть компиляция собственного apache. На этой странице bugzilla есть патч, который решает вашу проблему. Ошибка была открыта в течение 4 лет, не знаю, когда она привлечет внимание. Присмотревшись, можно увидеть несколько бинарных файлов mod_proxy.so, на которые тоже стоит взглянуть. - person Harley Holcombe; 08.10.2008
comment
В комментариях к патчу беспокоят возможные утечки памяти. Разобраться с дизайном бригады ведер Apache может быть непросто. - person ephemient; 08.10.2008

arrow_upward
1
arrow_downward

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

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

person Zoredache    schedule 08.10.2008
comment
Наш HTTP-прокси прозрачен, я понятия не имею, где он находится в сети. Обычно они также разрешают ПОДКЛЮЧАТЬСЯ только к определенным портам. - person ephemient; 08.10.2008

arrow_upward
1
arrow_downward

Видеть:

SSH через или через прокси

http://daniel.haxx.se/docs/sshproxy.html

http://www.agroman.net/corkscrew/

person Community    schedule 03.03.2009
comment
Нет, не может: компания использует прозрачный прокси-сервер, а не явный, на который вы можете отправлять CONNECT, и, кроме того, в вопросе говорится, что мне нужно иметь возможность продолжать использовать HTTPS на порту 443 вместо того, чтобы он был занят сшд. - person ephemient; 03.03.2009

arrow_upward
1
arrow_downward

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

См. http://chm.duquesne.free.fr/blog/?p=281 для подробностей.

person user48678    schedule 17.07.2011

arrow_upward
0
arrow_downward

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

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

person Cebjyre    schedule 08.10.2008
comment
Читайте вопрос внимательнее. Проблема в том, что я не могу ssh домой, и я не могу беспокоить сервер HTTPS, который используют другие. - person ephemient; 09.10.2008
comment
Я хорошо прочитал вопрос, но я не знаю вашей ситуации. Вы можете (или не можете) переместить HTTPS на другой порт и предоставить этим другим пользователям новые данные. HTTPS на 10443, по-видимому, не пройдет через ваш рабочий брандмауэр, но, поскольку вы можете использовать SSH на порту 443, lynx является вариантом. - person Cebjyre; 15.10.2008

arrow_upward
0
arrow_downward

Итак, попробуйте прокси-сервер (он поддерживает HTTP-прокси-сервер)!

http://www.proxifier.com/documentation/intro.htm

person Community    schedule 05.03.2009

arrow_upward
0
arrow_downward

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

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

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

person Vincent P    schedule 03.12.2012