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

Настройка клиентской части

  В основном данный материал предназначен для пользователй Microsoft® Windows™, поскольку весь этот геморрой с настройкой PuTTY нужен только в винде. Теоретически среднестатистический пользователь Линукса тоже может порадовать себя подобным извращением, так как сборка PuTTY существует и под Линукс, но здесь значительно проще будет просто запустить ssh и не париться. :)

Настройка PuTTY

  Во-первых, в разделе Session придумываем и заносим в соответствующее поле название нашего соединения (например, test) и определяемся, к какому серверу будем цепляться (например, somehost.testing.com) и на какой порт (как мы выяснили в предыдущей части, 443 порт — лучшее решение для тоталитарных файрволов). Безусловно, сервер и порт мы уже знаем, поскольку этот самый сервер только что настроили самостоятельно или же нам кто-то подсказал правильный адрес. 8-) Сразу же нажимаем на кнопочку «Save», дабы труд не пропал втуне.

  Во-вторых, настраиваем локаль соединения. В принципе, подавляющее большинство Linux-дистрибутивов по умолчанию поддерживают UTF-8, если только при установке из каких-то извращённых соображений администратор не выставил ISO-8859-5 или cp1251. Поэтому в разделе Translation выбираем эту самую UTF-8. Если же заранее известно, что сервер работает под бздями (любыми — Free/Open/NetBSD), то с большой вероятностью там будет использоваться всё ещё koi8-r. В этом случае, естественно, придётся указать koi8-r в качестве кодировки, а для символов рисования рамок выбрать что-нибудь типа XWindows encoding или вообще poor man's line drawing. В принципе, если рамки отображаются криво, а руские символы ну явно не русские, то можно будет поэкспериментировать уже после подключения. Естественно, после изменения настроек в этом разделе возвращаемся в раздел Session и нажимаем кнопочку «Save». :) Ну и вообще после любых изменений желательно сохраняться. Мне лично просто смертельно скучно заново набирать одно и то же, но, как говорится, YMMV. :)

  Следующая настройка, которую желательно было бы поменять сразу же, находится в ветке Data раздела Connection. Это имя пользователя, которое будет подставляться при соединении с сервером. Безусловно, поле автоподстановки можно оставить пустым, но тогда PuTTY каждый раз при соединении будет спрашивать, под кем заходить. Это хорошо для параноидальной степени безопасности с обязательной авторизацией по ключу, но в подавляющем большинстве остальных случаев значительно удобнее организовать автоподстановку. Остальные параметры на этой странице можно не трогать.

  Следующий шаг — настройка прокси. Если вы не знаете, что это такое, лучше здесь ничего не трогать. B-) Если же вам для доступа в инет админы настраивали проксятник и выдали имя пользователя и пароль для авторизации, значит вам придётся всё это вспомнить и вбить сюда. :/ Если вы используете Firefox, то вам крупно повезло. :) Заходите в Настройки, дальше на закладку «Защита» и жмите кнопку «Сохранённые пароли...», а в открывшемся окне — «Отобразить пароли». С другими браузерами, вероятно, вам поможет Google. К чему это я?.. А, да... Так вот, иногда бывает так, что админы настраивают всем доступ через прокси, но отдельно никто не авторизуется. В этом случае, естественно, никаких имени пользователя/пароля не будет, и вбивать их, соответственно, не нужно. Ну это, вроде бы, очевидно. :) Тип прокси с большой вероятностью будет HTTP, хотя может быть и SOCKS, если админы склонны поддерживать анархию на предприятии. Остальные параметры можно оставить как есть. И ещё раз: если вы ничего не знаете о прокси, здесь лучше всё оставить как было.

  Далее переходим к настройкам собственно протокола SSH. В принципе, все параметры по умолчанию нам подходят, но есть пара нюансов. :) Если вы не собираетесь использовать shell (то есть выполнять какие-то команды на удалённом сервере), то можно поставить галку «Don't start a shell or command at all». А если вы будете использовать это соединение в основном для просмотра html-страниц, то можно ещё и выставить «Enable compression» — появится аналог сжимающего прокси, то есть трафик от сервера до вашей клиентской машины будет значительно меньше. Но если вы предполагаете прокачивать через это соединение большое количество уже сжатого контента (видео, картинки, музыка, архивы, зашифрованные контейнеры), то сжатие ничего не даст; более того — трафик даже увеличится, а сервер и клиент будут без толку напрягаться. Так что здесь решать вам.

  В разделе «Auth» пока ничего менять не будем, но когда создадим пару ключей, здесь нужно будет указать местоположение нашего закрытого ключа.

  А сейчас пойдёт самое интересное... =)

Настройка форвардинга портов

  Что это такое и с чем его едят? Ну это такая фича, позволяющая соединяться с разными сервисами, находящимися за файрволом, подключаясь к указанным нами портам на нашей же машине. То есть, например, запрещено у нас соединение с IRC-сетями — ну и ладно, мы, например, прокинем 6667 порт на localhost и будем соединяться с ним, а файрвол... Короче, сами придумайте, чем будет заниматься в это время файрвол. :) А с чем едят... Ну там с сыром, с майонезом, с кетчупом... Как обычно... Суть не в этом, а в том, что именно теперь можно забить на ограничения и оттягиваться в полный рост. 8-) Это, собственно, и есть те самые туннели, ради которых и затевался весь сыр-бор. Итак, ...
  Случай первый. Динамический форвардинг
В принципе, самый простой способ пробить дыру в защите и гулять где угодно.

Здесь достаточно указать любой порт (в нашем случае 1080 для определённости) и обозвать его Dynamic (естественно, кнопка «Add» служит для сохранения настроек туннеля в списке). Это будет означать, что соединение с данным портом на локальной машине будет передаваться на сервер, а уже сервер сам будет разбираться, куда это соединение отправлять дальше. Собственно, это самый что ни на есть настоящий SOCKS5 прокси-сервер. То есть использовать это можно так. Например, ставим Skype, в его настройках соединения указываем, что у нас есть прокси по адресу 127.0.0.1 на порту 1080, и к тому же он является SOCKS5-прокси. После этого можем свободно общаться со всем миром. Ну или в любой другой проге, которая поддерживает SOCKS-проксирование, можно указать наш туннель в качестве прокси. Для софта, который SOCKS не поддерживает, можно найти оболочку-socksifier — для винды это будет, например, FreeCap — и уже в нём указать в качестве прокси этот туннель.
  Случай второй. Прямой форвардинг
В этом случае мы эксплицитно явным образом определяем хост и порт назначения, на который хотим выйти, соединяясь с указанным локальным портом. Например, если у нас на сервере поднят кэширующий HTTP-прокси на стандартном порту (мы хотим уменьшить трафик не только от нашего сервера до нас, но и от внешних ресурсов до сервера), можно сделать так:

Это значит, что внутренняя сеть сервера определена как частная сеть класса B (172.16.0.0/12), и что по адресу 172.16.0.1 на стандартном 3128-м порту сидит какой-то HTTP-прокси. А для нас это означает, что теперь мы можем прописать в браузере в качестве проксятника не злой корпоративный, а свой с адресом 127.0.0.1 и портом 3128 (ну или какой укажем в поле «Source port»). После чего можно будет совершенно безнаказанно лазить по одноглазникам, ФСБукам и прочим порно-сайтам. Безусловно, пока кто-нибудь из коллег не настучит админам, или сами админы не решат проверить, какого чёрта у вас резко подскочил SSL-трафик с какого-то странного адреса. Если же порнуха нас уже не интересует, поскольку мы занимаемся серьёзным B-) делом, то наверняка на нашем сервере завёлся Tor. Ну не может такого быть, чтобы уважающий себя параноик не поднял бы Tor. :) Значит делаем так:

Опять же предполагаем (ну или знаем наверняка, если настраивали самостоятельно), что Tor у нас висит на адресе 172.16.0.1 и слушает свой 9050-й порт. Соответственно, в данном конкретном случае, чтобы соединиться с ним, мы цепляемся на 127.0.0.1:9050 — и этот последний адрес можно указывать в браузерах в качестве SOCKS4-прокси (поскольку Tor взаимодействует с браузером по протоколу SOCKS4). Но если бы всё ограничивалось обычным проксированием, это было бы слишком скучно. :) Вот, например, что делать, если мне разрешают ходить на работу со своим ноутбуком, но, подключившись в корпоративную сеть, я имею право просматривать только строго определённые внешние ресурсы, а у меня, например, почтовый клиент настроен на работу с гмылом? Вот в этом случае поможет примерно такая схема:

Прокидываем порт для получения почты.

Прокидываем порт для отправки почты. Не забываем тыкать на кнопочку «Add». :) И в почтовом клиенте указываем в качестве POP-сервера 127.0.0.1:9995, а в качестве SMTP-сервера — 127.0.0.1:5587. Обращаю внимание на номера локальных портов. Теоретически в POSIX-совместимых системах (к которым якобы относится и винда, начиная с NT 4) пользователь не имеет права запускать сервисы на портах ниже 1024 (они считаются привилегированными). Поэтому порт 587 превратился в 5587, а 995 — в 9995. Но, опять же, кто из пользователей винды станет ограничивать себя, любимого, и отбирать у себя администраторские права? Короче, про привилегированные порты можете забыть, если не собираетесь работать с Линуксом. Ну и пример про мыло тоже, наверное, был несколько искусственным. Вот более реалистичный пример. Если мы хотим просто иметь возможность поболтать через Google Talk, то можно сделать так:

А в клиенте прописать в качестве сервера (традиционно) 127.0.0.1:5222.
  Случай третий. Обратный форвардинг
Это редкое извращение, о котором, впрочем, не мешает знать, чтобы разнообразить сексуальную жизнь себе и своим системным администраторам и специалистам по безопасности. :) В чём смысл этого извращения? В том, что мы можем установить соединение с корпоративной машины и указать порт на удалённом сервере, на который можно соединяться, чтобы получить доступ к локальным/корпоративным ресурсам. Например, у нас есть корпоративный сайт, доступ на который разрешён только из внутренней сети. Более того — доменное имя и ip-адреса этого сайта относятся к зарезервированным частным диапазонам (например, www.corporate.local висит на адресе 192.168.35.100). И вот нам во что бы то ни стало приспичило что-то там посмотреть на этом сайте откуда-то снаружи, предположим, с домашнего компа на выходных. Для этого создаём вот такой туннель:

Сразу же после соединения появляется возможность зайти снаружи на сервер (предполагается, что тоже по ssh), указать в браузере адрес 127.0.0.1:8181 и лицезреть вожделенный корпоративный сайт. Кому уж он нафиг нужен — это другой вопрос, но вдруг... :) Думаю, не нужно отдельно заострять внимание на том, что соединение от корпоративной машины до ssh-сервера должно быть железобетонным, поскольку если оно упадёт, у вас не будет гномика, который вам его опять поднимет без вашего непосредственного участия. Ну да, конечно, можно это делать скриптами. Но это уже совсем другая история... :)

Запуск!

  Итак, если вы всё ещё не отказались от безумной идеи пробить брешь в кило-мега-супер-пупер-защите, то как можно быстрее перемещайтесь в раздел «Session», сохраняйте ещё раз настройки и тыкайте на кнопку «Open». Если всё было сделано правильно, то сервер запросит у вас пароль (поскольку, как вы помните, имя пользователя мы решили отправлять автоматически), после ввода которого можно пользоваться всеми бонусами и примусами, которые мы понаоткрывали.
Первую часть можно найти в предыдущем посте, а третью — в следующем.