Туннель по HTTPS

Question

На моем рабочем месте блокировка трафика / брандмауэр постепенно ухудшается. Я не могу подключиться к своей домашней машине через порт 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-скрипт, но я не хочу указывать это как требование, если есть лучшие решения.

Answer 1

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

Если вы все еще обнаружите, что хотите обойти политику, вы можете написать небольшой прокси-сервер, который будет прослушивать ваш сервер на порту 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 с веб-сервером или демоном SSH с туннелированием TLS / SSL.

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

См:

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

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

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

Answer 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

Answer 9

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

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

Answer 10

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