Загрузка...

Настройка Open*** и stunnel для создания защищенного канала

Тема в разделе Безопасность создана пользователем Swifty_inactive 18 мар 2018. 2841 просмотр

Сортировать
  1. Swifty_inactive
    Кому понравилось (1)
    Swifty_inactive Автор темы 18 мар 2018 Заблокирован(а) 3 8 ноя 2017
    У тебя могут быть самые разные мотивы, чтобы пользоваться ***: недоверенные сети, разного рода ограничения или просто разумное желание не распространять лишний раз свои данные. В этой статье я расскажу, как сделать себе личный *** на арендованном сервере и настроить Open*** и stunnel таким образом, чтобы даже глубокая инспекция пакетов ничего не давала.

    О сервисах и блокировках
    Существует бесчисленное множество сервисов, которые предоставляют ***, в том числе и бесплатные. Вот несколько причин, почему бесплатный *** — это плохая идея.

    1. Качество. Те, кто пользовался бесплатным ***, знают, что в большинстве случаев сервис просто ужасен: низкая скорость, постоянные обрывы. Это и неудивительно, ведь, кроме тебя, им одновременно может пользоваться еще пара сотен человек.
    2. Безопасность. Даже если качество более-менее сносное, ты не знаешь, что на самом деле происходит с твоим трафиком. Хранится и анализируется ли он, кто и в каких целях оперирует сервисом. Бесплатный сыр, как говорится…
    3. Малое количество или полное отсутствие опций и настроек: нет возможности выбрать шифр, протокол и порт. Остается только пользоваться тем, что дали.
    С платными сервисами дела обстоят лучше: можно ожидать какого-то гарантированного качества и наличия настроек. Но ты все еще не можешь знать наверняка, хранятся твои **** непосредственно на сервере или нет. К тому же твоего провайдера могут заблокировать.



    Великий китайский файрвол, к примеру, научили определять и блокировать трафик Open*** при помощи техники Deep packet inspection (DPI). На какой бы порт ты его ни прятал, будь то UDP 53 или TCP 443, в Китае просто так Open*** не попользуешься. Дело в том, что в режиме TLS трафик Open*** отличается от обычного трафика HTTPS. Если под рукой есть сниффер, в этом несложно убедиться.

    [IMG]
    TLS-трафик Open***
    А вот как выглядит обычный HTTPS.

    [IMG]
    Трафик HTTPS
    Некоторые популярные платные *** предоставляют средства обхода DPI, но чем больше популярность, тем больше шанс, что провайдер узнает о сервисе и сможет полностью заблокировать доступ к нему. От полной блокировки не защищен никто, но, когда используешь публичный сервис, шанс всегда выше.

    Пара слов об Open***
    Open*** использует два канала: канал управления (control channel) и канал данных (data channel). В первом случае задействуется TLS — с его помощью ведется аутентификация и обмен ключами для симметричного шифрования. Эти ключи используются в канале данных, где и происходит само шифрование трафика.

    Существуют скрипты, которые автоматизируют установку, и процесс занимает меньше времени. Но, во-первых, эти скрипты подходят только для конкретных дистрибутивов, а во-вторых, они не предоставляют выбора. Например, используют RSA и AES-CBC, когда есть поддержка ECDSA и AES-GCM. Таким образом, без знания и понимания того, как это работает, ты не сможешь подправить скрипт, чтобы он исполнялся на других системах или делал то, что ты хочешь.

    Что такое stunnel
    Stunnel — это утилита для обеспечения защищенного соединения между клиентом и сервером посредством TLS для программ, которые сами шифровать трафик не умеют. Например, можно туннелировать трафик для netcat, vnc и даже bash. В нашем случае stunnel будет использоваться для маскировки трафика Open*** под «чистый» TLS, чтобы его было невозможно определить посредством DPI и, следовательно, заблокировать.

    [IMG]
    Трафик, туннелируемый через stunnel, ничем не отличается от обычного HTTPS
    С учетом того что Open*** использует шифрование для своего канала данных, у нас есть два варианта настройки:

    • использовать шифрование stunnel плюс шифрование канала данных Open***;
    • использовать шифрование stunnel, а шифрование канала данных Open*** отключить.
    Таким образом, в первом варианте получается два слоя: один от stunnel, второй от Open***. Этот вариант позволит использовать RSA вместе с ECDSA. Недостаток в том, что тратится больше ресурсов, и второй вариант позволит этого избежать. В любом случае настройка stunnel остается неизменной.

    Что нам понадобится
    Провайдер VPS
    Первым делом нужно выбрать провайдера, который нам предоставит виртуальный выделенный сервер (VPS). Что выбирать — дело каждого и зависит от страны и от того, сколько ты готов платить. Главная рекомендация — выбирай страну, наиболее близкую по географическому расположению, это сведет задержку к минимуму. Но, конечно, живя в Китае, покупать сервис в Индии или Пакистане смысла мало.

    Выбор ОС
    Я буду использовать RHEL 7.4. Для точного копирования команд из статьи годится и CentOS 7 (1708), так как это бесплатная и почти идентичная копия RHEL, основанная на его коде. Возможно, подойдут другие дистрибутивы, а также производные RHEL (Fedora), но пути конфигурационных файлов и версии программ могут отличаться.

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

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

    Для начала нам понадобится подключить репозиторий EPEL — пакет open*** лежит именно там.

    Код
    $ yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
    
$ yum update -y



    На RHEL, CentOS, Fedora, OpenSUSE и, возможно, других установлен и включен по умолчанию SELinux. Проверить это можно командой getenforce или sestatus. Чтобы не нырять в дебри его настроек и спастись от возможной головной боли, мы переведем его в режим permissive. В этом режиме он будет оповещать нас о нарушениях политик безопасности, но предпринимать никаких действий не станет. Таким образом, у тебя всегда будет возможность его поизучать. Для этого нужно изменить следующую директиву в файле /etc/selinux/config:

    Код
    SELINUX=permissive



    Перезагружаемся и ставим необходимые пакеты:

    Код
    $ yum install -y iptables-services open*** unzip



    • iptables-services — файлы .service для управления утилитой iptables;
    • open*** — сам сервер Open***;
    • зачем нужен unzip, попробуй догадаться сам.
    Базовая защита
    Поскольку китайские боты и скрипт-киддиз не дремлют и, скорее всего, уже сейчас пробуют подобрать пароль к твоему серверу, перенесем sshd на другой порт и запретим логин от рута. Перед тем как это сделать, нужно убедиться, что в системе существует другой пользователь с доступом по SSH, или добавить нового и установить для него пароль.

    Код
    $ useradd -G wheel -m eakj
    
$ passwd eakj



    где eakj — имя пользователя. В идеале нужно использовать ключи SSH, но в этом случае обойдемся паролем. Не забудь проверить, раскомментирована ли строчка %wheel ALL=(ALL) ALL в файле /etc/sudoers. Теперь изменим следующие директивы в файле /etc/ssh/sshd_config:

    Код
    Port 12222
    
PermitRootLogin no
    
PasswordAuthentication yes



    Перечитаем конфиги (systemctl reload sshd), убедимся, что sshd поднялся без проблем (systemctl status sshd), и попробуем открыть дополнительную сессию SSH, не закрывая текущей.

    [IMG]
    Работа на сервере
    Easy-rsa
    Утилита easy-rsa была создана, чтобы облегчить процесс создания Certificate Authority (CA) и управления ими, а также серверными и клиентскими сертификатами. В идеале для CA нужно выделить специальную машину, но для экономии времени можно использовать все ту же. Поддержку ECDSA добавили в версии 3.0, а в репозиториях у нас 2.2.2, поэтому скачаем последнюю версию с GitHub. Это бинарник, поэтому ничего компилировать уже не придется.

    Код
    $ cd /opt/ && curl -O -L https://github.com/Open***/easy-rsa/archive/master.zip
    
$ unzip master.zip && rm -f master.zip
    
$ cd easy-rsa-master/easyrsa3/ && cp vars.example vars



    Далее в файле vars нужно раскомментировать и настроить некоторые параметры.

    Код
    [SIZE=3][B]/opt/easy-rsa-master/easyrsa3/vars[/B][/SIZE]
    
set_var EASYRSA_DN     "cn_only"
    
set_var EASYRSA_ALGO            ec
    
set_var EASYRSA_CURVE           secp521r1
    
set_var EASYRSA_CA_EXPIRE       3650
    
set_var EASYRSA_CERT_EXPIRE     3650
    
set_var EASYRSA_CRL_DAYS        3650



    Здесь указано, что использовать нужно только Common Name (CN) для Distinguished Name (DN) и криптографию на эллиптических кривых (ec). Также задано название кривой (secp521r1) и время действия сертификатов.

    Некоторые версии OpenSSL отличаются нестабильной работой, так что рекомендую выбирать проверенные эллиптические кривые: prime256v1, secp384r1, secp521r1. В RHEL и родственных дистрибутивах доступны только они. Список можно посмотреть при помощи openssl ecparam -list_curves.
    По умолчанию, easyrsa будет искать vars в той же директории, где и сам исполняемый файл. Но для надежности мы объявим переменную окружения:

    Код
    $ export EASYRSA_VARS_FILE=/opt/easy-rsa-master/easyrsa3/vars



    Создаем свой CA, а также генерируем сертификаты и ключи сервера и клиентов:

    Код
    $ ./easyrsa init-pki
    
$ ./easyrsa --batch build-ca nopass
    
$ ./easyrsa build-server-full open***-server nopass
    
$ ./easyrsa build-client-full open***-client nopass



    где open***-server и open***-client — это наш CN для сервера и клиента.

    [IMG]
    Скопируем сертификат и ключ сервера в /etc/open***/server, а сертификат и ключ клиента — в /tmp.

    Код
    $ cp -p pki/ca.crt pki/private/open***-server.key pki/issued/open***-server.crt /etc/open***/server/
    
$ cp -p pki/ca.crt pki/private/open***-client.key pki/issued/open***-client.crt /tmp/







    Open***-сервер
    Приступим к созданию конфигов и настройки сервера Open***.
    Код

    
$ cd /etc/open***/server/
    
$ open*** --genkey --secret ta.key



    Файл ta.key нужен для директивы tls-auth, которая предоставляет дополнительный уровень защиты для нашего Open***. Этот ключ должен быть и у клиента, поэтому скопируем его в /tmp:

    Код
    $ cp -p ta.key /tmp/



    Пример конфига:

    /etc/open***/server/open***-server.conf
    Код
    ### Bind на loopback-адрес и стандартный порт,
    
### так как коннект из интернета все равно получает stunnel
    
local 127.0.0.1
    
port 1194
    
### Stunnel туннелирует только TCP
    
proto tcp
    
### Режим туннеля
    
dev tun

    Код
    ### Файлы сертификатов и ключей
    
ca ca.crt
    
cert open***-server.crt
    
key open***-server.key
    
### Включаем использование Elliptic Curve Diffie — Hellman (ECDH)
    
dh none
    
### На сервере ставим 0
    
tls-auth ta.key 0
    
### Явно указываем, что можно использовать для канала управления (control channel)
    
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256
    
### Шифр для канала данных (data channel)
    
cipher AES-256-GCM

    Код
    server 10.8.8.0 255.255.255.0
    
### Указываем клиентам перенаправлять весь трафик в туннель,
    
### где 52.214.41.150 — IP сервера
    
push "redirect-gateway def1"
    
push "route 52.214.41.150 255.255.255.255 net_gateway"
    
### Указываем использовать эти DNS
    
push "dhcp-option DNS 208.67.222.222"
    
push "dhcp-option DNS 208.67.220.220"

    Код
    ### Включаем возможность использования одного клиентского
    
### сертификата на многих устройствах одновременно
    
### для большего контроля — можно выключить (закомментировать)
    
duplicate-cn
    
keepalive 10 120

    Код
    user nobody
    
group nobody
    
persist-key
    
persist-tun

    Код
    ### Никаких *****. Есть смысл включить для отладки
    
### в случае сбоя
    
status /dev/null
    
log /dev/null
    
verb 0



    Также этот конфиг не позволяет клиентам общаться между собой в сети. Если хочется больше контроля, то можно запретить использование одного сертификата на многих устройствах одновременно. Тогда придется генерировать клиентский сертификат для каждого устройства отдельно. Для этого нужно закомментировать duplicate-cn.

    Чтобы отключить шифрование, устанавливаем cipher none, остальное — без изменений. В этом режиме все еще будет проходить аутентификация, но канал данных шифроваться не будет.

    Пробуем стартовать:

    Код
    $ systemctl start open***-server@open***-server



    Смотрим статус:

    Код
    $ systemctl status open***-server@open***-server



    То, что идет после @, — это название файла с конфигом. Например, если он у тебя называется просто server.conf, тогда будет systemctl start open***-server@server.

    [IMG]
    Если все хорошо, добавляем автоматическую загрузку:

    $ systemctl enable open***-server@open***-server



    Сервер stunnel
    В репозиториях у нас версия stunnel 4.56, которая не поддерживает верификацию клиентов со стороны сервера, поэтому установим более свежую:

    Код
    $ cd /opt && curl -O -L https://rpmfind.net/linux/fedora/linux/updates/25/x86_64/Packages/s/stunnel-5.41-1.fc25.x86_64.rpm
    
$ rpm -ivh stunnel-5.41-1.fc25.x86_64.rpm
    
### Проверим
    
$ rpm -qi stunnel



    Теперь добавим нового пользователя stunnel и создадим ему домашнюю директорию в /var/stunnel:

    Код
    $ useradd -d /var/stunnel -m -s /bin/false stunnel



    Проверим, что все успешно:

    Код
    $ ls -ld /var/stunnel



    Это делается для того, чтобы не запускать stunnel от root, и дает возможность использовать chroot.

    [IMG]
    Примерно так должен выглядеть /etc/stunnel/stunnel.conf:

    Код
    ### Помни: exec исполняется из каталога chroot!
    
chroot = /var/stunnel
    
setuid = stunnel
    
setgid = stunnel
    
pid = /stunnel.pid
    

    
debug = 0
    

    
## performance tunning
    
socket = l:TCP_NODELAY=1
    
socket = r:TCP_NODELAY=1
    

    
### curve used for ECDHE
    
curve = secp521r1
    
sslVersion = all
    
options = NO_SSLv2
    
options = NO_SSLv3
    

    
[open***]
    
accept = 443
    
connect = 127.0.0.1:1194
    
renegotiation = no
    

    
### RSA
    
ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-SHA
    
cert = /etc/stunnel/stunnel-server.crt
    
key = /etc/stunnel/stunnel-server.key
    
CAfile = /etc/stunnel/clients.crt
    
verifyPeer = yes



    Основные директивы в этом файле:

    • accept = [address:]<port> — указывает, на каком адресе и порте будет слушать наш stunnel;
    • connect = [address:]<port> — указывает, на какой адрес и порт будет перенаправляться трафик;
    • cert = <full path to certificate> — абсолютный путь к сертификату;
    • key = <full path to key> — абсолютный путь к ключу от этого сертификата. Эту директиву можно опустить, если ключ встроен в файл с сертификатом.
    Имя сервиса [open***] заключается в квадратные скобки и может быть произвольным.

    Создадим ключи и сертификаты:
    Код

    
$ cd /etc/stunnel
    
$ openssl req -newkey rsa:2048 -nodes -keyout stunnel-server.key \
    
-x509 -days 3650 -subj "/CN=stunnel-server" \
    
-out stunnel-server.crt



    [IMG]
    Так как все сертификаты клиентов должны быть записаны в clients.crt на сервере, сгенерируем их:

    Код
    $ openssl req -newkey rsa:2048 -nodes -keyout eakj-desktop.key \
    
  -x509 -days 3650 -subj "/CN=eakj-desktop" \
    
  -out eakj-desktop.crt
    

    
$ openssl req -newkey rsa:2048 -nodes -keyout eakj-mobile.key \
    
  -x509 -days 3650 -subj "/CN=eakj-mobile" \
    
  -out eakj-mobile.crt
    

    
$ openssl pkcs12 -export -in eakj-mobile.crt \
    
  -inkey eakj-mobile.key -out eakj-mobile.p12



    При генерации eakj-mobile.p12 нужно будет ввести пароль, не забудь его.

    [IMG]
    Запишем все клиентские сертификаты в clients.crt. Вот что должно примерно получиться:

    /etc/stunnel/clients.crt
    Код
    ### eakj-desktop
    
-----BEGIN CERTIFICATE-----
    
...
    
-----END CERTIFICATE-----
    

    
### eakj-mobile
    
-----BEGIN CERTIFICATE-----
    
...
    
-----END CERTIFICATE-----


    Стартуем:

    Код
    $ systemctl start stunnel



    И проверяем:

    Код
    $ systemctl status stunnel`



    [IMG]
    Статус stunnel
    Если все хорошо, то добавляем на автостарт:

    Код
    $ systemctl enable stunnel



    Как и в случае с Open***, скопируем клиентские файлы, а также серверный сертификат в /tmp:

    Код
    $ cp -p eakj-* stunnel-server.crt /tmp/



    Настройка файрвола и маршрутизации
    Чтобы снизить риск перекрытия доступа самому себе, рекомендую не прописывать iptables в автозагрузку и для начала хорошенько проверить содержимое файла /etc/sysconfig/iptables. Если что-то пойдет не так, то ты сможешь перезагрузить машину и продолжить эксперименты.

    Утилита iptables — это мощный инструмент, но он не терпит ошибок в конфигурации. Стоит быть предельно аккуратным и перепроверять правила, чтобы случайно не закрыть себе доступ. Открыть его после этого бывает трудно, и все зависит от провайдера VPS.
    Ну а если уверен, что все настроил правильно, то пиши:

    Код
    $ systemctl enable iptables



    В некоторых случаях firewalld может быть установлен и включен по умолчанию, например на минимальной установке CentOS 7.4. Так что для начала лучше проверь:

    Код
    $ systemctl status firewalld



    [IMG]
    Firewalld в CentOS 7.4.1708
    Если он включен, то нужно его остановить и убрать из автозагрузки.

    Код
    $ systemctl stop firewalld
    
$ systemctl disable firewalld
    
$ systemctl status firewalld



    [IMG]
    Firewalld отключен
    Убедимся, что список правил у нас пуст (iptables -nvL), и приступим.

    [IMG]
    Список правил iptables
    Нам нужно создать набор базовых правил для файрвола, который говорит:

    • позволять пинг;
    • принимать любой трафик на интерфейс lo;
    • пропускать пакеты на порты 443 и 12222 (еще не забыл, что мы перенесли наш SSH?);
    • а также принимать ответы на наши исходящие запросы. Больше информации о conntrack можно найти в интернете.
    Код
    $ iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    
$ iptables -A INPUT -i lo -j ACCEPT
    
$ iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT
    
$ iptables -A INPUT -p tcp --dport 443 -j ACCEPT
    
$ iptables -A INPUT -p tcp --dport 12222 -j ACCEPT



    Пока эти правила ничем не опасны, так как у них стоит действие ACCEPT, то есть принимать и пропускать. Смотрим, все ли добавилось (снова iptables -nvL).

    [IMG]
    Основной набор правил iptables
    Далее нам понадобится несколько правил переадресации.

    Код
    $ iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    
$ iptables -A FORWARD -i tun+ -s 10.8.8.0/24 -j ACCEPT



    Здесь 10.8.8.0/24 — адрес и маска подсети, которую мы указывали в open***-server.conf.

    Добавим правила, которые позволят клиентам отсылать и принимать пакеты из интернета. Тут возможны два варианта: вариант, когда у тебя есть статический IP, и вариант, когда адрес динамический. Первый лучше тем, что не тратятся ресурсы на определение IP-адреса. Преимущество второго варианта — в том, что не надо иметь статический IP. Если ты не уверен или не знаешь, какой у тебя, используй второй вариант. Для начала узнаем свой адрес командой ip a. У меня сервер за NAT, поэтому и IP тут локальной сети.

    [IMG]
    Вот варианты правил. Помни, что тебе нужно либо 1, либо 2, вместе их не добавляй.

    1. iptables -t nat -A POSTROUTING -s 10.8.8.0/24 -o eth0 -j SNAT --to-source 172.31.26.46, где 172.31.26.46 — это IP, присвоенный интерфейсу, который смотрит в инет, а eth0 — это сам интерфейс.
    2. iptables -t nat -A POSTROUTING -s 10.8.8.0/24 -o eth0 -j MASQUERADE.
    [IMG]
    Настройки форвардинга
    Осталось указать политику DROP по умолчанию для цепочек INPUT и FORWARD, после чего сохраним наши правила.

    Код
    $ iptables -P INPUT DROP
    
$ iptables -P FORWARD DROP
    
$ iptables-save > /etc/sysconfig/iptables



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

    [IMG]
    Если на этом этапе ты еще не потерял доступ к своему серверу, тогда добавим правила в автозагрузку и продолжим.

    Код
    $ systemctl enable iptables



    Далее нам нужно включить форвардинг пакетов, так как по умолчанию он выключен. Проверить это можно командой

    Код
    $ sysctl net.ipv4.ip_forward



    Если вывод команды показывает net.ipv4.ip_forward = 1, то ничего делать не нужно, форвардинг уже включен. Если же net.ipv4.ip_forward = 0, то в файле /etc/sysctl.conf нужно изменить уже существующую или добавить новую строчку net.ipv4.ip_forward = 1. Это позволит нашим изменениям переживать перезагрузку. Далее выполним команду sysctl -p, чтобы изменения применились немедленно.

    Настройка клиентов
    Настройка сервера закончена. Сейчас у нас в /tmp должны быть все необходимые файлы для клиентов.

    [IMG]
    Как видно, некоторые файлы доступны для чтения только руту, что не позволит их скачать при помощи scp (ведь логин от рута у нас запрещен). Поэтому присвоим им другого владельца командой

    Код
    $ chown eakj: /tmp/{ta.key,ca.crt,open***-client.crt,open***-client.key}



    где eakj — это имя пользователя, которого мы создали в начале для доступа по SSH. Не забудь удалить эти файлы из /tmp на сервере. После того как настроишь все свои клиенты, они там только для удобства скачивания.

    Для экономии времени я возьму один и тот же сертификат и ключ для подключения к Open*** в Linux, Windows и Android. Но на Android будет другой сертификат и ключ для подключения к stunnel, так как там придется использовать формат PKCS#12.

    Клиент stunnel
    Linux
    С правами разобрались, перейдем к настройке клиента. Нужно скачать и установить stunnel, обычно он есть в репозиториях и c установкой нет проблем. Также исходники можно найти на официальном сайте.

    В Fedora надо набрать dnf install -y stunnel, в Arch Linux: pacman -S stunnel, в Ubuntu: apt install stunnel4.

    В Ubuntu 16.04.3 LTS пакет stunnel4 имеет версию 5.30, которая не поддерживает верификацию (verifyPeer), поэтому придется или найти свежий пакет, или закомментировать verifyPeer и CAfile. Также нужно изменить ENABLED=0 на ENABLED=1 в файле /etc/default/stunnel4. Возможны и другие мелкие отличия, для их обнаружения понадобится включить логирование.
    Теперь скачаем клиентские файлы командой scp. Обрати внимание, что для записи в /etc/stunnel нужны права рута, поэтому и scp нужно запустить от суперпользователя.

    Код
    $ scp -P 12222 eakj@52.214.41.150:"/tmp/{eakj-*,stunnel-server.crt}" /etc/stunnel/



    Теперь нужно создать клиентский /etc/stunnel/stunnel.conf. Вот пример.

    Код
    [open***]
    
client = yes
    
accept = 127.0.0.1:1194
    
connect = 52.214.41.150:443
    
### Проверить сервер
    
verifyPeer = yes
    
### Для этого нужен его сертификат
    
CAfile = /etc/stunnel/stunnel-server.crt
    
### Сертификат и ключ нужны для проверки
    
### клиента (verifyPeer) на сервере
    
cert = /etc/stunnel/eakj-desktop.crt
    
key = /etc/stunnel/eakj-desktop.key



    Запускаем (systemctl start stunnel) и проверяем (systemctl status stunnel).

    [IMG]
    Windows
    Для начала нужно скачать и установить stunnel. Найти его можно на официальном сайте.

    Затем нужно скачать клиентские сертификаты и ключи с нашего сервера и поместить их в C:\Program Files (x86)\stunnel\config, как показано на скрине. Я делал это при помощи WinSCP, ты можешь использовать любой удобный тебе клиент SSH. После установки и запуска увидишь главное окно программы.

    [IMG]
    Нужно отредактировать стандартный конфиг, а также переместить или удалить сгенерированные при установке ключи и сертификаты. Я переместил их в папку old. Для Windows конфиг почти идентичен линуксовому, только с другими путями.

    Код
    [open***]
    
client = yes
    
accept = 127.0.0.1:1194
    
connect = 52.214.41.150:443
    
### Проверить сервер
    
verifyPeer = yes
    
### Для этого нужен его сертификат
    
CAfile = C:\Program Files (x86)\stunnel\config\stunnel-server.crt
    
### Сертификат и ключ нужны для проверки
    
### клиента (verifyPeer) на сервере
    
cert = C:\Program Files (x86)\stunnel\config\eakj-desktop.crt
    
key = C:\Program Files (x86)\stunnel\config\eakj-desktop.key



    После того как изменил и сохранил конфиг, в окне stunnel жмешь Configuration → Reload Configuration.

    Android
    В качестве клиента stunnel на мобильных устройствах будет использоваться приложение SSLDroid. Перенесем на телефон файл eakj-mobile.p12 и настроим приложение.

    [IMG]
    Укажем путь к файлу, введем пароль, который запомнили при генерации eakj-mobile.p12, сохраним настройки и запустим сервис.

    [IMG]
    Клиент Open***
    Linux
    Скачаем и установим open*** из репозитория. Клиент и сервер идут вместе. В Fedora пили: dnf install -y open***, в Arch Linux: pacman -S open***, в Ubuntu: apt install open***.

    Скачаем файлы клиента с сервера при помощи scp. Для записи в /etc/open***/client/также нужны права рута.

    UbuntuВ Ubuntu клиентские файлы хранятся в /etc/open***/ и сервисы называются open***@<имя конфиг файла>. Например:
    $ systemctl start open***@open***-client



    В репозиториях Ubuntu 16.04.3 LTS пакет open*** имеет версию 2.3.10, а поддержка AES-256-GCM появилась в 2.4. Придется или найти свежий пакет, или использовать шифрование AES-256-CBC (не забудь изменить и на сервере). Также могут возникнуть проблемы с отсутствием группы nobody (фиксится командой groupadd nobody). Если что-то еще пойдет не так, включай **** и чини.

    Код
    $ scp -P 12222 eakj@52.214.41.150:"/tmp/{open***-client*,ca.crt,ta.key}" /etc/open***/client/



    Примерный файл конфигурации /etc/open***/client/open***-client.conf:

    Код
    client
    
dev tun
    
proto tcp
    
remote 127.0.0.1 1194
    
resolv-retry infinite
    
nobind
    
user nobody
    
group nobody
    
persist-key
    
persist-tun
    

    
ca ca.crt
    
cert open***-client.crt
    
key open***-client.key
    
### на клиенте 1
    
tls-auth ta.key 1
    

    
remote-cert-tls server
    
cipher AES-256-GCM
    
verb 3



    Для отключения шифрования делаем то же, что и на сервере: cipher none.

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

    • файл конфигурации (open***-client.conf);
    • сертификат CA (ca.crt);
    • клиентский сертификат (open***-client.key);
    • клиентский ключ (open***-client.key);
    • ключ для tls-auth (ta.key).
    Это может быть не всегда удобно, поэтому есть возможность записать их содержимое в конфигурационный файл. Вместо ca ca.crt, cert client.crt, key client.key и tls-auth ta.key 1 используется <ca>, <cert>, <key>, key-direction 1 и <tls-auth>. Выглядит это примерно так:

    Код
    <ca>
    
содержимое ca.crt
    
</ca>
    
<cert>
    
содержимое open***-client.crt
    
</cert>
    
<key>
    
содержимое open***-client.key
    
</key>
    
### Указываем, что tls-auth на стороне клиента
    
key-direction 1
    
<tls-auth>
    
содержимое ta.key
    
</tls-auth>



    Детальнее пример такого конфига рассмотрим при настройке клиента Android.

    Стартуем:

    Код
    $ systemctl start open***-client@open***-client



    и проверяем:

    Код
    $ systemctl status open***-client@open***-client



    Windows
    Скачать клиент Open*** для Windows можно c официального сайта. Конфиги хранятся в C:\Program Files\Open***\config. После установки нужно скачать клиентские сертификаты и ключи с нашего сервера и поместить их в C:\Program Files\Open***\config, как показано на скрине. Будем использовать те же сертификаты и ключи, что и для Linux (привет duplicate-cn).

    Чтобы создать клиентский конфиг, открывай «Блокнот» от админа, копируй пример и удаляй user nobody и group nobody. Должно получиться как на скрине. Заметь, используется расширение .o***.

    [IMG]
    Конфиг Open*** для Windows
    Стартуешь и видишь заветную надпись Initialization Sequence Completed — значит, все работает.

    [IMG]
    Open*** и stunnel в Windows
    [IMG]
    Убедимся
    Android
    Для Android есть приложение Open*** for Android, будем использовать именно его. Конфиг с записанными в него сертификатами и ключами выглядит примерно так:

    Код
    client
    
dev tun
    
proto tcp
    
remote 127.0.0.1 1194
    
resolv-retry infinite
    
nobind
    
user nobody
    
group nobody
    
persist-key
    
persist-tun
    

    
remote-cert-tls server
    
cipher AES-256-GCM
    

    
### На клиенте можно :-)
    
verb 3
    

    
### Содержимое ca.crt
    
<ca>
    
-----BEGIN CERTIFICATE-----
    
...
    
-----END CERTIFICATE-----
    
</ca>
    

    
### Содержимое open***-client.crt
    
<cert>
    
-----BEGIN CERTIFICATE-----
    
...
    
-----END CERTIFICATE-----
    
</cert>
    

    
### Содержимое open***-client.key
    
<key>
    
-----BEGIN PRIVATE KEY-----
    
...
    
-----END PRIVATE KEY-----
    
</key>
    

    
### Указываем, что tls-auth на стороне клиента
    
key-direction 1
    

    
### Содержимое ta.key
    
<tls-auth>
    
##
    
## 2048 bit Open*** static key
    
##
    
-----BEGIN Open*** Static key V1-----
    
...
    
-----END Open*** Static key V1-----
    
</tls-auth>



    Как ты мог заметить, файл open***-client.crt в начале содержит примерно следующую информацию.

    Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    9b:0a:56:f3:d4:70:97:66:d9:92:81:54:26:fc:9c:53
    Signature Algorithm: ecdsa-with-SHA256
    Issuer: CN=ChangeMe
    Validity
    Not Before: Dec 4 22:02:32 2017 GMT
    Not After : Dec 2 22:02:32 2027 GMT
    Subject: CN=open***-client



    Все это можно опустить и добавить в файл конфига только сам сертификат (от пометок BEGINдо END), как сделано в примере.

    Переместим готовый конфиг на устройство и начнем настройку приложения. В главном меню жмешь плюсик, потом «Импорт», выбираешь нужный конфиг и сохраняешь.

    [IMG]
    [IMG]
    Open*** на Android: главное меню и импорт профиля
    Нажимаешь на импортированный профиль и смотришь за процессом подключения.

    [IMG]
    [IMG]
    Подключается.
    Наконец, видим три заветных слова: Initialization Sequence Completed. Все работает! В некоторых случаях может понадобиться подкорректировать значение MSS, о чем это приложение нам любезно сообщит. Удачной отладки!



    #моястатья
     
    18 мар 2018
  2. shardiw
    shardiw 1 июл 2018 0 30 июн 2018
    Не получается поднять stunnel

    Выдает ошибку Failed to start TLS tunnel for netwok daemons

    В чем может быть проблема? От инструкции неуклонялся.
     
    1 июл 2018
  3. shardiw
    shardiw 1 июл 2018 0 30 июн 2018
    Job for stunnel.service failed because the control process exited with error code. See "systemctl status stunnel.service" and "journalctl -xe" for details.
     
    1 июл 2018
  4. coolbeaver
    coolbeaver 1 июл 2018 Гигант мысли, отец русской порнографии! 180 7 июн 2016
    Я столько за все года обучение не читал...
     
    1 июл 2018
Top
Загрузка...