У тебя могут быть самые разные мотивы, чтобы пользоваться ***: недоверенные сети, разного рода ограничения или просто разумное желание не распространять лишний раз свои данные. В этой статье я расскажу, как сделать себе личный *** на арендованном сервере и настроить Open*** и stunnel таким образом, чтобы даже глубокая инспекция пакетов ничего не давала. О сервисах и блокировках Существует бесчисленное множество сервисов, которые предоставляют ***, в том числе и бесплатные. Вот несколько причин, почему бесплатный *** — это плохая идея. Качество. Те, кто пользовался бесплатным ***, знают, что в большинстве случаев сервис просто ужасен: низкая скорость, постоянные обрывы. Это и неудивительно, ведь, кроме тебя, им одновременно может пользоваться еще пара сотен человек. Безопасность. Даже если качество более-менее сносное, ты не знаешь, что на самом деле происходит с твоим трафиком. Хранится и анализируется ли он, кто и в каких целях оперирует сервисом. Бесплатный сыр, как говорится… Малое количество или полное отсутствие опций и настроек: нет возможности выбрать шифр, протокол и порт. Остается только пользоваться тем, что дали. С платными сервисами дела обстоят лучше: можно ожидать какого-то гарантированного качества и наличия настроек. Но ты все еще не можешь знать наверняка, хранятся твои **** непосредственно на сервере или нет. К тому же твоего провайдера могут заблокировать. Великий китайский файрвол, к примеру, научили определять и блокировать трафик Open*** при помощи техники Deep packet inspection (DPI). На какой бы порт ты его ни прятал, будь то UDP 53 или TCP 443, в Китае просто так Open*** не попользуешься. Дело в том, что в режиме TLS трафик Open*** отличается от обычного трафика HTTPS. Если под рукой есть сниффер, в этом несложно убедиться. TLS-трафик Open*** А вот как выглядит обычный HTTPS. Трафик 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 и, следовательно, заблокировать. Трафик, туннелируемый через 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 Code $ 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 Code SELINUX=permissive Перезагружаемся и ставим необходимые пакеты: $ yum install -y iptables-services open*** unzip Code $ yum install -y iptables-services open*** unzip iptables-services — файлы .service для управления утилитой iptables; open*** — сам сервер Open***; зачем нужен unzip, попробуй догадаться сам. Базовая защита Поскольку китайские боты и скрипт-киддиз не дремлют и, скорее всего, уже сейчас пробуют подобрать пароль к твоему серверу, перенесем sshd на другой порт и запретим логин от рута. Перед тем как это сделать, нужно убедиться, что в системе существует другой пользователь с доступом по SSH, или добавить нового и установить для него пароль. $ useradd -G wheel -m eakj $ passwd eakj Code $ 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 Code Port 12222 PermitRootLogin no PasswordAuthentication yes Перечитаем конфиги (systemctl reload sshd), убедимся, что sshd поднялся без проблем (systemctl status sshd), и попробуем открыть дополнительную сессию SSH, не закрывая текущей. Работа на сервере 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 Code $ 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 Code [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 Code $ 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 Code $ ./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 для сервера и клиента. Скопируем сертификат и ключ сервера в /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/ Code $ 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 Code $ cd /etc/open***/server/ $ open*** --genkey --secret ta.key Файл ta.key нужен для директивы tls-auth, которая предоставляет дополнительный уровень защиты для нашего Open***. Этот ключ должен быть и у клиента, поэтому скопируем его в /tmp: $ cp -p ta.key /tmp/ Code $ 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 Code ### 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 Code ### Файлы сертификатов и ключей 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" Code 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 Code ### Включаем возможность использования одного клиентского ### сертификата на многих устройствах одновременно ### для большего контроля — можно выключить (закомментировать) duplicate-cn keepalive 10 120 user nobody group nobody persist-key persist-tun Code user nobody group nobody persist-key persist-tun ### Никаких *****. Есть смысл включить для отладки ### в случае сбоя status /dev/null log /dev/null verb 0 Code ### Никаких *****. Есть смысл включить для отладки ### в случае сбоя status /dev/null log /dev/null verb 0 Также этот конфиг не позволяет клиентам общаться между собой в сети. Если хочется больше контроля, то можно запретить использование одного сертификата на многих устройствах одновременно. Тогда придется генерировать клиентский сертификат для каждого устройства отдельно. Для этого нужно закомментировать duplicate-cn. Чтобы отключить шифрование, устанавливаем cipher none, остальное — без изменений. В этом режиме все еще будет проходить аутентификация, но канал данных шифроваться не будет. Пробуем стартовать: $ systemctl start open***-server@open***-server Code $ systemctl start open***-server@open***-server Смотрим статус: $ systemctl status open***-server@open***-server Code $ systemctl status open***-server@open***-server То, что идет после @, — это название файла с конфигом. Например, если он у тебя называется просто server.conf, тогда будет systemctl start open***-server@server. Если все хорошо, добавляем автоматическую загрузку: $ 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 Code $ 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 Code $ useradd -d /var/stunnel -m -s /bin/false stunnel Проверим, что все успешно: $ ls -ld /var/stunnel Code $ ls -ld /var/stunnel Это делается для того, чтобы не запускать stunnel от root, и дает возможность использовать chroot. Примерно так должен выглядеть /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 Code ### Помни: 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 Code $ cd /etc/stunnel $ openssl req -newkey rsa:2048 -nodes -keyout stunnel-server.key \ -x509 -days 3650 -subj "/CN=stunnel-server" \ -out stunnel-server.crt Так как все сертификаты клиентов должны быть записаны в 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 Code $ 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 нужно будет ввести пароль, не забудь его. Запишем все клиентские сертификаты в clients.crt. Вот что должно примерно получиться: /etc/stunnel/clients.crt ### eakj-desktop -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ### eakj-mobile -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- Code ### eakj-desktop -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ### eakj-mobile -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- Стартуем: $ systemctl start stunnel Code $ systemctl start stunnel И проверяем: $ systemctl status stunnel` Code $ systemctl status stunnel` Статус stunnel Если все хорошо, то добавляем на автостарт: $ systemctl enable stunnel Code $ systemctl enable stunnel Как и в случае с Open***, скопируем клиентские файлы, а также серверный сертификат в /tmp: $ cp -p eakj-* stunnel-server.crt /tmp/ Code $ cp -p eakj-* stunnel-server.crt /tmp/ Настройка файрвола и маршрутизации Чтобы снизить риск перекрытия доступа самому себе, рекомендую не прописывать iptables в автозагрузку и для начала хорошенько проверить содержимое файла /etc/sysconfig/iptables. Если что-то пойдет не так, то ты сможешь перезагрузить машину и продолжить эксперименты. Утилита iptables — это мощный инструмент, но он не терпит ошибок в конфигурации. Стоит быть предельно аккуратным и перепроверять правила, чтобы случайно не закрыть себе доступ. Открыть его после этого бывает трудно, и все зависит от провайдера VPS. Ну а если уверен, что все настроил правильно, то пиши: $ systemctl enable iptables Code $ systemctl enable iptables В некоторых случаях firewalld может быть установлен и включен по умолчанию, например на минимальной установке CentOS 7.4. Так что для начала лучше проверь: $ systemctl status firewalld Code $ systemctl status firewalld Firewalld в CentOS 7.4.1708 Если он включен, то нужно его остановить и убрать из автозагрузки. $ systemctl stop firewalld $ systemctl disable firewalld $ systemctl status firewalld Code $ systemctl stop firewalld $ systemctl disable firewalld $ systemctl status firewalld Firewalld отключен Убедимся, что список правил у нас пуст (iptables -nvL), и приступим. Список правил 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 Code $ 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). Основной набор правил iptables Далее нам понадобится несколько правил переадресации. $ iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT $ iptables -A FORWARD -i tun+ -s 10.8.8.0/24 -j ACCEPT Code $ 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 тут локальной сети. Вот варианты правил. Помни, что тебе нужно либо 1, либо 2, вместе их не добавляй. 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 — это сам интерфейс. iptables -t nat -A POSTROUTING -s 10.8.8.0/24 -o eth0 -j MASQUERADE. Настройки форвардинга Осталось указать политику DROP по умолчанию для цепочек INPUT и FORWARD, после чего сохраним наши правила. $ iptables -P INPUT DROP $ iptables -P FORWARD DROP $ iptables-save > /etc/sysconfig/iptables Code $ iptables -P INPUT DROP $ iptables -P FORWARD DROP $ iptables-save > /etc/sysconfig/iptables Политика по умолчанию срабатывает после того, как отработали все правила в цепочке. Поэтому перед тем, как ее применить, стоит удостовериться, что все нужные порты открыты. Если на этом этапе ты еще не потерял доступ к своему серверу, тогда добавим правила в автозагрузку и продолжим. $ systemctl enable iptables Code $ systemctl enable iptables Далее нам нужно включить форвардинг пакетов, так как по умолчанию он выключен. Проверить это можно командой $ sysctl net.ipv4.ip_forward Code $ 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 должны быть все необходимые файлы для клиентов. Как видно, некоторые файлы доступны для чтения только руту, что не позволит их скачать при помощи scp (ведь логин от рута у нас запрещен). Поэтому присвоим им другого владельца командой $ chown eakj: /tmp/{ta.key,ca.crt,open***-client.crt,open***-client.key} Code $ 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/ Code $ 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 Code [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). Windows Для начала нужно скачать и установить stunnel. Найти его можно на официальном сайте. Затем нужно скачать клиентские сертификаты и ключи с нашего сервера и поместить их в C:\Program Files (x86)\stunnel\config, как показано на скрине. Я делал это при помощи WinSCP, ты можешь использовать любой удобный тебе клиент SSH. После установки и запуска увидишь главное окно программы. Нужно отредактировать стандартный конфиг, а также переместить или удалить сгенерированные при установке ключи и сертификаты. Я переместил их в папку 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 Code [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 и настроим приложение. Укажем путь к файлу, введем пароль, который запомнили при генерации eakj-mobile.p12, сохраним настройки и запустим сервис. Клиент 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/ Code $ 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 Code 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> Code <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 Code $ systemctl start open***-client@open***-client и проверяем: $ systemctl status open***-client@open***-client Code $ 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***. Конфиг Open*** для Windows Стартуешь и видишь заветную надпись Initialization Sequence Completed — значит, все работает. Open*** и stunnel в Windows Убедимся 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> Code 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), как сделано в примере. Переместим готовый конфиг на устройство и начнем настройку приложения. В главном меню жмешь плюсик, потом «Импорт», выбираешь нужный конфиг и сохраняешь. Open*** на Android: главное меню и импорт профиля Нажимаешь на импортированный профиль и смотришь за процессом подключения. Подключается. Наконец, видим три заветных слова: Initialization Sequence Completed. Все работает! В некоторых случаях может понадобиться подкорректировать значение MSS, о чем это приложение нам любезно сообщит. Удачной отладки! #моястатья
Не получается поднять stunnel Выдает ошибку Failed to start TLS tunnel for netwok daemons В чем может быть проблема? От инструкции неуклонялся.
Job for stunnel.service failed because the control process exited with error code. See "systemctl status stunnel.service" and "journalctl -xe" for details.