Semenalidery.com

IT Новости из мира ПК
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Ssh туннель linux

Туннели через SSH или «VPN для бедных»

«Если мы видим свет в конце туннеля, то это свет приближающегося поезда» (Роберт Лоуэлл)

Ну да, еще одна неплохая цитата. Эта статья посвящена туннелям через SSH или, как мне больше нравится называть их, «VPN для бедных». Вопреки распространенному среди сисадминов мнению, эти туннели могут быть весьма полезны как для технических специалистов, так и для обычных пользователей. Я говорю «вопреки распространенному мнению», поскольку обратные туннели и туннели с HTTP-трафиком внутри могут обходить файерволы и фильтры содержимого. Но эта статья не о том, как нарушать корпоративную политику пользования Интернетом, она о том, как с помощью SSH-туннелей сделать свою жизнь чуть легче.

Итак, почему SSH-туннели вместо VPN? Вообще-то я использую дома и то, и другое. Если вы читали мои статьи на jaysonbroughton.com, то знаете, что я использую OpenVPN с трехступенчатой аутентификацией (логин, сертификат и одноразовый пароль). Но если я хочу проверить один из моих серверов из дома с помощью Android-устройства или компьютера, на котором у меня нет прав администратора (эти права нужны для моего OpenVPN-клиента) или же подключиться по VNC к ноутбуку моей супруги, чтобы решить ее проблему, то в этом случае я заменяю использование VPN на SSH.

Я дам здесь лишь самые основы: расскажу, как создавать туннели, объясню синтаксис команд, приведу примеры обратных туннелей и причины для использования каждого из них. Кратко коснусь файла ssh_config; более подробно он будет рассмотрен в будущем.

Итак, с чем мы будем работать? Я использую Debian в виртуальном окружении, поэтому ваши реалии могут отличаться от моих. В данном случае я использовал OpenSSH_5.3p1 в качестве сервера и различные OpenSSH-клиенты 5 версии. Перед тем, как углубиться в туннели, хочу сказать следующее: если вам хочется использовать SSH-туннели для шифрования HTTP или обратные SSH-туннели для обхода корпоративного файервола, удостоверьтесь, что вы не нарушаете никаких правил вашей компании. Нечего и говорить о том, что ваши системные администраторы начнут на вас охотиться, как только обнаружат такие проделки; сам будучи системным администратором, я получаю невыразимое удовольствие, отлавливая подобных индивидуумов. По крайней мере, предупредите их, чтобы они не были застигнуты врасплох. LinuxJournal.com и я не несут никакой ответственности за ваши нарушения вашей же корпоративной политики 🙂 Ну, а теперь перейдем к делу.

Создать SSH-туннель довольно просто. А вот решить, что с ним делать, может оказаться немного труднее. Поэтому я приведу несколько примеров, прежде чем мы вдадимся в детали. Я в свое время немного попутешествовал — это было на прежнем месте работы и до того, как у меня родились дети. В поездках мне доводилось останавливаться в самых странных гостиницах (думаю, вы с такими знакомы), оснащенных еще более странными беспроводными точками доступа. Захотите ли вы в гостинице подключиться к точке доступа, у которой SSID написан с орфографическими ошибками? Или в аэропорту, где вы обнаруживаете сразу несколько открытых точек? Если я нахожусь не дома, я пущу HTTP-трафик через туннель между своим устройством на Android (с root-доступом) и домашним сервером. Если же я работаю на ноутбуке, то открою SSH-туннель и пущу HTTP-трафик через Socks5 с тем, чтобы он весь был зашифрован средствами SSH. Я не доверяю открытым точкам доступа настолько, насколько могу. Что еще добавить? Мне приходилось «заворачивать» в туннели SMTP-трафик, когда я попадал в такие места, где блокировались исходящие SMTP-пакеты. То же самое мне приходилось делать и с POP3, с которого я недавно перешел на IMAPS. Другие примеры SSH-туннелей включают в себя проброс приложений X11 и сеансов VNC. Ранее я также упоминал обратные туннели. Они представляют собой. ну, вы сами понимаете — туннели, направленные в обратную сторону. В этом случае вы подключаетесь откуда-либо, где нет сервера SSH, к внешнему SSH-серверу. Потом, зарегистрировавшись на этом сервере, в том числе и локально, вы можете восстановить это подключение. Какая в этом польза, говорите? Ну, например, VPN-сервер вашей компании «упал» или работает только с VPN-клиентами под Windows, но вам совершенно не хочется тащиться с ноутбуком домой, чтобы проверить, работает ли тот или иной процесс. Придя домой, вы можете установить обратный туннель. В этом случае вам следует подключиться с сервера «Икс» к вашей домашней машине. Прибыв домой, вы восстанавливаете подключение к серверу «Икс», таким образом обходя файервол или VPN, и проверяете работу процесса без необходимости подключения по VPN. Я поступаю так очень редко, так как, на мой взгляд, подключение к серверу минуя файервол или VPN — это «плохое кунг-фу» и может использоваться лишь в самом крайнем случае.

Итак, вы получили несколько примеров SSH-туннелей, а теперь посмотрим, как это все делается.

Перед тем, как мы углубимся в работу на клиенте, немного отредактируем файл sshd_config на сервере. В /etc/ssh/sshd_config я обычно вношу некоторые изменения. Но не забудьте перед началом редактирования сделать его резервную копию на случай, если что-то пойдет наперекосяк.

Не забудьте, что если вы внесли какие-либо изменения в sshd_config, то вам нужно будет перезапустить сервис sshd для того, чтобы эти изменения вступили в силу.

А теперь перейдем к ключам. Нет-нет, не тем ключам, которые у вас отобрал папа, когда вы разбили мамину машину, а к ключам командной строки SSH.

Типичный SSH-туннель без перенаправления X выглядит примерно так:

Здесь ключи означают следующее:

-N — не выполнять команд на удаленной машине
-p 22 — подключаться на внешний порт 22. Я обычно использую другой внешний порт, чтобы избавиться от атак «кулхацкеров» на мой SSH-сервер
bob@mylinuxserver.xxx — имя_пользователя@имя_сервера (или IP-адрес)
-L 2110:localhost:110 — информация о привязке портов. Означает следующее: порт_клиента:имя_сервера:порт_сервера. В данном примере мы перенаправляем 110 порт сервера на 2110 порт вашей машины

Хотите еще немного примеров?

Проброс POP3 и SMTP через SSH:

Проброс Google Talk через SSH (ключ -g позволяет удаленным машинам подключаться к проброшенным локальным портам):

Практически все, что передается в виде простого текста, можно обезопасить с помощью SSH-туннелей

Шифрование HTTP-трафика

Еще одна вещь, понятная без лишних слов. Но если в вашей компании действует какая-либо политика относительно ИТ, проверьте, не нарушаете ли вы ее. Я пускаю HTTP-трафик через SSH в тех случаях, когда не доверяю точке доступа. Под Android я использую приложение SSHTunnel, а на ноутбуке — такую команду:

После подключения настройте свой браузер или другую программу, способную использовать прокси на адрес localhost:5222. Таким образом будет создан динамический проброс порта и весь трафик пойдет через SSH-сервер, одновременно шифруясь и обходя фильтрование по содержимому

Перенаправление сеансов X и VNC

Припоминаете, что вы добавили » X11Forwarding yes » в sshd_config? Это-то и позволяет пробрасывать сеансы X.

Вы угадали, -X пробрасывает X. Но учтите, что это работает только на клиентских машинах с Linux. Если вы вдруг оказались вынуждены работать в Microsoft Windows, а вам нужен SSH-туннель, просто установите пакет Cygwin/X ( http://x.cygwin.com/ ). Я лично не пробовал с ним работать, но, насколько я понимаю, он предоставляет возможность запускать удаленные X-приложения, находясь в Windows.

При пробросе сеансов VNC будьте внимательны. Если на клиенте, с котрого вы подключаете туннель, работает VNC-сервер, скажем, на порту 5900, удостоверьтесь, что вы не указали этот порт в качестве перенаправляемого, иначе вы подключитесь к самому себе. Вообще же VNC пробрасывается точно так же, как и любой другой сервис:

В данном примере вы подключаетесь по SSH на внешний порт 2022 сервера mylinuxserver.com от имени пользователя bob. Локальный порт 5900 пробрасывается на порт 5900 на сервере. После установления соединения вы можете открыть свой VNC-клиент и направить его на localhost:0 для подключения к удаленной машине. Если вы пробросили порт 5901, указывайте «localhost:1» и так далее.

Обратные SSH-туннели

Ну, вот и настало время для моей любимой разновидности SSH-туннелей. Разумеется, получать доступ к какому-либо сервису через SSH — это здорово, «гонять» веб-трафик по зашифрованным SSH-туннелям — тоже, но самое приятное удивление можно испытать от обратных туннелей. Как я уже говорил ранее, ими приходится пользоваться в ситуации, когда имеется машина без SSH-сервера, а вы испытываете необходимость получить к ней доступ в дальнейшем (через несколько минут, часов или дней), но при этом не хотите или не можете воспользоваться VPN. Вам следует соединиться с SSH-сервером с этой машины, а затем установить обратный SSH-туннель, подключившись к этому соединению. Для чего я это применяю? Время от времени — для того, чтобы поработать с удаленным сервером или просто для того, чтобы помочь друзьям и родственникам по VNC через SSH. В последнем случае они запускают Putty с сохраненными настройками сеанса и подключаются к моему SSH-серверу от имени пользователя, не имеющего никаких прав. После создания туннеля я могу зайти по VNC на их машины. И все, им не нужно настраивать файервол или разбираться с LogMeIn или другими подобными сайтами.

Итак, для создания обратного SSH-туннеля необходимо выполнить следущие действия:

На клиентской машине:

На стороне сервера:

И вот вам обратный туннель! Вуаля!

Для любителей наглядности пользователи daddoo и nerdboy4200 с канала #linuxjournal подготовили схему последовательностей сообщений с помощью пакета mscgen ( http://www.mcternan.me.uk/mscgen/ ). Да, это пакет с открытым исходным кодом и он обладает потрясающими возможностями. Я попробовал свои силы и создал схему для этой заметки, но то, что за короткое время сделали daddoo и nerdboy, заставило меня устыдиться [своей неумелости — прим. пер.].

Заключение

Ну, вот вы и получили начальные знания в области SSH-туннелей. Не забывайте, что это лишь азы, на самом же деле область применения этих туннелей ограничена лишь вашим воображением. Позднее я опишу настройку файла ssh_config на стороне клиента для сохранения индивидуальных параметров соединений. Но об этом — в следующий раз.

ИТ База знаний

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Популярное и похожее

Установка VirtualBox 6.0 на Linux

Как восстановить пароль от root в CentOS 7

Текстовый редактор Nano — как установить и использовать

8 крутых файловых менеджеров Linux: обзор и установка

Про SSH port forwarding в Linux

SSH туннели один из самых часто используемых методов связи среди системных и сетевых администраторов. В данном руководстве расскажем о такой функции как переброс порта SSH. Это используется для безопасной передачи данных между двумя и более системами.

Читать еще:  Проги для оптимизации

Что такое переброс порта SSH?

Коротко, переброс порта SSH даёт возможность создавать туннель между несколькими системами, а затем настроить эти системы так, чтобы трафик они гнали через этот туннель. Именно по такой логике работает VPN или SOCKS Proxy.

Есть несколько разных методов переброса: переброс локального порта, переброс удалённого порта или динамический переброс. Для начала дадим пояснение каждому из них.

  • Локальный переброс порта позволяет получать доступ ко внешним ресурсам из локальной сети и работать в удаленной системе, как если бы они находились в одной локальной сети. По такому принципу работает Remote Access VPN.
  • Переброс удаленного порта дает возможность удалённой системе получать доступ к вашей локальной сети.
  • Динамический переброс создает SOCKS прокси сервер. После этого настраиваем приложения так, чтобы они использовали это туннель для передачи данных. Чаще всего такой переброс используется для доступа к ресурсам, который по той или иной причине заблокированы для данной страны.

Для чего нужен переброс порта SSH?

Допустим у вас есть какое-то приложение, которые передаёт данные в открытом виде или через нешифрованный протокол. Ввиду того, что SSH создает шифрованное соединение, то вы с легкостью можете настроить программу так, чтобы трафик её шёл через этот туннель.

Он так же часто используется для доступа к внутренним ресурсам извне. Приблизительно это напоминает Site-to-Site VPN, где нужно указывать какой именно трафик нужно заворачивать в туннель.

Сколько сессий можно устанавливать?

Теоретически, можно создавать столько сессий, сколько нам захочется. В сети используется 65 535 различных портов, и мы можем перебрасывать любой из этих портов.

Но при перебросе порта нужно учитывать, что некоторые из них зарезервированы за конкретными сервисами. Например, HTTP использует 80 порт. Значит, переброс на порт 80 возможен только если нужно переадресовать веб трафик.

Порт, который перебрасывается на локальном хосте может не совпадать с портом удаленной системы. Мы легко можем перебросить локальный порт 8080 на порт 80 на удаленной машине. Иными словами, если мы напишем IP адрес нашей машины и порт 8080, то запрос пойдет на 80 порт удалённой системы.

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

Переброс локального порта

Локальная пересылка представляет собой переброс порта из клиентской системы на сервер. Он позволяет настроить порт в системе таким образом, чтобы все соединения на этот порт проходили через туннель SSH.

Для переадресации локального порта используется ключ L. Общий синтаксис команды таков:

Данной командой мы говорим системе, что все запросы на 8080 порт example1.com переадресовывать на example2.com. Это часто используется когда нужно организовать доступ извне на внутренний ресурсы компании.

Тестирование работы переадресованного порта

Чтобы проверить, работает ли переадресация должным образом можно воспользоваться утилитой netcat. На машине, где была запущена команда переадресации нужно ввести команду netcat в следующем виде:

Если переадресация работает и трафик проходит, то утилита вернёт «Успех!». В противном случае выдаст ошибку об истечении времени ожидания.

Если что-то не работает, нужно убедиться, что подключение к удаленному порту по SSH работает корректно и запросы не блокируются межсетевым экраном.

Создание постоянного туннеля (Autossh)

Для создания туннеля, который будет активен постоянно используется так называемая утилита Autossh. Единственно требование это необходимость настройки между двумя системами аутентификацию по публичным ключам, чтобы не получать запросы на ввод пароля при каждом обрыве и восстановлении соединения.

По умолчанию, Autossh не установлен. Чтобы установить эту утилиту введем команду ниже.

Синтаксис утилиты autossh почти похож на синтаксис ssh:

Переброс удалённого порта

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

А общий синтаксис команды выглядит так:

Динамическая переадресация портов

Динамическая переадресация портов позволит ssh функционировать как прокси-сервер. Вместо переброса трафика на специфический порт, здесь трафик будет идти через на диапазон портов.

Если вы когда-нибудь пользовались прокси сервером для посещения заблокированного сайта или просмотра контента, недоступного в вашем регионе, вероятнее всего вы пользовались SOCKS сервером.

Динамическая переадресация также обеспечивает некоторую приватность. Она затрудняет логирование и анализ трафика, так как трафик проходит через промежуточный сервер. Для настройки динамической переадресации используется следующая команда:

Таким образом, если нужно весь трафик идущий на порт 1234 направить на SSH сервер, нужно ввести команду:

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

Множественная переадресация

Иногда приходится перебрасывать несколько внутренних портов на несколько внешних. Допустим у нас на одном и том же сервере крутятся и веб сервер и oracale. В таком случае мы можем указать несколько условий переадресации ставя перед каждым из них ключ L для локальной переадресации и R для внешней.

Просмотр списка туннелей

Чтобы просмотреть сколько SSH туннелей активны на данный момент можно прибегнуть к помощи команды lsof:

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

Ограничение переадресации портов

По умолчанию, переброс портов SSH активен для всех. Но если нужно ограничить переадресацию портов в целях безопасности, то нужно отредактировать файл sshd_config.

$ sudo vi /etc/ssh/sshd_config

Здесь есть несколько опций, позволяющих ограничивать создание SSH туннелей.

PermitOpen позволяет прописать адреса, для которых можно включить переадресацию портов. Тут можно указать конкретный IP адреса или название хоста:

AllowTCPForwarding данная опция включает или отключает переадресацию портов для SSH. Так же можно указать какой тип переадресации допускается на этом хосте.

Для подробной информации можно вызвать руководство по файлу sshd_config:

Уменьшение задержки

Проблема с переадресацией портов на SSH это возможность увеличения задержки. При работе с текстовой информацией э то не критично. Проблема даёт о себе знать если по сети идёт много трафика, а SSH сервер настрое как SOCKS сервер, то есть на нём настроена динамический переброс портов.

Это происходит по той причине, что SSH туннели по сути это TCP туннель поверх TCP. Это не очень эффективный метод передачи данных.

Для решения проблемы можно настроить VPN, но если по какой-то причине предпочитаете SSH туннели, то существует программа sshuttle, которая устраняет проблему. На Ubuntu или других дистрибутивах семейства Debian программу можно установить командой

Если же программы нет в репозиториях дистрибутива, то можно взять ее с GitHub:

Настройка туннеля в sshuttle отличается от SSH. Чтобы завернуть весь трафик в туннель нужно ввести следующую команду:

Прервать соединение можно комбинацией клавиш Ctrl+C. Чтобы запустить sshuttle как демон, нужно добавить ключ D.

Чтобы убедиться что туннель поднят и в глобальной сети показывается другой IP, в терминале можно ввести команду:

Или же просто открыть любой другой сайт, который покажет белый IP и местоположение.

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

Учимся использовать SSH туннелирование для безопасного серфинга

Существует три различных типа туннелирования, и все они используются для решения разных задач. Каждая задача предполагает использование SSH-сервера для перенаправления трафика из одного сетевого порта в другой. Трафик передается по зашифрованному SSH-соединению , поэтому его нельзя отследить или изменить в процессе передачи:


Туннелирование можно реализовать с помощью ssh-команды в Linux , Mac OS и операционных системах семейства UNIX . Для пользователей Windows , где нет встроенной ssh-команды , мы предлагаем бесплатный инструмент PuTTY . Он умеет подключаться к SSH-серверам . Он также поддерживает SSH-туннелирование .

Локальное перенаправление портов (port forwarding): получаем доступ к удалённым ресурсам на локальной системе

« Локальное перенаправление портов » позволяет осуществлять доступ к ресурсам, находящимся внутри локальной сети. Предположим, что нужно попасть на офисный сервер БД, сидя дома. В целях безопасности этот сервер настроен так, чтобы принимать подключения только с ПК, находящихся в локальной сети офиса. Но если у вас есть доступ к SSH-серверу , находящемуся в офисе, и этот SSH-сервер разрешает подключения из-за пределов офисной сети, то к нему можно подключиться из дома. Затем осуществить доступ к БД. Проще защитить от атак один SSH-сервер , чем защищать каждый ресурс локальной сети по отдельности.

Чтобы сделать это, вы устанавливаете SSH-соединение с SSH-сервером и говорите клиенту передать трафик с указанного порта на локальном ПК. Например, с порта 1234 на адрес сервера базы данных и его порт внутри офисной сети. Когда вы пытаетесь получить доступ к БД через порт 1234 на вашем ПК (« localhost ») трафик автоматически « туннелируется » по SSH-соединению и отправляется на сервер БД.

SSH-сервер выступает посредником, пересылая трафик туда-сюда. При этом можно использовать любую командную строку или графический инструмент для осуществления доступа к базе данных, как вы обычно делаете это на локальном ПК.

Чтобы использовать локальное перенаправление, подключитесь к SSH-серверу с использованием вспомогательного аргумента -L . Синтаксис для туннелирования трафика будет следующим:

Предположим, что офисный сервер находится по адресу 192.168.1.111 . У вас есть доступ к SSH-серверу через адрес ssh.youroffice.com , и имя вашего аккаунта на SSH-сервере — bob . В таком случае необходимая команда будет выглядеть следующим образом:

Запустив эту команду, вы попадете на офисный сервер баз данных через порт 8888 на localhost . Если у СУБД есть веб-интерфейс, можно вписать в адресную строку браузера http://localhost:8888 . Если у вас инструмент командной строки, которому необходим сетевой адрес базы данных, то направьте его на localhost:8888 . Весь трафик, отправленный на порт 8888 на ПК, будет перенаправлен на 192.168.1.111:1234 внутри офисной сети:


Это слегка сбивает с толку, если надо подключиться к серверному приложению, запущенному в той же системе, где и сам SSH-сервер . К примеру, есть SSH-сервер , работающий на порте 22 на офисном ПК. Но у вас также есть сервер баз данных, работающий на порте 1234 в той же системе по тому же адресу. Вам нужно подключиться к БД из дома, но система принимает только SSH-подключение через 22 порт , и сетевой экран не пропускает любые внешние подключения. В таком случае можно запустить следующую команду:

При попытке подключиться к БД через 8888 порт на вашем ПК, трафик будет передаваться с помощью SSH-подключения . Когда он достигнет системы, в которой работает SSH , SSH-сервер отправит его на порт 1234 на « localhost », принадлежащий тому же ПК, на котором запущен SSH-сервер . То есть, « localhost » в приведённой выше команде означает « localhost » с перспективы удалённого сервера:

Читать еще:  Bluestacks 4 оптимизация


Чтобы сделать это в PuTTY на Windows , выберите опцию Connection > SSH > Tunnels . Далее опцию « Local ». В поле « Source Port » укажите локальный порт. В поле « Destination » введите целевой адрес и порт в формате удалённый_адрес:удалённый_порт .

Например, если нужно настроить SSH-тоннель , как это сделано выше, то введите 8888 в качестве порта-источника и localhost:1234 в качестве целевого адреса. После этого нажмите « Add » и затем « Open », чтобы открыть SSH-подключение . До подключения SSH туннелирования нужно ввести адрес и порт самого SSH-сервера в разделе « Session »:

Дистанционное перенаправление портов: открываем доступ к локальным ресурсам на удалённой системе

« Дистанционное перенаправление портов » — ситуация, противоположная локальному перенаправлению, и используется не так часто. Она позволяет открывать доступ к ресурсам на локальном ПК через SSH-сервер . Предположим, что на локальном ПК настроен веб-сервер. Но ваш ПК защищён сетевым экраном, который не пропускает входящий трафик на сервер.

Если есть доступ к удалённому SSH-серверу , можно подключиться к этому SSH-серверу и использовать дистанционное перенаправление портов. Ваш SSH-клиент укажет серверу перенаправлять трафик с определённого порта – скажем, 1234 – на SSH-сервере на указанный адрес и порт на вашем ПК или внутри локальной сети. Когда кто-то подключается к порту 1234 на SSH-сервере , этот трафик автоматически « туннелируется » по SSH-соединению . Любой, кто подключается к SSH-серверу , сможет получить доступ к серверу, запущенному на вашем ПК. Это достаточно эффективный способ обхода фаерволов.

Чтобы воспользоваться дистанционным туннелированием IP , используйте ssh-команду с аргументом — R . Синтаксис здесь будет практически таким же, как и в случае с локальным перенаправлением:

Предположим, что нужно создать серверное приложение, прослушивающее порт 1234 на вашем ПК. Оно доступно через порт 8888 на удалённом SSH-сервере . Адрес SSH-сервера ssh.youroffice.com , а ваше имя пользователя на SSH-сервере bob . Значит, команда будет следующей:

Затем кто-то может подключиться к SSH-серверу через порт 8888 , и это подключение будет туннелировано на серверное приложение, запущенное на порте 1234 ПК , с которого вы подключались:


Чтобы сделать это в PuTTY для Windows , выберите опцию Connection > SSH > Tunnels . Далее – опцию « Remote ». В поле « Source Port » укажите удалённый порт. В поле « Destination » введите целевой адрес и порт в формате локальный_адрес:локальный_порт .

Например, если нужно настроить SSH-тоннель , как это сделано выше, то укажите 8888 в качестве порта-источника и localhost:1234 в качестве целевого адреса. После этого нажмите « Add » и затем « Open », чтобы открыть SSH-подключение . До подключения нужно будет ввести адрес и порт самого SSH-сервера в разделе « Session ».

После этого пользователи смогут подключаться к порту 8888 на SSH-сервере и их трафик будет передаваться на порт 1234 на вашей локальной системе:


По умолчанию, удалённый SSH-сервер будет слушать только подключения с того же хоста. Другими словами, доступ будет только у людей из той же системы, на которой запущен SSH-сервер . При туннелировании трафика так делается в целях безопасности.

Нужно включить опцию « GatewayPorts » в sshd_config на удалённом SSH-сервере , если хотите изменить эти настройки.

Динамическое перенаправление портов: используем SSH-сервер в качестве прокси

Также существует « динамическое перенаправление портов », которое работает по тому же принципу что прокси или VPN-сервер . SSH-клиент создаёт SOCKS-прокси , который можно настраивать под собственные приложения. Весь трафик, отправляемый через прокси, будет отправляться через SSH-сервер . Принцип здесь схож с локальным перенаправлением – берётся локальный трафик, отправленный на определённый порт на вашем ПК, и перенаправляется через SSH-соединение на удалённый адрес.

Предположим, что вы используете общедоступную Wi-Fi сеть. Но хочется делать это безопасно. Если у вас есть доступ к SSH-серверу из дома, то можно подключиться к нему и использовать динамическое перенаправление. SSH-клиент создаст SOCKS-прокси на вашем ПК. Весь трафик, отправленный на этот прокси, будет отправляться через подключение к SSH-серверу . Никто из тех, кто использует общедоступную Wi-Fi сеть, не сможет отслеживать ваши перемещения в сети или закрывать доступ к сайтам. С перспективы сайтов, которые посещаете, будет казаться, что вы заходите на них с домашнего ПК.

Или же может понадобиться подключиться к медиа-серверу, находящемуся в вашей домашней сети. В целях безопасности, к интернету подключен только ваш SSH-сервер . При этом вы не разрешаете подключаться к медиа-серверу через интернет. В таком случае можно включить динамическое перенаправление портов, настроить SOCKS-прокси в браузере и затем подключаться к серверам, работающим в домашней сети, через браузер, как будто вы сидите дома.

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

Чтобы воспользоваться динамическим перенаправлением, запустите ssh-команду с аргументом — D :

Предположим, что у вас есть доступ к SSH-серверу по адресу ssh.yourhome.com , а ваш логин на SSH-сервере – bob . Нужно использовать динамическое перенаправление для того, чтобы открыть SOCKS-прокси по порту 8888 на текущем ПК. Тогда команда для SSH туннелирования будет выглядеть следующим образом:

После этого можно настроить браузер или другое приложение на использование локального IP-адреса (127.0.0.1) и порта 8888 . Весь трафик этого приложения будет перенаправляться через туннель:


Чтобы сделать это в PuTTY для Windows , выберите опцию Connection > SSH > Tunnels . Далее – опцию « Dynamic ». В поле « Source Port » укажите локальный порт.

Например, если вам нужно настроить SOCKS-прокси на порт 8888 , то введите 8888 в качестве порта-источника. После этого нажмите « Add » и затем « Open », чтобы открыть SSH-подключение .

После этого можно настроить приложение на подключение через SOCKS-прокси на вашем локальном ПК ( то есть, по IP-адресу 127.0.0.1 , который ведёт на ваш локальный ПК ) и указать корректный порт для работы:


К примеру, можно настроить браузер Firefox на использование SOCKS-прокси . Это удобно, так как у Firefox могут быть отдельные настройки прокси, и поэтому не обязательно использовать базовые параметры для всей системы. Firefox будет отправлять трафик через SSH туннелирование , а другие приложения будут использовать интернет-подключение в обычном режиме.

Туннель будет оставаться активным и открытым до тех пор, пока открыта сессия SSH-соединения . Когда вы завершите SSH-сессию и отключаетесь от сервера, туннель тоже закроется. Чтобы снова открыть туннель, переподключитесь при помощи соответствующей команды или нужной функции в PuTTY .

Как настроить SSH туннель для частного просмотра

Главное меню » Операционная система Linux » Как настроить SSH туннель для частного просмотра

Один из вариантов заключается в использовании VPN, но для этого требуется установка клиентского программного обеспечения на вашем компьютере и настройка собственного VPN-сервера или подписка на службу VPN.

Простейшей альтернативой является маршрутизация локального сетевого трафика с помощью зашифрованного туннеля прокси SOCKS. Таким образом, все ваши приложения, использующие прокси-сервер, подключаются к SSH-серверу, и сервер будет перенаправлять весь трафик на его фактическое место назначения. Ваш интернет-провайдер (ISP) и другие третьи стороны не смогут проверять ваш трафик и блокировать доступ к веб-сайтам.

В этой статье вы узнаете о процессе создания зашифрованного туннеля SSH и настройки браузеров Firefox и Google Chrome для использования прокси SOCKS.

Предпосылки

  • Сервер работает с любым дистрибутивом Linux, с SSH-доступом для маршрутизации вашего трафика через него.
  • Веб-браузер.
  • Клиент SSH.

Настройка туннеля SSH

Мы создадим туннель SSH, который будет безопасно перенаправлять трафик с вашей локальной машины на порт 9090 на сервер SSH на порту 22 . Вы можете использовать любой номер порта больше, чем 1024 .

Linux и macOS

Если на вашем локальном компьютере вы запускаете Linux, macOS или любую другую операционную систему на основе Unix, вы можете легко запустить SSH-туннель с помощью следующей команды:

  • -N – Указывает SSH не выполнять удаленную команду.
  • -D 9090 – Открывает туннель SOCKS по указанному номеру порта.
  • [USER]@[SERVER_IP] – Ваш удаленный SSH пользователя и IP-адрес сервера.
  • Для запуска команды в фоновом режиме используйте эту опцию -f .
  • Если ваш SSH-сервер прослушивает порт, отличный от порта 22 (по умолчанию), используйте этот параметр -p [PORT_NUMBER] .

После запуска команды вам будет предложено ввести свой пароль пользователя. После входа в систему вы войдете на свой сервер, и будет создан туннель SSH.

Вы можете настроить аутентификацию на основе ключа SSH и подключиться к серверу без ввода пароля.

Windows

Пользователи Windows могут создавать туннель SSH с помощью клиента SSH PuTTY.

    Запустите Putty и введите IP-адрес вашего сервера в поле Host name (or IP address) .

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

Настройка браузера для использования прокси-сервера

Теперь, когда вы открыли туннель SSH SOCKS, последний шаг – настроить предпочтительный браузер для его использования.

Fire Fox

Ниже приведены шаги для Windows, MacOS и Linux.

  1. В правом верхнем углу нажмите значок гамбургера, ☰ чтобы открыть меню Firefox:
  2. Нажмите на ссылку ⚙ Preferences .
  3. Прокрутите вниз до раздела Network Settings и нажмите на кнопку Settings. .
  4. Откроется новое окно.
    • Выберите переключатель Manual proxy configuration .
    • Введите 127.0.0.1 в поле SOCKS Host и 9090 в поле Port .
    • Установите флажок Proxy DNS when using SOCKS v5 .
    • Нажмите на кнопку OK , чтобы сохранить настройки.

На данный момент ваш Firefox настроен, и вы можете просматривать Интернет, как ваш туннель SSH. Чтобы проверить его, вы можете открыть его google.com , введите “what is my ip” и вы увидите IP-адрес вашего сервера.

Чтобы вернуться к настройкам по умолчанию, перейдите в раздел Network Settings , выберите радио-кнопку Use system proxy settings и сохраните настройки.

Также есть несколько плагинов, которые могут помочь вам настроить настройки прокси-сервера Firefox, такие как FoxyProxy.

Google Chrome

Google Chrome использует настройки прокси-сервера по умолчанию. Вместо изменения настроек прокси-сервера вашей операционной системы вы можете использовать аддон, например SwitchyOmega, или запустить веб-браузер Chrome из командной строки.

Чтобы запустить Chrome с использованием нового профиля и вашего туннеля SSH, используйте следующую команду:

Linux:

macOS:

Windows:

Профиль будет создан автоматически, если он не существует. Таким образом, вы можете одновременно запускать несколько экземпляров Chrome.

Чтобы подтвердить, что туннель SSH работает правильно, откройте google.com и введите “what is my ip”. IP-адрес должен быть IP-адресом вашего сервера.

Заключение

Вы узнали, как настроить туннель SSH SOCKS 5 и настроить браузер для доступа к Интернету конфиденциально и анонимно.

Если вы столкнулись с проблемой, оставьте комментарий ниже.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Как работает SSH-туннелирование

SSH туннель или SSH Port Forwarding, как его называет man(1) ssh – это опциональный функционал протокола, который работает поверх всем знакомой обычной SSH сессии. SSH туннель позволяет послать TCP пакет с одной стороны SSH соединения на другую его сторону и произвести трансляцию IP заголовка по заранее определенному правилу в процессе передачи.

Понять, как работает SSH туннель очень просто: если представить его в виде point-to-point соединения. Так же как и в PPP, любой пакет, попавший в один конец соединения, будет передан и получен на другом конце туннеля. Дальше, в зависимости от адреса получателя заданного в IP заголовке, пакет будет либо обработан принимающей стороной туннеля (если пакет предназначается непосредственно ей), либо смаршрутизирован дальше в сеть (если адресатом является другой узел сети).

Основное отличие SSH туннеля от PPP соединения в том, что в SSH туннель можно завернуть только TCP трафик. (Примечание: есть несколько хаков, как можно передать UDP через TCP-сокет внутри SSH туннеля, но это решение выходит за рамки данной статьи).

Второе отличие состоит в том, что в point-to-point соединении входящий трафик может быть инициирован с любой стороны, тогда как для SSH туннеля необходимо явно задать «точку входа» для трафика. «Точка входа» – это параметр вида : , указывающий какой сокет открыть для входа в туннель (с локальной или удалённой стороны SSH сессии).

Кроме точки входа дополнительно нужно указать правило вида : , по которому должен быть переписан заголовок (точнее, адрес и порт назначения) TCP пакета в процессе передачи. Точка входа может задаваться с любого конца туннеля. За этот параметр отвечают ключи –L (local) и –R (remote). Под local и remote подразумеваются стороны туннеля с точки зрения стороны-оригинатора, то есть того хоста, который устанавливает SSH сессию.

Пока выглядит немного запутанно, поэтому давайте разберём на конкретном примере.

Прямой туннель SSH — обеспечиваем доступ к серверу за NAT

Алекс работает системным администратором в маленькой компании Qwerty Cakes, занимающейся производством яблочных пирогов. Вся сеть компании находится в одном броадкаст домене 192.168.0.0/24. Для доступа в интернет используется программный маршрутизатор на базе Linux, адрес которого 192.168.0.1 со стороны сети компании и 1.1.1.1 со стороны сети Интернет. На маршрутизаторе поднят и работает демон OpenSSD, который доступен по сокету 1.1.1.1:22. Внутри сети на сервере с адресом 192.168.0.2 установлен внутренний корпоративный портал, на котором до завтрашнего утра Алексу нужно сделать изменения через Web интерфейс. Однако Алекс не хочет задерживаться на работе допоздна, он хочет получить доступ к порталу из дома со своего домашнего компьютера с адресом 2.2.2.2.

Алекс приходит домой и после ужина устанавливает следующее соединение с маршрутизатором компании:

Что произошло? Алекс установил SSH сессию между адресами 2.2.2.2 и 1.1.1.1, при этом открыв локальную «точку входа» в туннель 127.0.0.1:8080 на своем домашнем компьютере:

$ sudo lsof -nPi | grep 8080

ssh 3153 alex 4u IPv4 9862 0t0 TCP 27.0.0.1:8080 (LISTEN)

Любой TCP пакет, который попадёт в сокет 127.0.0.1:8080 со стороны компьютера Алекса, будет отправлен по point-to-point соединению внутри сессии SSH, при этом адрес назначения в TCP заголовке будет перезаписан с 127.0.0.1 на 192.168.0.2, а порт с 8080 на 80.

Теперь Алексу, чтобы попасть на портал своей компании, нужно всего лишь набрать в браузере:

Как проходят сетевые пакеты внутри SSH-туннеля

Давайте детально разберём, что произошло с TCP пакетом в процессе его прохождения по SSH туннелю:

1. TCP пакет с адресом источника 127.0.0.1 и адресом и портом назначения 127.0.0.1:8080 попал в сокет 127.0.0.1:8080, открытый процессом ssh;

2. Процесс ssh получил пакет, в соответствии с правилом трансляции переписал адрес и порт назначения на 192.168.0.2:80 и отправил его внутри SSH сессии удалённой стороне 1.1.1.1;

3. Процесс sshd на маршрутизаторе 1.1.1.1 получил пакет и, просмотрев адрес назначения, отправил его хосту 192.168.0.2, переписав при этом адрес источника с 127.0.0.1 на адрес собственного интерфейса 192.168.0.1, для того чтобы получатель, который ничего не знает про существование SSH туннеля, вернул пакет роутеру, а не отправил в свой же localhost 127.0.0.1.

В данном примере, если бы портал или любой другой ресурс, к которому Алексу нужно получить доступ, находился на самом роутере (например, по адресу 192.168.0.1:80), то команда выглядела бы следующим образом:

$ ssh -L 127.0.0.1:8080:192.0.0.1:80 alex@1.1.1.1

Если сервис доступен по адресу localhost (например, локальный SQL сервер), то и к нему можно получить доступ:

Конструкции вида -L 127.0.0.1:80:127.0.0.1:80 могут выглядеть, на первый взгляд, довольно странными. Но в них нет ничего сложного, если помнить, что решение о маршрутизации пакета принимается на удалённой стороне туннеля. Нужно помнить основное правило: вторая пара : обрабатывается удалённой стороной туннеля.

Поэтому пакет с адресом назначения 127.0.0.1 в правиле трансляции будет обработан второй стороной SSH сессии, и никак иначе.

Как вы уже, наверное, догадались, точку входа в туннель можно создавать не только на loopback интерфейсе. Если туннель нужно сделать доступным не только для локального хоста, но и для других участников сети, то в качестве адреса сокета можно указать реальный адрес интерфейса.

Компьютер Алекса Alex-PC имеет два сетевых интерфейса с адресами 2.2.2.2 и 10.0.0.5. В процессе установления сессии ssh откроет сокет 10.0.0.5:8080 на компьютере Alex-PC. Теперь Алекс может получить доступ к порталу 192.168.0.2:80 со своего ноутбука с адресом 10.0.0.4 и со всей своей домашней сети 10.0.0.0/24.

Обратный SSH-туннель — выставить свои ресурсы в интернет

Как я уже говорил, точку входа в туннель можно открывать не только со стороны оригинатора ssh сессии, но и с удалённой стороны, то есть с той, к которой мы устанавливаем ssh сессию. Для этого вместо параметра -L используется параметр -R. Для чего это нужно?

Например, для того, чтобы можно было опубликовать локальный сервис для удалённого доступа.

На ноутбуке Алекса запущен Web сервер apache доступный по адресу 127.0.0.1 с тестовой копией портала компании. Алексу нужно дать доступ к Web серверу своим коллегам для проведения тестирования интерфейса. Вообще, для подобных целей Алексу неплохо было бы реализовать более надёжную тестовую песочницу. Но так как наш Алекс не более чем виртуальный персонаж этой статьи, он для демонстрации работы SSH туннеля устанавливает сессию между своим ноутбуком и маршрутизатором Linux. А с помощью параметра -R открывает порт 8080 на внутреннем интерфейсе маршрутизатора с адресом 192.168.0.1, который ссылается на сокет 127.0.0.1:80 его тестового Web сервера.

Как видите, на маршрутизаторе процесс sshd открыл локальный сокет 8080

sudo lsof -nPi | grep 8080

17233 alex 9u IPv4

95930 0t0 TCP 192.168.0.1:8080 (LISTEN)

Давайте посмотрим, что произойдёт с TCP пакетом, отправленным с компьютера 192.168.0.200 в сторону тестового портала, опубликованного на 192.168.0.1:8080:

1. TCP пакет с адресом источника 192.168.0.200 и адресом и портом назначения 192.168.0.1:8080 попадёт в сокет 192.168.0.1:8080, открытый процессом sshd;

2. Процесс sshd, получив пакет, в соответствии с правилом трансляции перепишет адрес и порт назначения с 192.168.0.1:8080 на 127.0.0.1:80 и отправит его внутри SSH сессии стороне-оригинатору 2.2.2.2;

3. Процесс ssh на ноутбуке Алекса, получив пакет и просмотрев адрес его назначения, перепишет адрес отправителя с 192.168.0.200 на адрес своего loopback, и отправит его в локальный сокет 127.0.0.1:80, открытый процессом apache.

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

Одно важное замечание, которое я оставил на конец статьи.

Если при открытии точки входа в туннель используется localhost вместо адреса реального интерфейса, то его можно опустить, сократив, таким образом, команду с

$ ssh -L 127.0.0.1:8080:192.0.0.1:80 alex@1.1.1.1

Эта важная особенность синтаксиса пригодится нам в следующем примере.

Двойное туннелирование

Давайте посмотрим на чуть более сложный пример. Пользователю SQL-Tester, находящемуся за NAT, нужно получить доступ к базе данных на SQL сервере, который тоже находится за NAT. SQL-Tester не может установить соединение напрямую к серверу, так как в NAT серверной сети нет соответствующих трансляций. Однако от обоих хостов можно установить SSH сессию с промежуточным сервером 3.3.3.3.

С SQL сервера устанавливаем SSH соединение с сервером 3.3.3.3 и открываем на loopback интерфейсе сервера 3.3.3.3 порт 13306, ссылающийся на локальный сервис SQL, запущенный на локальном сокете 127.0.0.1:3306 SQL сервера:

$ ssh -R 13306:127.0.0.1:3306

Теперь с клиентского хоста SQL-Tester устанавливаем соединение с 3.3.3.3 и открываем порт 3306 на loopback интерфейсе клиента, который, в свою очередь, ссылается на 127.0.0.1:13306 на сервере 3.3.3.3, который… ссылается на 127.0.0.1:3306 на SQL сервере. Всё просто.

Динамический туннель — SSH как Socks-прокси

В отличие от туннелей с явным указанием правил трансляции, динамический туннель работает совсем по другому принципу. Вместо указания однозначного сопоставления вида адрес:порт для каждого адреса и порта назначения, вы открываете сокет на локальной стороне SSH сессии, который превращает ваш хост в прокси-сервер, работающий по протоколу SOCKS4/SOCKS5. Давайте разберем

Создаём сокет динамического туннеля 127.0.0.1:5555 на хосте client внутри сессии SSH к серверу 2.2.2.2

$ ssh -D 5555 user@2.2.2.2

Проверяем, что порт открыт

$ sudo lsof -nPi | grep 5555

IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (LISTEN)

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

Теперь весь трафик браузера будет идти через SOCKS прокси внутри шифрованного соединения SSH между хостами 1.1.1.1 и 2.2.2.2.

Как использовать SSH в Microsoft Windows?

Прочитав статью, вы возможно, решите, что все преимущества SSH туннелей доступны только пользователям Unix-like систем. Однако это не так. Практически все терминальные клиенты для Windows работающие по протоколу SSH имеют поддержку туннелирования.

С некоторых пор, имеется возможность использовать Windows не только в качестве клиента SSH. Есть возможность установить SSH-сервер на Windows.

В каких случаях использовать SSH-туннели?

Конечно же, для создания постоянных туннелей на боевых серверах нужно использовать специальное программное обеспечение. Но для быстрого решения задачи по пробросу портов, траблшутинга, получения быстрого удалённого доступа да и вообще решения конкретной задачи “здесь и сейчас” зачастую хорошим подспорьем будет использование SSH туннелей.

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

Ссылка на основную публикацию
Adblock
detector