Как поднять ssh туннель на windows

Вы можете использовать встроенный OpenSSH сервер в Windows для проброса портов через SSH-туннель (SSH туннелирования). Перенаправление портов в SSH позволяет туннелировать (пробрасывать) порты приложений с локального компьютера на удаленный сервер и наоборот. Проброс портов через SSH туннель широко используется в среде Linux/Unix, а теперь вы можете воспользоваться этим возможностями и в Windows. В этом примере мы покажем, как пробросить RDP подключение через OpenSSH на хосте Windows Server.

Для чего нужны SSH-туннели?

SSH-туннель обеспечивает защищенное шифрованный TCP соединение локальных хостом и удалённым сервером SSH. SSH Port Forwarding позволяет туннелировать поверх SSH подключение к локальному порту на локальном компьютере к любому TCP порту на удаленном сервере (или наоборот)

Порт форвардинг в SSH-туннелях применяются для:

• Обхода межсетевых экранов;
• Открытия бэкдоров в частные сети;
• Организации простых VPN/прокси сценариев для безопасного удаленного подключения;
• Защиты трафика устаревших приложений (протоколов), которые передают данные в открытом тексте (без шифрования).

Вы можете перенаправить в SSH туннель только TCP трафик/порт (UDP и ICMP протоколы не поддерживаются).

Проброс портов через SSH туннель можно использовать в сценариях, когда нужно подключиться к удаленному компьютеру, который защищен межсетевым экраном. Например, у вас имеется сервер c Windows, на котором наружу открыт только SSH порт (TCP 22). Все остальные порты блокируются аппаратным межсетевым экраном или Windows Defender Firewall Windows. Ваша задача подключиться к рабочему столу этого Windows сервера с помощью клиента RDP. Казалось бы, невозможная задача, т.к. порт RDP 3389 блокируется брандмауэром. Однако вы можете получить доступ к любому открытому порты на удаленном хосте через SSH-тунель.

Чаще всего используются следующие сценарии проброса через SSH:

• Local TCP forwarding — проброс локального порта на удаленный сервер;
• Remote TCP forwarding — проброс удаленного порта на локальный компьютер;
• Двойной SSH туннель – позволяет соединить между собой через SSH сервер компьютеры без выделенных белых IP адресов или находящиеся за NAT (если не подходит решение с OpenVPN)

Защищенный доступ к RDP через SSH туннель (local TCP forwarding)

В этом режиме вы создаете на своем компьютере локальный TCP порт, подключения к которому перенаправляются через SSH туннель на указанный порт удаленного сервера. В этом примере мы создадим локальный порт 8888, при подключении к которому выполняется перенаправление на RDP порт 3389 на удаленном компьютере. Общая схема подключения выглядит так:

Для проброса портов нам потребуется SSH клиент. Можно использовать сторонний клиент (например, Putty), но я буду использовать встроенный SSH клиент в Windows. Чтобы установить клиенте OpenSSH, выполните в консоли PowerShell команду:

Get-WindowsCapability -Online | ? Name -like 'OpenSSH.Client*'

Чтобы создать SSH туннель с удаленным компьютером 192.168.1.90, выполните команду:

ssh -L 8888:192.168.1.90:3389 [email protected]

В этом примере используется формат
LOCAL_PORT:DESTINATION:DESTINATION_PORT
и
[email protected]_SERVER_IP
(имя пользователя и адрес удаленного SSH сервера)

Чтобы SSH туннель работал в фоновом режиме, нужно добавит параметр –f.

Теперь, чтобы подключится к удаленному компьютеру по RDP через SSH туннель, вам запустить RDP-клиент (mstsc.exe) и подключиться на локальный порт 8888 своего компьютера:

127.0.0.1:8888

Выполните аутентификацию на удаленном компьютере и можете спокойно работать в RDP-сессии. С помощью команды Get-NetTCPConnection или утилиты TCPView вы можете убедиться, что RDP подключение установлено локально (RDP подключение инициировано запущенным локально SSH сервером):

Get-NetTCPConnection -State Established|where {$_.localport -eq "3389"}|fl

TcpTestSucceeded       : False

Обратите внимание, что если вы перенаправляете таким образом незашифрованный трафик приложения, то по сети он передается в зашифрованном виде. Трафик шифруется на одном конце SSH соединения и расшифровывается на другом.

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

mstsc.exe /v 10.10.1.220:8888

Защита RDP подключения с помощью SSH туннеля может быть хорошей альтернативой VPN для доступа к публичным Windows хостам в Интернете. В этом случае вам не нужно открывать прямой доступ к порту RDP/3389 из Интернета к хосту Windows. Достаточно открыть только порт SSH/22, что защитит вас от атак подбора пароля по RDP и эксплуатации 0-day RDP уязвимостей.

Computer : localhost:8888
User name : remoteusername

SSH туннель в Windows с помощью Putty

Рассмотрим, как настроить SSH туннель в Windows с помощью популярного SSH клиента Putty.

1. Запустите PuTTY и перейдите в раздел Connection -> SSH -> Tunnels;
2. В поле Source port укажите локального порта (в нашем примере это 8888);
3. Укажите IP адрес сервера SSH и порт на удаленном хосте, на который нужно выполнить переадресацию:
   192.168.31.90:3389
4. Выберите Local в качестве Destination и нажмите Add;
5. Чтобы не открывать shell удаленного хоста при подключении через туннель, включите опцию Don’t start a shell or command at all в разделе SSH;
6. Вернитесь на вкладку Session, укажите имя или IP адрес удаленного SSH хоста и порт подключения (по умолчанию порт 22). Чтобы сохранить настройки подключения, укажите имя сессии в поле Saved Session и нажмите Save;
7. Теперь вы можете запустить сохраненный SSH туннель в Putty прямо и панели задач Windows.

Переброс удаленного порта на локальную машину (Remote TCP forwarding)

Есть еще один вариант применения SSH туннеля – remote TCP forwarding. Через SSH туннель вы можете открыть доступ удаленному серверу к локальному порту на вашем компьютере или порту на другом компьютере в вашей локальной сети. Например, вы хотите, чтобы внешний сервер (192.168.1.90) получил доступ к вашему Интранет сайту (не опубликованному в Интернете). Для создания обратного туннеля, используйте такую команду:

ssh -R 8080:internalwebsever:80 [email protected]

Теперь, чтобы на удаленном SSH сервер получить доступ к веб серверу internalwebsever достаточно в браузере набрать адрес
http://localhost:8080
.

С помощью SSH туннелей вы можете строить целые цепочки для форвардинга портов. Включить или отключить SSH туннелирование можно в конфигурационном файле OpenSSH (sshd_config) с помощью директив:

AllowStreamLocalForwarding yes
AllowTcpForwarding remote
PermitTunnel no

Данные опции неприменимы для текущей версии OpenSSH в Windows.

В данной статье будет описано как строить SSH–туннели с помощью PuTTY.

1. Локальный проброс порта

Рассмотрим следующую ситуацию. Мы находимся внутри корпоративной сети, у нашего компьютера адрес 192.168.0.2, доступ во внешний мир полностью закрыт (то есть никакого NAT–а, proxy и т.п.). Влиять на политику ограничения доступа у нас возможности нет, но зато есть SSH–доступ на один из серверов с маршрутизируемым IP–адресом, который доступен из Интернета. Внутренний адрес этого сервера, пусть будет для примера 192.168.0.3. Структура сети изображена на рисунке:

Предположим, что нам очень нужно подключиться, к примеру, по SSH на некоторый удалённый сервер с IP–адресом 212.212.212.212 где–то далеко в Интернет. Для этого запускаем PuTTY, создаём SSH–подключение к серверу 192.168.0.3 (далее по тексту SSH–сессия 1), идём в пункт Tunnels:

и указываем, что локальный порт 2222 нашего компьютера должен быть поставлен в соответствие порту 22 на сервере с IP–адресом 212.212.212.212. Далее жмём кнопку «Open», авторизуемся на сервере 192.168.0.3. Затем создаём ещё одно подключение (далее по тексту SSH–сессия 2), но уже на localhost, порт 2222 и жмём кнопку «Open»:

В результате SSH–сессия 2 будет туннелироваться (т.е. будет установлена внутри ранее установленной SSH–сессии 1). Для удалённого сервера 212.212.212.212 всё будет выглядеть так, как будто к нему подключается 111.111.111.111:

2. Удалённый проброс порта

В этом случае подключение внутри SSH–туннеля устанавливается в другую сторону — от удалённого сервера на наш локальный компьютер. Может быть полезно, если требуется открыть доступ к локальным сервисам нашего компьютера. Рассмотрим ту же сеть, что и в пункте 1, но для простоты предположим, что теперь у нас есть NAT:

Здесь уже у нас есть возможность подключаться через SSH напрямую к 212.212.212.212 благодаря наличию NAT–а. А вот 212.212.212.212 подключиться на 192.168.0.2 без специальных ухищрений, понятное дело, не сможет, т.к. 192.168.0.2 не подключён к Интернет непосредственно. Предположим, что пользователю, сидящему под X–ами на 212.212.212.212 нужно через remote desktop попасть на наш компьютер 192.168.0.2. Для этого в SSH–сеансе подключения с 192.168.0.2 на 212.212.212.212 нужно изменить настройки в разделе Tunnels следующим образом:

В результате после успешной авторизации на 212.212.212.212 можно увидеть следующее:

#lsof -i -nP | grep 3333
sshd  18598   avz   11u  IPv4 592868957   TCP 127.0.0.1:3333 (LISTEN)

То есть sshd ожидает подключений на TCP–порт 3333, которые затем по SSH–туннелю будут перенаправлены на 192.168.0.2 порт 3389. И юзер сидящий за 212.212.212.212 сможет с помощью rdesktop увидеть наш рабочий стол:

3. Socks–proxy

В этом случае мы можем использовать сервер с SSH–демоном как промежуточный (proxy). Схема сети как в случае #1 (без NAT и штатных прокси):

Чтобы заставить PuTTY исполнять роль socks–прокси, нужно параметры SSH–сессии с 192.168.0.2 на 192.168.0.3 изменить следующим образом:

В результате после успешной авторизации со стороны клиента можно будет наблюдать следующее:

C:>netstat -ano | find "1080"
  TCP    127.0.0.1:1080     0.0.0.0:0      LISTENING       2392
C:>tasklist | find /i "2392"
putty.exe                2392 Console        0             5420 КБ

То есть putty, выполняющийся с PID–ом 2392, начинает слушать порт 1080, ожидая подключений. Далее бёрем любое приложение, умеющее работать с SOCKS–прокси, например Firefox, и указываем ему использовать наш прокси:

Теперь все запросы от браузера будут проходить через сервер 192.168.0.3. В логах веб–сайтов, по которым мы таким образом будем ходить, будет отображаться внешний IP–адрес нашего сервера — 111.111.111.111.

P.S. Из help–файла Putty 0.58:

Question A.10.3: What does «PuTTY» mean?

It’s the name of a popular SSH and Telnet client. Any other meaning is in the eye of the beholder. It’s been rumoured that «PuTTY» is the antonym of «getty», or that it’s the stuff that makes your Windows useful…

avz.org.ua

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Очень часто, когда речь заходит об удаленном доступе к сетям с низким уровнем безопасности, первое что приходит на ум — это VPN, однако ради административных соединений поднимать VPN не всегда целесообразно, особенно если речь идет об аутсорсинге или «приходящем админе». Кроме того, не всегда условия связи позволяют поднять устойчивое VPN-соединение, особенно если приходится использовать мобильные сети.

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

Строго говоря, SSH-туннели не являются полноценными туннелями и это название следует рассматривать как сложившееся в профессиональной среде устойчивое наименование. Официальное название технологии — SSH Port Forwarding — это опциональная возможность протокола SSH, которая позволяет передать TCP-пакет с одной стороны SSH-соединения на другую и произвести в процессе передачи трансляцию IP-заголовка по заранее определенному правилу.

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

Рассмотрим работу SSH-туннеля более подробно. В качестве примера возьмем классический случай обеспечения доступа к некоторому удаленному серверу по протоколу RDP.

Допустим, что в удаленной сети существует целевой сервер с адресом 192.168.0.105, но доступа к нему из внешней сети нет, единственное устройство к которому мы можем подключиться — это маршрутизатор с адресом 192.168.0.1 с которым мы можем установить SSH-соединение.

Остановимся на очень важном моменте: все параметры SSH-туннеля устанавливает инициатор подключения, он же SSH-клиент, вторым концом туннеля всегда является сервер, к которому мы подключаемся, он же SSH-сервер. В данном контексте следует понимать клиент и сервер сугубо как стороны соединения, например, в роли SSH-клиента может выступать VPS-сервер, а в роли SSH-сервера ноутбук админа.

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

Рассмотрим схему выше. Мы установили SSH-туннель с локальной машины к удаленному маршрутизатору, указав локальную точку входа 127.0.0.1:3389 и правило трансляции 192.168.0.105:3389. Еще раз обращаем ваше внимание, что правило трансляции не указывает на точку выхода, а определяет узел, которому будут посланы пакеты по выходу из туннеля. Если вы укажете недействительный адрес, либо узел не будет принимать соединения, то SSH-туннель установится, но доступа к целевому узлу не будет.

Согласно указанной точке входа служба SSH создаст локальный TCP-сокет, который будет ожидать подключений на порт 3389. Поэтому в окне RDP-подключения указываем в качестве назначения localhost или 127.0.0.1, RDP-клиент открывает динамический порт и отсылает пакет с адресом назначения 127.0.0.1:3389 и адресом источника 127.0.0.1:61256, о реальном назначении получателя пакета ему ничего не известно.

С точки входа данный пакет будет отправлен на другую сторону SSH-туннеля, а адрес назначения согласно правила трансляции будет изменен на 192.168.0.105:3389, и SSH-сервер примет дальнейшее решение согласно собственной таблицы маршрутизации, заменив адрес источника на свой собственный, в противном случае целевой сервер попытается отправить ответный пакет на локальный адрес.

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

Разобравшись в общих чертах как работают SSH-туннели перейдем к практическим вариантам их использования, в качестве платформы мы будем рассматривать Linux-системы семейства Debian/Ubuntu, но все нижеизложенное с небольшими поправками будет справедливо для любой UNIX-подобной системы.

SSH-туннель с локальной точкой входа

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

Мы будем рассматривать все тот-же вариант, RDP-подключение к удаленному серверу, оранжевым пунктиром на схеме обозначено безопасное SSH-соединение, синими стрелками — обычное TCP-подключение.

В самом простом варианте мы просто устанавливаем соединение с клиентского ПК к маршрутизатору в удаленной сети, указывая в правиле трансляции целевой узел:

ssh -L 127.0.0.1:3389:192.168.0.105:3389 user@rt.example.com

Ключ -L указывает на то, что точка входа расположена локально, затем через двоеточие указываются адрес и порт точки входа и адрес, порт правила трансляции. Точкой выхода является узел, к которому мы подключаемся, т.е. rt.example.com.

Если в вашей сети также присутствует маршрутизатор (или иной Linux-сервер), то можно сделать точкой входа его, что позволит подключаться к удаленному серверу любому RDP-клиенту из локальной сети. В теории для этого следует поднять такой туннель:

ssh -L 192.168.31.100:3389:192.168.0.105:3389 user@rt.example.com

В таком случае служба SSH должна будет открыть TCP-сокет на интерфейсе 192.168.31.100, но на практике этого не произойдет. Это связано с особенностями реализации OpenSSH, который является стандартом для подавляющего большинства UNIX-подобных систем.

По умолчанию OpenSSH открывает точку входа только на локальном интерфейсе. В этом несложно убедиться:

Для того, чтобы предоставить доступ к TCP-сокету с внешних интерфейсов следует использовать ключ -g, либо добавить в конфигурационный файл /etc/ssh/sshd_config опцию:

GatewayPorts yes

Однако после этого сокет будет принимать соединения с любого сетевого интерфейса инициатора:

Это значит, что порт 3389 будет открыт на всех сетевых интерфейсах, поэтому если точка входа является пограничным устройством, то следует ограничить доступ к сокету, например, средствами iptables. Для примера заблокируем доступ из внешней сети (интерфейс eth0):

iptables -A INPUT -i eth0 -p tcp --dport 3389 -j DROP

Таким образом рабочий туннель следует поднимать командой:

ssh -L -g 3389:192.168.0.105:3389 user@rt.example.com

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

Также мы советуем использовать по возможности ключ -g, а не добавление опции в конфигурационный файл, так как в последнем случае вы рискуете, забыв об этой настройке, открыть наружу доступ к незащищенным службам удаленной сети.

SSH-туннель с удаленной точкой входа

Туннель с удаленной точкой входа позволяет наоборот опубликовать любую локальную службу в удаленной сети, одно из наиболее частых применений — доступ в сети без выделенного IP-адреса, однако это требует «белый» IP со стороны сети администратора.

В первом варианте удаленный сервер сам устанавливает подключение с маршрутизатором локальной сети. Это можно сделать простой командой:

ssh -R 3389:127.0.0.1:3389 user@rt.example.com

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

Внимательный читатель заметит, что мы не указали ключ -g, да, это так. Дело в том, что для туннелей с удаленной точкой входа данный ключ неприменим и следует использовать опцию

GatewayPorts yes

на стороне SSH-сервера.

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

iptables -P INPUT DROP
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

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

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

ssh -R 3389:192.168.0.105:3389 user@rt.example.com

Снова обратим ваше внимание, что точка входа у нас располагается на противоположной стороне туннеля, поэтому трансляция указывается для стороны инициатора туннеля, т.е. в данном случае SSH-клиент устанавливает два соединения: одно SSH с rt.example.com, а второе RDP c 192.168.0.105, тогда как при туннеле с локальной точкой входа инициатор устанавливает единственное соединение с SSH-сервером.

Двойной SSH-туннель

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

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

Туннель с локальной точкой входа на ПК админа:

ssh -L 3389:127.0.0.1:3390 user@vps.example.com 

И туннель с удаленной точкой входа на RDP-сервере:

ssh -R 3390:127.0.0.1:3389 user@vps.example.com

Мы специально указали на удаленном сервере нестандартный порт для большей наглядности и теперь давайте посмотрим, как все это работает. Начнем с RDP-сервера, он поднимает туннель с удаленной точкой входа, открывая на промежуточном сервере TCP-сокет, который будет принимать подключения на порт 3390, в качестве трансляции укажем сам RDP-сервер — 127.0.0.1:3389, т.е. все пришедшие на вход этого туннеля пакеты будут направлены на локальный порт 3389.

Туннель с локальной точкой входа на ПК админа открывает локальный сокет на порт 3389, куда будет подключаться RDP-клиент, в качестве трансляции мы указываем точку входа второго туннеля — 127.0.0.1:3390.

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

Динамический SSH-туннель

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

Такой вид туннеля особенно удобен, если требуется разовый выход в интернет с другого узла. Простой пример: мой хороший знакомый привез из Штатов два операторских контрактных iPhone и попросил их разблокировать. Сложностей данная операция не таит, если условия контракта не были нарушены, то достаточно зайти на сайт оператора и заполнить заявку на разблокировку. Но проблема оказалась в том, что у оператора T-Mobile доступ к данному разделу сайта был доступен только для жителей США, а соединения с публичных прокси и VPN отвергались как небезопасные.

Динамический SSH-туннель позволил быстро решить эту проблему используя VPS в Штатах. Чтобы создать такой туннель введите команду:

ssh -D 1080 user@vps.example.com

Где 1080 — порт на котором будет доступен наш SOCKS-прокси. Остается только настроить браузер на использование локального прокси-сервера.

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

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

Несколько слов о безопасности

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

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

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

ssh -N -L -g 3389:192.168.0.105:3389 user@rt.example.com

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

SSH-туннели в Windows

На протяжении всей статьи мы рассматривали SSH-туннели на примере Linux-систем и у пользователей Windows могло сложиться впечатление, что им данные возможности недоступны. Но это не так, под Windows существует множество SSH-клиентов, которые поддерживают создание тоннелей. Мы будем рассматривать наиболее популярного из них — PuTTY. Также под Windows можно запустить и SSH-сервер, но это требует определенной квалификации и не всегда можно добиться стабильной работы, поэтому этот вариант мы рассматривать не будем.

Откроем PuTTY и в левой части дерева перейдем в Connection — SSH -Tunnels:

Перед нами откроется следующее окно, основные настройки туннеля сосредоточены внизу, и мы выделили их красной рамкой. Source port — предназначен для указания порта точки входа, которая всегда располагается на локальном интерфейсе (127.0.0.1). Destination — трансляция, т.е. куда будут отправлены пакеты с точки выхода. Радиопереключатели Local — Remote — Dynamic задают тип туннеля и аналогичны ключам -L, -R и -D.

После того, как вы заполнили все необходимые поля можно добавить туннель кнопкой Add. Чтобы разрешить внешним узлам доступ к локальному сокету точки входа установите галочку Local ports accept connections from other hosts. В данном случае следует также ограничить доступ к открытым портам средствами брандмауэра Windows или стороннего сетевого фильтра.

Сервер, к которому мы подключаемся, задается в ином разделе — Session, который знаком каждому, кто хоть раз использовал PuTTY, там же вы можете сохранить параметры сессии для дальнейшего использования.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Использование SSH для создания туннеля — это самый простой и быстрый способ организовать защищенный шифрованный канал связи. Для организации такого туннеля потребуется один компьютер с SSH-сервером и другой с SSH-клиентом. Технология SSH есть практически на любом компьютере с операционной системой Linux. С некоторых пор Microsoft тоже внедрила SSH в свои операционные системы: сервер OpenSSH доступен на Windows Server 2019, а клиент на Windows 10.

Что такое SSH-туннель?
Если обратиться к справке SSH, то там SSH-туннель именуется как Port Forwarding (проброс портов). Такое название наиболее точно выражает суть данной технологии. SSH port forwarding позволяет послать TCP пакет с одной стороны SSH соединения на другую его сторону и произвести трансляцию заголовка по заранее определенному правилу в процессе передачи.

Особенности SSH-туннеля:

1. SSH работает на транспортном уровне, используя протокол TCP. Поэтому завернуть в SSH туннель UDP трафик или пингануть ICMP запросом удаленный хост не получится;
2. В отличии от VPN туннелей, где любой хост может инициировать сеанс, в ssh-туннеле необходимо явно задать «точку входа».

SSH-туннели не подойдут для организации полноценного VPN между двумя сетями так как они создают TCP-соединение, которое всего лишь транслирует адрес источника или назначения (пробрасывают порт) и не позволяет задействовать другие протоколы транспортного уровня (UDP, ICMP и пр.). Такое соединение не позволит взаимодействовать любому хосту одной сети с любым хостом другой сети.

Есть возможность обойти вышесказанные ограничения, путем создания программного сетевого интерфейса TUN, но здесь тоже есть свои недостатки. Об этом в конце статьи.

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

1. Прямой SSH-туннель: подключаемся к серверу за NAT

Прямой ssh-туннель применяется для того, чтобы перенаправить соединение с заданным TCP-портом на локальном (клиентском) хосте на порт удаленного хоста (сервера). Всякий раз, когда устанавливается соединение с локальным портом или сокетом, соединение пересылается по защищенному каналу, и с удаленного компьютера устанавливается соединение либо с хост-портом, либо с сокетом Unix.

Представляйте этот туннель как проброс порта удаленного хоста через SSH на порт своего компьютера.

Практический пример:

Вам очень нужно подключится к корпоративному веб-сайту, но сделать это из сети интернет нет возможности так как на корпоративном роутере не проброшен через NAT 80 порт. Но на роутере есть ssh-сервер к которому можно подключиться из сети интернет.

Вы устанавливаете соединение SSH-сервером роутера (внешний ip 1.1.1.1), но перед логином с паролем передаете аргумент -L (local port) с правилами проброса порта (точка входа и трансляция). Например, точкой входа будет локальный порт вашего компьютера 8080, который будет транслироваться на 80 порт корпоративного веб сервера (ip 172.16.0.2).

ssh -L 127.0.0.1:8080:172.16.0.2:80 user@1.1.1.1

После создания прямого ssh-туннеля вы сможете подключиться к недоступному через интернет корпоративному веб-сайту, который станет доступен по петлевому адресу и заданному порту http://127.0.0.1:8080.

Кстати, петлевой ip можно не указывать и сократить строку подключения до следующего вида:

ssh -L 8080:172.16.0.2:80 user@1.1.1.1

Как проходят пакеты по прямому ssh-туннелю:

1. На ssh-клиенте TCP-пакеты с адресом источника Src 127.0.0.1:65235 и адресом назначения Dst 127.0.0.1:8080 отправляются в сокет открытый процессом SSH 127.0.0.1:8080;
2. Процесс SSH переписывает адрес назначения tcp-пакета согласно заданного правила трансляции на 172.16.0.2:80 и отправляет на ssh-сервер роутера;
3. Процесс SSHD на роутере смотрит адрес назначение tcp-пакета и отправляет его на порт веб-сервера 172.16.0.2:80. При этом адрес источника Src 127.0.0.1:65235 роутер переписывает на свой 172.16.0.1:11505, чтобы веб сервер отправил ответный пакет роутеру, а не на свой локальный адрес 127.0.0.1.

1.1 Прямой SSH-тунель с перенаправление на локальный порт SSH-сервера

Прямой туннель через ssh можно использовать для подключения к другому порту хоста, на котором установлен ssh-сервер. Например, у вас нет доступа к веб-интерфейсу роутера из сети интернет, но есть к порту ssh. Вы создаете ssh-сеанс с аргументом -L, а в качестве точки входа и адреса трансляции указываете сокеты соответственно 127.0.0.1:8080 и 127.0.0.1:88 (в реальности веб-интерфейсы используют порт 80).

ssh -L 127.0.0.1:8080:127.0.0.1:88 user@1.1.1.1 

Таким образом веб-интерфейс роутера станет доступен на локальном сокете вашего компьютера по адресу http://127.0.0.1:8080.

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

Есть еще один весьма интересный способ создания прямого ssh-туннеля — это туннель с предоставление доступа другим участникам своей локальной сети. По сути, этот тот же прямой туннель, но в качестве точки входа указан не локальный адрес хоста, а его адрес в локальной сети — например, 192.168.0.1.

ssh -L 192.168.0.1:8080:172.16.0.2:80 user@1.1.1.1

Таким образом любой участник локальной сети сможет подключиться на удаленный веб-ресурс через ssh-туннель по адресу http://192.168.0.1:8080.

Если для локальной точки входа указать адрес 0.0.0.0:8080, то доступ к туннелю можно будет получить из любой логической сети. Это может быть удобно в случае получения адреса от dhcp-сервера, так как избавляет от необходимости выяснять какой ip получен.

ssh -L 0.0.0.0:8080:172.16.0.2:80 user@1.1.1.1

2. Обратный SSH-туннель: выставляем ресурсы в Интернет

Обратный SSH-туннель применяется для того, чтобы на удаленном хосте (ssh-сервере) открыть сокет и перенаправлять соединения, устанавливаемые с этим сокетом, на порт локального хоста (ssh-клиента).

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

Практический пример:

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

Вы устанавливаете соединение с ssh-сервером корпоративного роутера (публичный ip 1.1.1.1) и задаете правило обратной трансляции с помощью аргумента -R (remote port). Затем указываете точку входа, находящуюся на удаленном хосте (ssh-cервере), 172.16.0.1:8080 и адрес трансляции на порт локального хоста (ssh-клиента) 127.0.0.1:

Что происходит с пакетом отправленным по обратному SSH-туннелю:

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

2. Процесс sshd переписывает адрес и порт назначения с 192.168.0.1:8080 на 127.0.0.1:80 и отправляет и отправляет его по SSH туннелю стороне инициатору сеанса;

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

3. Динамический SSH-туннель: создаем SOCKS-прокси

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

Практическое применение:

Вы находитесь в кафе и подключились к публичной сети wi-fi, а доступ к ресурсу в интернете заблокирован владельцем точки wi-fi или провайдером. Чтобы обойти эти ограничение нужно создать динамический ssh-туннель до своего хоста с публичным ip-адресом.

ssh -D 8888 user@3.3.3.3

После создания туннеля необходимо указать адрес прокси сервера в настройках операционной. Подробно об этом можете прочесть в статье «Как настроить параметры прокси в Windows 10»

4. SSH-туннель Layer 3 (сетевой уровень): туннелируем udp-трафик

В начале статьи было сказано о том, что ssh-туннель базируется на транспортном протоколе tcp и поэтому отправить в такой туннель udp-трафик не получится. Однако в операционных системах семейства Linux есть возможность создавать tun-интерфейсы, которые работают на сетевом уровне модели OSI и оперируют ip-пакетами.

В организации ssh-туннеля с помощью tun-интерфейсов есть один серьезный недостаток — авторизация на ssh-сервере должна происходить под учетной записью root. Это создает уязвимость вашей компьютерной сети т.к. пароль root будет передаваться через открытую сеть Интернет.

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

• Использовать для root довольно сложный пароль на подобии хэша md5;
• Или настроить авторизацию по ключам.

Для создания туннеля необходимо в конфигурационном файле OpenSSH разрешить туннелирование. Добавьте в файл /etc/ssh/ssh_config следующую строку:

PermitTunnel point-to-point 

Для того чтобы можно было использовать парольную авторизацию root:

PermitRootLogin yes 

Для подключения к ssh-серверу и создания туннеля через tun-интерфейсы используется следующая команда:

sudo ssh root@3.3.3.3 -w 0:0

Аргумент -w создает интерфейсы tun0 на клиенте и сервере.

Затем необходимо настроить ip адреса tun интерфейсов и добавить необходимые маршруты.

На клиенте:

ifconfig tun0 10.0.0.2/30 pointopoint 10.0.0.1
ip route add 172.16.0.0/24 via 10.0.0.1

На сервере:

ifconfig tun0 10.0.0.1/30 pointopoint 10.0.0.2
ip route add 192.168.0.0/24 via 10.0.0.1

Туннели с tun-интерфейсами работают на 3 уровне модели OSI, а значит должны пропускать ICMP и UDP трафик. Поэтому проверку работоспособности туннеля можно выполнить, послав icmp-запрос на какой-либо хост из удаленной сети: ping 172.16.0.100.

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

With the PuTTY suite, you can set up a tunnel either using the PuTTY itself (GUI) or using the command-line tool plink.exe.

With the plink.exe, you use the same arguments as with the OpenSSH ssh, except for the -f, which does not have an equivalent in Windows.

plink.exe -N -L 2000:SomeIp:2000 myusername@myLinuxBox

Reference: Using the command-line connection tool Plink

With the PuTTY, the -L 2000:SomeIp:2000 translates to:

So it’s actually, what you claim to have tried. If you have any problems, use the PuTTY event log to investigate:

The -N translates to the option «Don’t start a shell or command at all».

But it probably does not make sense with a GUI client to enable it, as you get a window anyway, you just cannot do anything with it. See also the PuTTY wish no-terminal-window.

If you are going to use the tunnel to connect with PuTTY to another server, you can actually set up the tunnel as a part of the session settings with use of plink as a proxy, see: PuTTY configuration equivalent to OpenSSH ProxyCommand.