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

пятница, 14 января 2011 г.

SSH-туннель (часть 1)

Моему любимому слизеринцу. :)

Предварительные замечания

  Давным-давно, кажется, даже значительно раньше, чем в прошлую пятницу,у меня появилась идея рассказать, как организовать ssh-туннель. Задача данного цикла статей (есть вторая и третья части, скоро появится четвёртая) вполне определённая — помочь пользователю проковырять дырку в файрволе. Поэтому другие методы типа vpn и иже с ним мы рассматривать не будем. Этическую сторону данной проблемы оставим в стороне, я просто расскажу, что для этого нужно сделать и какие дополнительные мероприятия провести. Если этот текст читает начинающий администратор (то есть формально — идеологический и технический противник), то для него у меня тоже есть пара слов. :) А админы со стажем и так знают, что делать в таких случаях. ;) Итак, …

Вводная

  Имеется некий комп, с которого можно заходить на некие сайты в интернете. В том же интернете существуют и другие сайты, доступ к которым закрыт. Неважно, ходит пользователь через корпоративный проксятник или же сидит за NAT'ом с фаши очень закрытым файрволом, нужно просто открыть доступ ко всему, что есть.
  Для начала отвлечёмся от заявленного способа реализации и определим базовые свойства нашей системы.
  1. Туннелированный трафик обязан шифроваться, чтобы сделать невозможной фильтрацию по содержимому. По сути трюизм.
  2. Сервер должен находиться за пределами файрвола. Вроде бы очевидно. Однако, в некоторых случаях :) это буквально означает "в другой стране".
  3. Необходимое условие доступа к серверу — "чистые" IP и доменное имя. Это значит, что они не должны быть в "чёрных списках" фильтров (анонимайзеры, порнуха, варез, файлопомойки, бесплатное мыло и прочие запрещённые для посещения домены и пулы IP-адресов).
  4. Дополнительное условие для работы через репрессивный прокси (закрыты все порты, кроме стандартных HTTP/HTTPS): сервер снаружи должен слушать 443 порт (HTTPS). Потому что в указанном тяжёлом случае только на этот порт разрешается необходимое нам шифрованное потоковое соединение.
  5. Немаловажный фактор на стороне клиента — возможность безнаказанно (или хотя бы скрытно) ставить софт для личного пользования. На личном ноутбуке таких проблем обычно :) не возникает, а вот в случае служебной рабочей станции от админов можно ожидать чего угодно. От некоторых — даже открытого доступа в соц. сети. :)

Идея решения

  Итак, в первом приближении решение можно сформулировать таким образом.
Организуем любым способом шелл с доступом по ssh и по мере необходимости соединяемся с ним, назначив динамический порт-форвардинг и используя соединение как SOCKS-прокси. Как обычно, в реальной жизни :) обнаруживаются некие нюансы. Например, многие шелл-провайдеры, раздающие своё добро бесплатно, требуют взамен копии документов, удостоверяющих личность. Якобы чтобы можно было предъявлять претензии, если вдруг окажется, что с выданного аккаунта кого-то ломанули или заспамили. Многие запрещают запускать постоянно висящие процессы типа screen или своих демонов/ботов. У некоторых вообще запрещён доступ в интернет, а некоторые разрешают, но, например, только на HTTP(S)/POP3/SMTP. Но самое главное, что готовый шелл — это необходимость соединяться на стандартный 22 порт. А это как раз и не устраивает. Хотя, опять же, есть и исключения, которые разрешают коннектиться, например, на вожделенный 443. :) В общем, есть идея лучше.
  Во втором приближении оказывается, что значительно удобнее пользоваться не голым шеллом, постоянно оглядываясь на всевозможные ограничения, а своим выделенным сервером. Более конкретно, нас интересует VPS, то есть Virtual Private Server (или виртуальный частный сервер). Стоимость виртуальных серверов значительно ниже, чем настоящих, "железных", а по производительности нас устроит и уровень полугигагерцового третьего пня. Итак, нам нужен VPS-хостинг на какой-нибудь "нейтральной" территории типа Канады, Швейцарии или, на худой конец, Вануату. :) Организационные моменты заказа/оплаты/установки системы и настройки, как мне кажется, выходят за рамки этой статьи, поэтому мы их опустим. Главное, что мы получили вместе с VPS — это полный контроль над своим сервером, статический IP, возможность ставить любой софт по своему усмотрению. Кроме того, если очень давит жаба, можно скинуться на оплату и завести на сервере кучу пользователей. Единственный минус такого варианта — придётся организовать некое подобие учёта трафика и биллинговой системы, чтобы ограничить желающих покачать торренты нахаляву. :)

Отказ от ответственности

  Как обычно эксплицитно заявляю о том, что текст цикла статей об организации ssh-туннеля ни в коей мере не является призывом к совершению описанных действий или даже просто предложением проверить изложенные идеи на практике. Данный текст представлен здесь исключительно в учебных целях как возможный вариант плана проведения лабораторной работы по курсу «Сети ЭВМ». Обычному пользователю, кроме того, следует знать, что любые ограничения, вводимые системными и сетевыми администраторами, направлены прежде всего на повышение безопасности IT-инфраструктуры предприятия и, в конечном итоге, ведут к снижению рисков и затрат. А подобная экономия высвобождает средства, которые могут быть использованы в том числе и на повышение зарплаты работников предприятия. Подумайте об этом, прежде чем безответственно использовать полученные знания для несанкционированного доступа к запрещённым ресурсам.
  Автор данного цикла статей не несёт ответственности за любой ущерб, материальный или моральный, понесённый читателем или третьими лицами вследствие осуществления на практике всех или части описанных действий, включая (но не ограничиваясь этим) утечку информации, недополучение прибыли, утрату имущества вследствие неправильного его использования, штрафные санкции и/или гражданскую, административную или уголовную ответственность, наложенные на читателя вследствие исков третьих лиц, организаций или государственных структур, а также увечья и травмы, полученные читателем во время или после прочтения данных статей, и связанные с применением указанной информации на практике.
  Вся информация, использованная для подготовки этого текста, взята из открытых источников или является результатом самостоятельных исследований автора этого блога.

Некоторые полезные ссылки

  1. man ssh :)
  2. Краткий обзор свободных реализаций VPN
  3. Краткое руководство по прокидыванию ssh-туннеля.
  4. Как организовать ssh-туннель на стороне клиента.
  5. Список шелл-провайдеров
  6. Список достаточно дешёвых VPS-хостингов
  7. VPS в Канаде

Комментариев нет:

Отправить комментарий