Сам себе сисадмин Рабочие заметки о системном администрировании В статье дан подробный анализ теории и практики построения SSH-туннелей на базе PuTTY. Информации по этому поводу в интернете очень много, однако она не носит систематического характера и зачастую представляет собой лишь разрозненный набор практических рецептов.
Терминология
Для упрощения понимания материала в статье использована терминология, которой я строго придерживаюсь и которая имеет чёткий смысл.
Сервер — компьютер-обработчик запросов. Например, десктоп в локальной сети.
Базовая схема — схема взаимодействия, в которой участвуют лишь Клиент и Сервер.
Расширенная схема — расширение базовой схемы, когда Клиент и Сервер опосредованы Прокси.
Прокси — компьютер-посредник между Клиентом и Сервером в расширенной схеме.
Прямой туннель — туннель, в котором направление инициирования SSH-сесии и запросов совпадают.
Обратный туннель — направление инициирования SSH-сессии и клиентских запросов противоположны.
Source port (исходный порт) — порт на одном из концов туннеля, куда приходит запрос от Клиента.
Может быть для PuTTY локальным «Local» (на том же конце туннеля, что и PuTTY) и удалённым «Remote» (на противоположном конце).
Destination (адрес назначения) — IP-адрес и порт компьютера, для которого предназначены пакеты, выходящие из туннеля. В расшриренной схеме это всегда сам Сервер.
Принцип работы SSH-туннеля
SSH-туннели создаются для решения 2-х независимых задач:
- Обеспечение конфиденциальности данных, передаваемых по защищённому каналу
- Создание связующего мостика (или нескольких мостиков) между Клиентом и Сервером через промежуточные компьютеры, так как Клиент может не иметь прямого доступа к Серверу. В этом случае конфиденциальность является второстепенной или вовсе не требуется.
SSH-туннели могут быть организованы как в режиме перенаправленя отдельных TCP-портов (Port forwarding), так и в режиме настоящих VPN-туннелей через виртуальные интерфейсы, когда передаваться может трафик любых протоколов и с любых портов. В данной статье мы рассмотрим первый режим.
При работе в режиме Port Forwarding пакет, поступающий на входной порт туннеля, должен быть передан в неизменном виде на его выходной порт. Такая схема применяется в работе интернет-шлюзов: пакеты с одного интерфейса передаются на другой без изменения и анализа.
Таким образом, SSH-канал в этом режме со всей его инфраструктурой напоминает виртуальный шлюз с входным и выходным интерфейсами, но только по конкретной паре TCP-портов:
Стрелкой указано направление инициирования SSH-сессии. В данном случае инициатором соединения выступает Клиент с установленным на нём PuTTY.
Приведённая выше схема является базовой, в которой взаимодействуют лишь 2 участника Клиент и Сервер. На практике же между Клиентом и Сервером может быть несколько промежуточных хостов. И до попадания на вход конкретного туннеля и после выхода из него пакеты могут передаваться по незащищённым каналам.
Для установления связи по SSH-протоколу необходима учётная запись на SSH-сервере, которая может быть любой, в том числе без каких бы то ни было прав и даже без шелла, если вы открываете на прослушивание непривелигированные порты от 1024 и выше. В противном случае необходим рутовый доступ и значение директивы PermitRootLogin равное yes или without-password.
Анализ связности и доступности участников взаимодействия
Приступая к решению задачи о том, как обеспечить доступ с Клиента на Сервер, полезно построить схему связности участников взаимодействия по SSH-протоколу, поскольку именно по этому протоколу создаются туннели, через которые затем можно пропустить данные любого другого протокола.
Для этого мы должны ответить на вопрос, где находятся SSH-серверы и доступны ли они с помощью SSH-клиентов с других хостов.
Рассмотрим эти шаги на базе расширенной схемы, состоящей из Клиента, промежуточного Прокси-сервера и Сервера. На практике такие схемы встречаются чаще всего.
Если соединять стрелками машины, доступные по SSH-протоколу, то возможны следующие варианты:
В частности, мы соединяем стрелкой Клиента с Прокси, если Прокси доступен с Клиента на 22-м порту. Перебрав попарно всех участников взаимодействия, получим схему связности. Например:
Стрелки схемы связности показывают, откуда может быть инициирован туннель на машину с SSH-сервером.
После построения схемы связности необходимо убедиться в доступности участников взаимодействия друг для друга по произвольным протоколам и портам, поскольку к созданному туннелю нужно как-то подключаться, либо, наоборот переправлять данные далее. Иными словами, необходимо проверить пингуются они или нет. По аналогии со схемой связности можно построить схему доступности, которая как минимум совпадает со схемой связности, но чаще всего шире её:
Схема доступности показывает, в каком направлении можно передать данные по незащищённому туннелем каналу.
Комбинация обеих схем помогает ответить на вопрос о том, имеется ли принципиальная возможность установления соединения Клиента с Сервером, а если её нет, то что надо добавить, чтобы её получить.
В дальнейшем мы воспользуемся этими схемами для построения канала связи.
Приведённая выше схема очень распространена: Клиент и Сервер (чаще всего на базе Windows) находятся в разных локальных сетях за NAT, имеют выход в интернет и «видят» удалённый Прокси-сервер, тогда как с Прокси они недоступны ни по SSH ни по другим протоколам. На Прокси, как правило, установлена *nix-подобная операционная система, в которой SSH-сервер есть по умолчанию.
В схемах на базе *nix систем практически все звенья полносвязные, поскольку на всех машинах имеются SSH-серверы, а SSH-порты обычно открыты для подключений.
Далее в статье стрелка SSH-связности указываться не будет, так как совпадает с направлением инициирования туннеля.
Алгоритм построения канала связи с помощью SSH-туннелей
Разберём алгоритм построения канала связи с помощью SSH-туннеля на примере схемы, приведённой выше, где Клиент и Сервер находятся в разных локальных сетях за NAT-ами, и могут быть связаны только через Интернет с помощью некоторого Прокси-сервера.
1) Составление схемы SSH-связности
SSH-сервер у нас имеется только на Прокси, поэтому мы можем инициировать 2 туннеля: с Клиента и с Сервера:
Это схема с двумя односвязными звеньями.
2) Составление схемы доступности
Клиент и Сервер находятся за NAT, поэтому недоступны извне с Прокси, но Прокси пингуется как с Клиента, так и с Сервера
3) Выбор звена для создания туннеля
Для обеспечения связи между Клиентом и Сервером достаточно одного туннеля — либо Клиент-Прокси, либо Прокси-Клиент, так как на оставшемся участке пакеты можно передать по незащищённому каналу.
Туннель Клиент-Прокси выглядит предпочтительнее, поскольку в таком случае все операции по организации связи мы смогли бы произвести с Клиента, и с него же по условиям задачи требуется работать с Сервером.
Пакеты, поступающие на вход туннеля на компьютере Клиента, передаются на Прокси и затем должны перенаправляться на адрес назначения (Destination), которым является Сервер. Однако согласно схеме доступности, Сервер недоступен с Прокси через интернет:
Поэтому для передачи пакетов не обойтись без создания второго туннеля между Прокси и Сервером:
А вот первый туннель, на который мы возлагали надежды, будет в такой схеме избыточен — мы можем направлять пакеты с Клиента на Прокси через незащищённую среду напрямую без использования туннеля:
Туннель Клиент-Прокси можно оставить лишь в том случае, если это важно с точки зрения конфиденциальности (по нему что-то передаётся открытым текстом и т.п.).
4) Выбор типа туннеля Прокси-Сервер: прямой или обратный
На самом деле тип туннеля уже предопределён. Запросы клиента поступают на порт источника (Source Port), который находится на Прокси, а туннель инициируется с Сервера. Это значит, что направление инициирования туннеля и запросов клиента будут противоположны. Следовательно туннель будет обратным (опция -R).
5) Прописывание параметров подключения и создания туннеля
Таким образом, вырисовывается следующий алгоритм построения канала связи
- Составить схему SSH-связности, исходя из расположения SSH-серверов
- Составить схему доступности.
- Выбрать звено: Клиент-Прокси или Прокси-Сервер (для расширенной схемы)
- Выбрать направление инициирования туннеля, если звено полносвязное.
- Выбрать тип туннеля, отталкиваясь от направления запросов клиента: прямой или обратный
- Написать формулы проброса портов в PuTTY (Source port, Destination и дополнительные опции) для каждого туннеля
Понимая описанные выше принципы, легко выставить правильные настройки как на вкладке SSH-Tunnels в PuTTY, так и в командной строке OpenSSH-клиента. В частности, справедливы следующие аксиомы:
Source port — это порт туннеля, на который поступают запросы Клиента.
Если направление инициирования туннеля и запросов Клиента совпадают (прямой туннель), то порт находится на том же конце, что и PuTTY и является для PuTTY локальным (опция -L, Local).
В противном случае Source port находится на противоположной стороне обратного туннеля и для PuTTY является удалённым (опция -R, Remote)
В 99% случаев Source port открывается на прослушивание на петлевом интерфейсе той машины, на которую приходят запросы от Клиента, и поэтому обычно опускается. В PuTTY для IP-адреса источника запросов даже не предусмотрено отдельного места — только Source port.
Destination — это IP-адрес и порт компьютера, на который передаются данные на выходе из туннеля. Если PuTTY находится на Destination, то это, очевидно, будет localhost.
В отличие от петлевого IP-адреса на входе туннеля, данные на выходе из туннеля могут передаваться куда угодно, в том числе на хосты с другими IP-адресами.
Этого достаточно, чтобы выставить правильные настройки для всех вариантов SSH-туннелей. Наиболее типичные из них представлены далее на конкретных примерах.
Приведу, также, синтаксис командной строки OpenSSH клиента в терминах PuTTY, если вы захотите инициировать туннель с какой-нибудь *nix-системы по базовой схеме:
ssh [-g] [-p port] [Source port]:[Destination] user@Сервер
и по расширенной схеме:
ssh [-g] [-p port] [Source port]:[Destination] user@Прокси
Здесь под [Source port] понимается порт с ключами, например: -L 5000 (прямой туннель), -R 5000 (обратный туннель) или -D 5000 (динамический проброс порта; в этом случае [Destination] опускается)
[-p port] — соединиться с Сервером или Прокси на порт, отличный от 22.
[-g] — опция, разрешающая подключение к локальному (Local) или динамическому (Dynamic) порту не только с localhost, но и с внешних адресов.
Для разрешения аналогичной возможности подключения к удалённому (Remote) порту с внешних адресов необходимо прописать в конфигурационном файле SSH-сервера /etc/ssh/sshd_config опцию:
GatewayPorts clientspecified
благодаря которой включение этой возможности производится по запросу клиента, либо
когда эта опция включена всегда.
Базовая схема
В базовой схеме взаимодействия участвуют лишь 2 компьютера, соединённые туннелем.
По этой схеме возможны 2 вида туннелей — прямой и обратный, в зависимости от того, с какой стороны выполняется инициирование SSH-сессии. Согласно этому, PuTTY всегда находится на том конце туннеля, где стрелка начинается.
Расширенная схема
Расширением базовой схемы является схема с промежуточным прокси-сервером, к которому либо подключается Клиент, либо с которого устанавливается соединение с Сервером. Здесь возможны 4 варианта.
В принципе, все четыре варианта расширенной схемы равноправны, если абстрагироваться от конкретной реализации SSH-клиента. Но коль скоро мы рассматриваем в данной статье работу через PuTTY, то инициировать туннели мы можем только с машин на базе Windows, т.е. чаще всего либо с Клиента, либо с Сервера.
Ситуации, в которых SSH-сессия с помощью PuTTY инициируется с промежуточного сервера, довольно редки, так как прокси-серверы обычно представляют собой машины без графической оболочки под управлением *nix-подобных ОС, и вместо PuTTY там будет OpenSSH.
Для полноты картины ниже рассмотрен и синтаксис OpenSSH клиента в терминах PuTTY, если вдруг вам понадобится инициировать туннель с помощью OpenSSH.
Практические примеры применения SSH-туннелей
1. Прямой туннель по базовой схеме
Схема связности и доступности для системы с Клиентом за NAT:
Рассмотрим защиту открытого протокола от перехвата на примере POP3.
Вместо того, чтобы получать почту на локальном компьютере напрямую через интернет и подвергать себя риску утраты пароля, передаваемого в открытом виде, мы получаем её через туннель с почтовым сервером на порт 110. Почтовый клиент в данном случае должен быть настроен на получение писем с адреса localhost:5000
Схема приведена в иллюстративных целях, поскольку все почтовые клиенты сейчас умеют работать по защищённым протоколам, а выбор портов строго ограничен.
Эквивалентная команда для OpenSSH клиента:
Клиент# ssh -L 5000:Сервер:110 user@Сервер
2. Обратный туннель по базовой схеме
Схема связности и доступности для системы с Сервером за NAT:
Это тот случай, когда вам по локальной сети нужно зайти с одного компьютера (Клиент) на другой (Сервер), но прямого соединения с ним не предусмотрено. Однако, с Сервера доступ к Клиенту имеется. Для этого SSH-сессия инициируется с Сервера, то есть с компьютера, к которому мы хотим подключиться. В результате создаётся обратный туннель.
Для поднятия обратного туннеля на Клиент необходимо установить SSH-сервер и указать, с какого удалённого порта (Remote Source port) на какой локальный для PuTTY будет выполняться проброс.
Эквивалентная команда для OpenSSH клиента:
Сервер# ssh -R 5000:localhost:3389 user@Клиент
3. Прямой туннель на SOCKS proxy
Схема связности и доступности для системы с Клиентом за NAT:
Такая схема позволяет безопасно подключаться к интернету через непроверенные источники, например Wi-Fi точки доступа в кафе и ресторанах. Весь трафик идёт через точку доступа в зашифрованном виде с удалённого Сервера.
Как известно, браузер направляет запросы к сайтам в интернет с произвольных портов WAN-интерфейса компьютера. В PuTTY такой режим предусмотрен в в виде опции Dynamic. Все запросы браузера через туннель направляются с некоторого исходного порта 5000 на компьютере с SSH-клиентом, а на другом конце назначаются динамически. Поэтому конечный порт не прописывается.
Поскольку браузеры не умеют работать через SSH-туннели напрямую, в настройках подключения через прокси-сервер нужно выбрать подключение через SOCKS (v5) на адрес localhost:5000 и удалить localhost или 127.0.0.1 из поля «Не использовать прокси для:», если он там прописан автоматически.
Эквивалентная команда для OpenSSH клиента:
Клиент# ssh -D 5000 user@Сервер
Добавляя опцию -g, которая эквивалентна опции PuTTY «Local ports accept connections from other hosts», можно разрешить другим компьютерам подключаться к Клиенту на указанный порт и превратить его, таким образом, в точку доступа.
4. Обратный туннель на SOCKS Proxy
Схема аналогична предыдущей, только с обратной схемой связности (Клиенту запрещён выход в интернет).
Это значит, что инициировать туннель мы можем только с Сервера. Очевидно, что на Клиенте должен быть развёрнут SSH-сервер. Для Клиентов на базе Windows хорошим выбором будет Bitvise SSH-сервер на 443 порту. FreeSSHd сервер с обратными туннелями у меня не заработал.
Итак, чтобы схема работала, нужно сделать из Сервера Socks proxy на 5000-м порту, создав туннель с самим собой:
Сервер# ssh -D 5000 user@Сервер
А после этого установить обратный туннель с Клиентом, в котором запросы на порт XXXX перенаправляются на 5000 порт нашего Socks proxy:
Сервер# ssh -R XXXX:localhost:5000 user@Клиент
Особенность такой схемы в том, что обратные туннели по цепочке можно пробрасывать и далее на другие компьютеры, не имеющие доступа в интернет.
Эта идея лежит в основе аналогичной схемы из данной статьи, но в ней туннель инициируется в обратном направлении выражением следующего вида:
Прокси# ssh -D 5000 -R XXXX:localhost:5000 user@Сервер
А уже затем к Серверу с помощью обратного туннеля подключается компьютер, не имеющий доступа в интернет:
Сервер# ssh -R YYYY:localhost:XXXX user@Компьютер
Однако в данном случае интернет-запрос на порт Сервера XXXX по обратному туннелю перенаправляется на компьютер, играющий роль Прокси-сервера, а затем возвращается на Cервер, чтобы быть обслуженным на нём же:
Очевидно, что в таком способе используется лишняя петля, состоящая из Туннелей 2 и 3, которую мы исключили выше, организовав раздачу интернета непосредственно с самого Сервера.
5. Прямой туннель на промежуточный SSH-сервер
В даном случае туннель создаётся с промежуточным Прокси-сервером, а уже с него выполняется подключение к конечному удалённому Серверу.
Такая схема выручает тогда, когда с локального компьютера нет прямого доступа в интернет, но есть доступ к некоторому серверу внутри локальной сети, который подключен к интернет. Пример схемы связности и доступности для случая, когда Клиент и Прокси находятся за NAT, а Сервер доступен из Интернета:
В другом случае Сервер находится в удалённой локальной сети и недоступен из интернета напрямую, но к нему можно подключиться через промежуточный Прокси в той же локальной сети. Возможная схема связности и доступности для случая, когда Прокси является шлюзом, а Клиент разсположен за NAT в собственной LAN:
В обоих случаях Клиенту нужно подключиться на адрес localhost:5000.
Эквивалентная команда для OpenSSH клиента:
Клиент# ssh -L 5000:Сервер:3389 user@Прокси
6. Обратный туннель на промежуточный SSH-сервер
Эта схема уже подробно рассматривалась в самом начале:
В даном случае нам нужно зайти с домашнего компьютера на удалённый, к которому нет доступа из интернет, но есть промежуточный Прокси, доступный как для Клиента, так и для Сервера. Мы выяснили, что связь можно наладить только с помощью обратного туннеля Сервера с Прокси.
Для разрешения удалённого подключения Клиента необходимо также отметить опцию [Remote ports do the same]. Эта опция работает только в том случае, когда разрешение на подключение на удалённый порт по запросу клиента разрешено в файле конфигурации ssh-демона Прокси-сервера /etc/ssh/sshd_conf:
GatewayPorts clientspecified
После этого Сервер должен стать доступным с Клиента по RDP на адрес Прокси:5000
Эквивалентная команда для OpenSSH клиента:
Сервер# ssh -R 5000:localhost:3389 user@Прокси
Круто!