The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Использование SSH поверх прокси (через SSL CONNECT в squid) (ssh ssl tunnel squid proxy)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: ssh, ssl, tunnel, squid, proxy,  (найти похожие документы)
Date: 3 Sep 2002 From: Игорь Чубин Subject: Использование SSH поверх прокси (через SSL CONNECT в squid) SSH поверх прокси (SSL CONNECT в squid) Идея Причиной, которая заставила меня написать эти рекомендации была необходимость. Необходимость в полноценном доступе к Интернету, когда под рукой есть только прокси-сервер. Такая проблема сейчас встает очень часто: существует локальная сеть, подключенная к Интернету через Squid или другой подбобный ему сервер. Компьютеры сети используют внутренние адреса: 10.x.x.x, 172.16.x.x или 192.168.x.x. Очевидно, прямой доступ к серверам Интернета они получить не могут. Выходом мог бы быть маскарадинг, но он выполняется не всегда: причины могут быть самые разные -- от соображений безопасности, до элементарной лени. Обиднее всего, что где-то там, за брандмауэром, есть компьютер, которому ты не безразличен и вы жаждете соединиться. Что же делать? Неужто нет никакого выхода? Выход есть, его не может не быть. С детства известно, настоящая любовь (к полноценному коннекту) преодолеет любые преграды. Все прокси поддерживают обработку HTTP-запросов. Это, конечно, хорошо, но это еще не все. Обычно прокси поддерживает еще и SSL и это его роковая ошибка :) Здесь и далее, говоря прокси, мы имеем в виду традиционное толкование этого термина, т.е. кэширующий прокси-сервер типа Squid, а не более общее: сервер-посредник, который предоставляет доступ к какому-лиюо сервису Конфигурационный файл Squid по умолчанию разрешает соединение с портами 443 и 563 на которых работает HTTP over SSL и NNTP over SSL. Фрагмент типового squid.conf файла конфигурации Squid: acl SSL_ports port 443 563 # Deny CONNECT to other than SSL ports http_access deny CONNECT !SSL_ports По большому счету нам все равно, какой из этих портов использовать. Поскольку обычно все прокси-серверы поддерживают защищенное соединение https, соединение по порту 443 должно обеспечиваться. Замечание Если бы Squid разрешал CONNECT по любому порту: http_access allow CONNECT all то можно было бы осуществлять любое исходящее соединение вообще без всяких проблем. Например, transconnect (http://transconnect.sourceforge.net/), используя технику подстановки функций, при помощи замены библиотек позволяет добиться прекрасных результатов! Поскольку мы не можем обращаться к любому порту любого сервера напрямую, нам нужно иметь в Интернете машину, которая будет выполнять прослушивание этого порта и обрабатывать наши запросы. Схема выглядит так: +------- + +-------+ +---------+ / | Client |-----| Proxy |-----| S-Proxy |(-- +--------+ +-------+ +---------+ \ Мы (client) устанавливаем соединение с нашим компьютером в Интернете (s-proxy) при помощи доступного прокси-сервера (proxy). Соединение, как мы уже договорились, происходит по https. Приложение на s-proxy, с которым мы устанавливаем связь, может быть каким угодно. Нужно добиться как-то, чтобы S-Proxy расшифровывал SSL-трафик, приходящий на порт 443, и отправлял его интересующему нас приложению. Это достигается с использование программы stunnel, которая позволяет делать все что-угодно с каналами SSL. Какой сервис лучше всего сделать доступным? Добъемся например доступа к ssh. Для этого есть несколько причин : (самая главная: меня это сейчас интересует больше всего ;) * Необходимость. Обычно во внутренней сети все наиболее популярные службы, как то: e-mail, www, ftp уже доступны. Удаленный же доступ к компьютерам за пределами сети нередко запрещается или попросту отсутствует. При этом зачастую он бывает важнее всех остальных сервисов вместе взятых. * Универсальность. ssh за счет своей огромнейшей гибкости позволяет выполнять самые разнообразые вещи, далеко выходящие за рамки безопасной оболчки, установленные его названием. Фактически, если у нас есть доступ к удаленной машине по ssh, у нас есть все. Подсказка При желании мы можем заставить вообще весь трафик ходить по SSL-тунелю. Это не проблема, только нужно ли? Серверная часть Итак, мы договорились, что данные из внутренней сети во внешнюю и назад, у нас будут передаваться по SSL-каналу. Все что остается - это создать его и подключить его к нужным службам. На s-proxy поднимаем stunnel: # stunnel -p stunnel.pem -r 22 -d https Ключ -p указывает на файл сертификата. Он обязательно нужен при использовании stunnel в режиме сервера. Узнать имя файла можно при помощи ключа -V. Ключ -r задает порт, на который будет направлен поток, принятый программой извне. Это как раз и есть данные передающиеся по SSL-каналу, они расшифровываются и направляются на порт 22, где ведет прослушивание демон sshd. Ключ -d определяет порт на котором, сам stunnel выполняет прослушивание. Мы решили, что будем ходить через https, потому что скорее всего наш прокси-сервер его обслуживает. Клиентская часть Теперь мы долны заняться клиентской частью. Здесь все почти также просто. Но есть одно небольшое НО. Соединение должно быть установлено через прокси-сервер, а stunnel, к сожалению, поддерживает только прямые SSL-соединения. На www.stunnel.org можно найти небольшой патч к stunnel, который позволяет использовать прокси-серверы. Патч находится по адресу: http://www.stunnel.org/patches/desc/proxy_sweeheng.html . Он разрабатывался для stunnel 3.14, поэтому на stunnel 3.x он накладывается практически без проблем. Те трудности, которые могут возникнуть при небольшом несовпадении некоторых строк в файлах версий >3.14 - не в счет - они легко устраняются ручным вмешательством. Итак, выполняем сборку stunnel с поддержкой прокси (файлы proxy_sweeheng.patch.txt и stunnel-3.14-proxy.tar.bz2 находятся в текущем каталоге, в который у пользователя есть право на запись): $ tar xvfj stunnel-3.14-proxy.tar.bz2 $ cd stunnel-3.14 $ patch -p0 < ../proxy_sweeheng.patch.txt $ ./configure $ make # make install Последняя команда должна выполняться от имени суперпользователя root. Теперь клиентский stunnel с поддержкой прокси у нас есть. Нам осталось проложить канал на сервер, а дальше преспокойно пользоваться им: # stunnel -c -d 2222 -Z s-proxy:https -r proxy:https Команда устанавливает SSL-туннель с текущего хоста на хост s-proxy, используя хост proxy, как промежуточный (ключ -Z поддерживается только пропатченным stunnel'ем). Локально тунель доступен по порту 2222. Этим тунеллированием мы добились того, что все что поступает на порт 2222 локального хоста в результате оказывается на порту 22 хоста s-proxy. И наоборот, что s-proxy отправляет с порта 22 -- доступно по локальному порту 2222. Осталось только воспользоваться плодами своего труда и запустить ssh: $ ssh user@localhost -p 2222 Мы заставляем обратиться ssh к порту 2222 локального компьютера. Он наивно полагает, что он общается с локальным сервером и только мы знаем, что он общается с stunnel, который передает данные по SSL-тунелю на s-proxy. Понятно, что имя пользователь соответствует не локальному пользователю, а удаленному, на хосте s-proxy. Для того чтобы предельно облегчить себе жизнь, можно отключить аутентификацию по открытым ключам, которую ssh проводит при обращении к localhost. Для этого в ~/.ssh/config нужно добавить: Host localhost PubkeyAuthentication no Теперь, даже в том случае, если мы используем несколько разных тунелей с разными хостами или, если, мы любим заходить к себе локально по ssh, проблем с аутентификацией хоста не возникнет. Предостережение Настоятельно не рекомендается отключать проверку подлинности открытыми ключами с компьютерами, отличными от localhost.

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, Dim, 08:23, 18/01/2005 [ответить] [смотреть все]
  • +/
    Несколько криво это всё работает.  А на OS отличных от Linux/BSD оно без напильника даже не собирается. Кроме того этот патч ТОЛЬКО для stunnel-3.14.
    Более универсальное решение для тунелирования ssh прпотокола - использовать программу Corkscrew (http://www.agroman.net/corkscrew/), которая специально заточена для этого.
     
  • 1.2, syder, 12:52, 31/01/2005 [ответить] [смотреть все]
  • +/
    А как на счет соединения в среде виндовс, какими штучками это можно сделать
     
     
  • 2.9, Сергей, 15:37, 05/02/2009 [^] [ответить] [смотреть все]
  • +/
    В Windows есть ssh-клиент putty - там в настройках надо указать прокси - и всё!
     
  • 1.4, Valentin Nechayev, 20:05, 01/02/2005 [ответить] [смотреть все]
  • +/
    У меня практически работала совсем другая схема I Обеспечить выход в мир через... весь текст скрыт [показать]
     
  • 1.5, napTu, 18:17, 02/02/2006 [ответить] [смотреть все]  
  • +/
    поставил cygwin, попарился с настройками и компиляцией corkscrew, когда уже всё было готово, возник вопрос: "каким клиентом коннектится на сервак?"
    Оказывается, всё намного проще! Я всегда использовал putty для подключения из винды на BSD. Этот клиент сам по себе поддерживает работу через прокси. Остается только настроить сервер на порт 443 или сделать форвардинг пакетов с 443 на 22 порт.
    У меня построено так: putty через прокси уходит на мой виндовый сервак с установленным порт маппером (в netview от killsoft). Маппер делает из инет:443 локалBSD:22
    Всё. Коннект установлен.
     
  • 1.6, napTu, 18:20, 02/02/2006 [ответить] [смотреть все]  
  • +/
    теперь надо пробросить VPN также...
     
  • 1.7, veo, 17:06, 10/05/2006 [ответить] [смотреть все]  
  • +/
    кстати, где то видел, что с corkscrew можно проходить через не только http-proxy Но и через httpS-proxy
    однако что то у меня не вышо - может у кого то выходило??
     
     
  • 2.8, noir74, 20:45, 31/05/2006 [^] [ответить] [смотреть все]  
  • +/
    >кстати, где то видел, что с corkscrew можно проходить через не только
    >http-proxy Но и через httpS-proxy
    >однако что то у меня не вышо - может у кого то
    >выходило??

    зачем прокидывать через https, если данные уже идут внутри ssh ?

     
  • 1.10, Альберт, 23:36, 18/02/2010 [ответить] [смотреть все]  
  • +/
    Я когда поднимаю тунель на стороне клиента к серверу то соединение создается успешно. Однако когда я пытаюсь вопользоваться тунелем Firefox'ом то никаких ошибок не возникает (типа тунель есть и работает), однако все сайты открываются пустыми страницами (контент не передается почему то..) Никто не в курсе в какую сторону копать?
    Спасибо!
     
     
  • 2.12, Serge, 19:13, 26/02/2010 [^] [ответить] [смотреть все]  
  • +/
    Vidimo u vas SSH ne podderzhivaet HTTP proxy - ispolzuite SOCKS. dlya firefox est' addon foxyproxy - on pozvolit ispolzovat' SOCKS dlya vseh protokolov. Udachi!
     
  • 1.11, Tig, 11:21, 24/02/2010 [ответить] [смотреть все]  
  • +/
    Мне в итоге помог реверсивный ssh. http://toic.org/2009/01/18/reverse-ssh-port-forwarding/
     
  • 1.13, Evgeny, 17:15, 09/11/2012 [ответить] [смотреть все]  
  • +/
    А что делать если в прокси закрыт доступ через 443 порт, открыт только 80й?

    Прокся режет все https соединения, кроме проверенных серверов, список которых очень узок.

     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:





      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor