Admin
Администратор
Выстраиваем простую многозвенную схему с помощью OpenVPN
И снова здравствуйте, уважаемые форумчане, а также те кто сделал свой выбор в пользу того чтобы остаться, особенно после известных событий, а так же вновь(или же снова) пришедшие. Ведь жизнь продолжается, как и не ослабевает интерес к нюансам технического развития нашего любимого форума и к необходимости продолжения наполнения его базы знаний актуальными, а иногда возможно и не очень актуальными, но в то же время интересными темами и их визуальным представлением. В том числе в виде публикаций. Чем собственно мы и попытаемся заняться далее, если получится-).
Целью текущей статьи, из предполагаемого достаточно длинного цикла статей, является детальное описание отдельно взятого VPN решения из целого спектра решений которые мы рассмотрим и опишем в течение всего цикла в различных связках и многозвенных вариациях с целью реализации безопасных и анонимных схем туннелирования трафика путем маскировки, обфускации и с использованием средств их обеспечивающих. И во всем предполагаемом цикле данная статья выступает первой. Мы постараемся в необходимом и достаточном виде рассмотреть весь актуальный стек технологий как с точки зрения запросов общества, так и с точки зрения удовлетворения соверменным технологическим трендам, и в то же самое время, представлять информацию в максимально простом для восприятия виде, насколько это возможно конечно. Исходя из этого, соответственно, каждая из представленных в рамках цикла статей будет опираться в качестве основной базы на одно из популярных VPN решений. Итак, по традиции давайте приступим к обзору первой из них.
Перечислим и опишем весь используемый стек технологий и продуктов представленный здесь в качестве строительного материала для решений:
1. OpenVPN - в данном случае выступит качестве той самой основной базы. И именно его мы будем всячески маршрутизировать, модифицировать, поворачивать, заворачивать и использовать как главный стержень VPN соединений в различных комбинациях.
2. tor - всем давно известный и знакомый tor, тут добавить нечего. Единственное что напомню-это тоже некое подобие соксификатора, только глобального и геораспределенного, который шифрует и пробрасывает трафик приложений сквозь цепь хостов где так же работает служба tor. Подробнее можно изучить в Интернет.
3. obfs4proxy - обфускатор для tor позволяющий не только обфусцировать трафик, но и манипулировать графами маршрутов для сетевого трафика, что значительно повышает уровень безопасности в части анонимности. Рассмотрим его пожалуй очень вскользь скорее для обозначения потенциоальных возможностей и разнообразия, ведь каждая из предствленных технологий имеет свои уникальные преимущества, впрочем как и недостатки, именно потому будем рассматривать их все по чуть-чуть.
Стандартный однозвенный клиент-серверный VPN мы рассматривать предусмотрительно не будем ни в каком виде, поскольку это не очень интересно и потому как подобными инструкциями пестрит весь Интернет куда ни посмотри. Да и не имеет такая схема почти никакой практической пользы в части тематики безопасности, анонимности и обхода прещений. Теперь же приведем и пробежимся по перечню тех комбинаций и связок из вышеприведенных технологий которые будут представлены по ходу обсуждения:
1. Двухзвенная архитектура VPN в нескольких вариантах, так называемый doublevpn, основанный на ранее выбранном нами базовом решении, тоесть OpenVPN, а остальные перечисленные выше технологии предназначены в качестве вспомогательных средств с целью усиления элементов безопасности соединений и всей схемы целиком. Как вы уже успели догадаться, двухвенный-это когда в цепи маршута состоящего из узлов доступа VPN последовательно два хоста.
2. Трехзвенная архитектура в нескольких вариантах часто упоминаемая как triplevpn, в основе которой опять таки OpenVPN. Соответственно тут будет описано три хоста со всеми вышеперечисленными аспектами, за исключением возможно того момента, что не исключено что цепь VPN сети будет иметь не только последовательную структуру графа, но об этом чуть позже.
Ну-с, в путь дорожку, как говорится...
Итак, вариант номер один, настраиваем двухзвенную архитектуру OpenVPN, пока подвариант без проксификаций и обфускаций, самый простецкий. И оговорюсь сразу, в данной статье мы не станем рассматривать глубокие вопросы безопасности цепей VPN серверов по причине достаточно большого числа нюансов, которые необходимо было бы затронуть и в тексте одной статьи охватить все их будет сильно проблематично, и она разбухнет до такой степени, что понять все написанное единым массивом станет сложной задачей. А потому основной упор сделаем на сетевую конфигурацию звеньев, а остальные вопросы, до которых мы непременно доберемся оставим для будущих публикаций:
Вариант с DoubleVPN на основе OpenVPN:
В представленной конфигурации имеем два серверных узла: SERVER_IN и SERVER_OUT, и один условно клиентский узел, где непосредственно расположен тот кто VPN использует в конечном счете, но его конкретно в этой схеме собственно за серверный хост не считаем и пишем что все рассматриваемое нами - это doublevpn.
SERVER_IN - узел к которому подключается клиент, тоесть первая, входное звено для туннельного трафика VPN. ИЗ программного обеспечения на нем установлены операционка Linux, на ней в качестве приложений сервер openvpn к которому подключается клиент, клиент openvpn, который соединяет сервер данного узла с сервером второго узла цепи серверов, стандартный файервол linux iptables, различные сетевые сервисы, такие как сервер ssh, ну и так далее, желательно по-минимуму. В любом решении связанном с попыткой обеспечить безопасность инфраструктура и собственную безопасность тоже обязательно придерживайте правила минимализма, за исключением разве что тех случаев, когда требуется запутать условного противника.
Публичный ip адрес: 192.168.1.1
Внутренний адрес подсети VPN: 10.20.10.0 255.255.255.0
Порт: 21290
SERVER_OUT - выходной узел, соединение с которым инициируется звеном SERVER_IN посредством openvpn клиента, как и было описано выше и что будет представлено непосредственно в конфигурации ниже, в тексте статьи. На этом узле, в свою очередь, установлены все те же программы что и на первом, за исплючением openvpn клиента, поскольку в нашем случае он попросту не нужен.
Публичный ip адрес: 192.168.1.2
Внутренний адрес подсети VPN: 10.20.20.0 255.255.255.0
Порт: 23450
И теперь давайте с вами взглянем на саму конфигурацию:
Для начала создадим PKI и CA сертификаты, соответствено сгенерируем и подпишем созданные сертификаты/ключи, затем создадим crl, cгенерируем ключ tls-crypt и не забудем скопировать все ранее созданные ключи и сертификаты на соответствующие хосты в нужные директории. Но стоить особо отметить, что непосредственно генерацией сертификатов и кдючей лучше всего заниматься на отдельно взятом хосте, таком как специально организованный для этих целей центр сертификации. Но как уже говорилось, более подробно на этом мы пока останавливаться не будем. Это тема будущих материалов и публикаций:
Код:
./easyrsa init-pki && ./easyrsa build-ca nopass
./easyrsa gen-req SERVER_IN nopass && ./easyrsa sign-req server SERVER_IN
./easyrsa gen-req SERVER_OUT nopass && ./easyrsa sign-req server SERVER_OUT
./easyrsa gen-req CLIENT_TO_IN nopass && ./easyrsa sign-req client CLIENT_TO_IN
./easyrsa gen-req CLIENT_TO_OUT nopass && ./easyrsa sign-req client CLIENT_TO_OUT
./easyrsa gen-crl && openvpn --genkey --secret ta.keyРассмотрим блок настроек конфигурации для SERVER_IN, того самого, который является первым звеном в цепи, именно с ним устанавливает первичное соединение пользовательский клиент:
Код:
# openvpn_server.conf
port 21290
proto udp
dev tun_SERVER_IN
server 10.20.10.0 255.255.255.0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/SERVER_IN.crt
key /etc/openvpn/SERVER_IN.key
tls-crypt /etc/openvpn/ta.key
crl-verify /etc/openvpn/crl.pem
verify-client-cert require
user nobody
group nogroup
ifconfig-pool-persist /var/log/openvpn/ipp_SERVER_IN.txt
duplicate-cn no
client-config-dir /etc/openvpn/ccd-client
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 8.8.8.8"
ncp-ciphers AES-256-GCM
cipher AES-256-GCM
auth SHA256
dh none
ecdh-curve X25519
client-to-client no
tls-server
remote-cert-tls client
tls-version-min 1.2
reneg-sec 3600
comp-lzo no
auth-nocache
persist-key
persist-tun
keepalive 10 120
verb 0
# openvpn_client.conf
client
dev tun_CLIENT_FROM_SERV_IN_TO_SERV_OUT
proto udp
remote 192.168.1.2 23450
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/CLIENT_TO_OUT.crt
key /etc/openvpn/CLIENT_TO_OUT.key
tls-crypt /etc/openvpn/ta.key
dh none
ecdh-curve X25519
ncp-ciphers AES-256-GCM
cipher AES-256-GCM
auth SHA256
remote-cert-tls server
tls-version-min 1.2
auth-nocache
verb 0
# sysctl.conf:
net.ipv4.ipforward=1
# iptables_rules:
iptables -A INPUT -p udp --dport 21290 -j ACCEPT
iptables -A FORWARD -i tun_SERVER_IN -o tun_CLIENT_FROM_SERV_IN_TO_SERV_OUT -j ACCEPT
iptables -A FORWARD -i tun_CLIENT_FROM_SERV_IN_TO_SERV_OUT -o tun_SERVER_IN -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.20.10.0/24 -o tun_CLIENT_FROM_SERV_IN_TO_SERV_OUT -j MASQUERADEСделаем необходимые замечения по конфигурации:
Даный блок проталкивает клиенту на хост шлюз по умолчанию и параметры DNS. Использовать его имеет смысл только на самом первом звене, на том, куда устанавливает соединение конечный клиент:
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 8.8.8.8"
Меняем периодически ключи(в цикле): reneg-sec 3600
По истечении указанного времени происходит регенерация нового tls handshake и новых ключей.
0-будет означать не менять, но лучше это делать, а время цикла выбрать оптимальное для своих задач и других настроек.
ecdh-curve X25519: используем эллептическую кривую X25519 при обмене ключами tls.
auth-nocache: отключаем кеширование учетных данных. тут собственно понятно для чего это необходимо.
Отключаем сжатие, поскольку существует эксплуатируемая уязвимость при использовании данной опции: comp-lzo no
И внимательно отнеситесь к настройкам файервола, в том числе к пробросам NAT, а в нашем случае было решено выбрать вариант маскарадинга в силу ряда объективных причин, в том числе в нежелании загромождать большим количеством конфигурации данную статью.
Опишем конфигурацию для SERVER_OUT:
Код:
# openvpn_server.conf
port 23450
proto udp
dev tun_SERVER_OUT
server 10.20.20.0 255.255.255.0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/SERVER_OUT.crt
key /etc/openvpn/SERVER_OUT.key
tls-crypt /etc/openvpn/ta.key
crl-verify /etc/openvpn/crl.pem
verify-client-cert require
user nobody
group nogroup
ifconfig-pool-persist /var/log/openvpn/ipp_SERVER_OUT.txt
duplicate-cn no
client-config-dir /etc/openvpn/ccd-client
ncp-ciphers AES-256-GCM
cipher AES-256-GCM
auth SHA256
dh none
ecdh-curve X25519
client-to-client no
tls-server
remote-cert-tls client
tls-version-min 1.2
reneg-sec 3600
comp-lzo no
auth-nocache
persist-key
persist-tun
keepalive 10 120
verb 0
# sysctl.conf:
net.ipv4.ipforward=1
# iptables_rules:
iptables -A INPUT -p udp --dport 21290 -j ACCEPT
iptables -A FORWARD -i tun_SERVER_OUT -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun_SERVER_OUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.20.20.0/24 -o eth0 -j MASQUERADEКак видим, базовая и большая часть настроек для каждого серверного узла в цепи VPN практически идентичны. Различия появляются в основном лишь в тех местах, где описаны идентификаторы сетей, ключей и сертификатов. Ниже мы сделаем единое описание наиболее интересных параметров конфигурации.
Что нужно сделать на хосте пользовательского клиента. Настройки клиента:
Код:
# openvpn_client.conf:
client
dev tun_CLIENT_TO_SERV_IN
proto udp
remote 192.168.1.1 21290
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/CLIENT_TO_IN.crt
key /etc/openvpn/CLIENT_TO_IN.key
tls-crypt /etc/openvpn/ta.key
dh none
ecdh-curve X25519
ncp-ciphers AES-256-GCM
cipher AES-256-GCM
auth SHA256
remote-cert-tls server
tls-version-min 1.2
auth-nocache
verb 0
# sysctl.conf:
net.ipv4.ipforward=1На клиенте следует обратить внимание на маршрутизацию по умолчанию и если используется линукс, точно так же включить форвардинг сетевого трафика изменением соответствующего значения параметра ядра.
Отдельно сделаем заметку с описанием некоторых параметров настройки конфигурации, как и было обещано выше по тексту:
Обязательно выставляем нулевой уровень детализации журнальной информации в уже рабочей и полностью отлаженном и работающем приложении: verb 0
Как мы видим, ничего сложного в представленной схеме нет, где первый хост в архитектуре выполняет роль как клиента(в качестве клиента для второго хоста), так и сервера(для клиентских подключений пользователя), а последний - только сервера, а так же выходной ноды в публичную сеть Интернет. Вот так все просто и неприхотливо. Повторяюсь, тут мы не рассматриваем детали настроек операционных систем, сопутствующего ПО и не углубляемся во всеобъемлящий контекст безопасности всего набора программ, систем, сетей и периметра в целом. Все это удел будущих статей и последующих обсуждений в них.
Вариант с TipleVPN на основе OpenVPN:
Настало время дополнить двухзвенную архитектуру третьей нодой, чтобы получить уже трехзвенную схему. Правда тут мы добавим толику сложности и в качестве полезного дополнения присовокупим некоторые элементы сетевой безопасности и анонимности. мы попробуем пробросить соединения между нодами через ряд различных инструментов сетевой обфускации. Для примера покажем несколько разных примеров и дадим краткие посянения к ним.
Опишем конфигурацию:
Не будем повторяться относительно уже описанных ранее узлов, а просто дополним схему дополнительной нодой, назвав ее просто SERVER_MIDDLE, и немного изменим сетевые параметры, которую по примеру тех, что уже были описаны ранее. В результате получим такой набор узлов:
SERVER_IN - как и в первом случае, это узел к которому подключается клиент, тоесть первая, входное звено для соединений VPN.
Публичный ip адрес: 192.168.1.1 - опционально, либо адрес в публичной, либо в ТОР сети, либо вместо негоиспользуйте ТОР домен
Внутренний адрес подсети VPN: 10.20.10.0 255.255.255.0
Порт: 21290
Код:
# torrc:
SocksPort 9050
UseBridges 1
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy --managed
Bridge obfs4 x.x.x.x:443 3456856123DDFAEF224216659DAFBCD0124376 cert=MIIDFjKASgkerf... iat-mode=0
HiddenServiceDir /openvpn/SERVER_IN/hiddenservice
HiddenServiceVersion 3
HiddenServicePort 21290 127.0.0.1:21290
# openvpn_server.conf:
port 21290
proto tcp
dev tun_SERVER_IN
server 10.20.10.0 255.255.255.0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/SERVER_IN.crt
key /etc/openvpn/SERVER_IN.key
tls-crypt /etc/openvpn/ta.key
crl-verify /etc/openvpn/crl.pem
verify-client-cert require
user nobody
group nogroup
ifconfig-pool-persist /var/log/openvpn/ipp_SERVER_IN.txt
duplicate-cn no
client-config-dir /etc/openvpn/ccd-client
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 8.8.8.8"
ncp-ciphers AES-256-GCM
cipher AES-256-GCM
auth SHA256
dh none
ecdh-curve X25519
client-to-client no
tls-server
remote-cert-tls client
tls-version-min 1.2
reneg-sec 3600
comp-lzo no
auth-nocache
persist-key
persist-tun
keepalive 10 120
verb 0
#openvpn_client.conf
client
dev tun_CLIENT_FROM_SERV_IN_TO_SERV_MIDDLE
proto tcp-client
remote 192.168.1.2 22340
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/CLIENT_TO_MIDDLE.crt
key /etc/openvpn/CLIENT_TO_MIDDLE.key
tls-crypt /etc/openvpn/ta.key
dh none
ecdh-curve X25519
ncp-ciphers AES-256-GCM
cipher AES-256-GCM
auth SHA256
remote-cert-tls server
tls-version-min 1.2
auth-nocache
socks-proxy 127.0.0.1 9050
socks-proxy-retry
verb 0
# sysctl.conf:
net.ipv4.ipforward=1
# iptables_rules:
iptables -A INPUT -p udp --dport 21290 -j ACCEPT
iptables -A FORWARD -i tun_SERVER_IN -o tun_CLIENT_FROM_SERV_IN_TO_SERV_OUT -j ACCEPT
iptables -A FORWARD -i tun_CLIENT_FROM_SERV_IN_TO_SERV_OUT -o tun_SERVER_IN -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.20.10.0/24 -o tun_CLIENT_FROM_SERV_IN_TO_SERV_OUT -j MASQUERADESERVER_MIDDLE - промежуточный узел, с ним при помощи клиента соединяется SERVER_IN, так что тут все предально понятно, за исключением того, что на узле, помимо сервера и клиента openvpn будут располагаться допольнительные средства обфускации.
Публичный ip адрес: 192.168.1.2 - аналогично SERVER_IN, либо публичный адрес, либо адрес в ТОР сети, либо вместо негоиспользуйте ТОР домен.
Внутренний адрес подсети VPN: 10.20.20.0 255.255.255.0
Порт: 22340
Код:
# torrc:
SocksPort 9050
UseBridges 1
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy --managed
Bridge obfs4 x.x.x.x:443 3456856123DDFAEF224216659DAFBCD0124376 cert=MIIDFjKASgkerf... iat-mode=0
HiddenServiceDir /openvpn/SERVER_MIDDLE/hiddenservice
HiddenServiceVersion 3
HiddenServicePort 22340 127.0.0.1:22340
# openvpn_server.conf
port 22340
proto tcp
dev tun_SERVER_MIDDLE
server 10.20.20.0 255.255.255.0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/SERVER_MIDDLE.crt
key /etc/openvpn/SERVER_MIDDLE.key
tls-crypt /etc/openvpn/ta.key
crl-verify /etc/openvpn/crl.pem
verify-client-cert require
user nobody
group nogroup
ifconfig-pool-persist /var/log/openvpn/ipp_SERVER_MIDDLE.txt
duplicate-cn no
client-config-dir /etc/openvpn/ccd-client
ncp-ciphers AES-256-GCM
cipher AES-256-GCM
auth SHA256
dh none
ecdh-curve X25519
client-to-client no
tls-server
remote-cert-tls client
tls-version-min 1.2
reneg-sec 3600
comp-lzo no
auth-nocache
persist-key
persist-tun
keepalive 10 120
verb 0
# openvpn_client.conf
client
dev tun_CLIENT_FROM_SERV_IN_TO_SERV_OUT
proto tcp-client
remote 192.168.1.3 23450
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/CLIENT_TO_OUT.crt
key /etc/openvpn/CLIENT_TO_OUT.key
tls-crypt /etc/openvpn/ta.key
dh none
ecdh-curve X25519
ncp-ciphers AES-256-GCM
cipher AES-256-GCM
auth SHA256
remote-cert-tls server
tls-version-min 1.2
auth-nocache
socks-proxy 127.0.0.1 9050
socks-proxy-retry
verb 0
# sysctl.conf:
net.ipv4.ipforward=1
# iptables_rules:
iptables -A INPUT -p udp --dport 22340 -j ACCEPT
iptables -A FORWARD -i tun_SERVER_IN -o tun_CLIENT_FROM_SERV_IN_TO_SERV_OUT -j ACCEPT
iptables -A FORWARD -i tun_CLIENT_FROM_SERV_IN_TO_SERV_OUT -o tun_SERVER_IN -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.20.20.0/24 -o tun_CLIENT_FROM_SERV_IN_TO_SERV_OUT -j MASQUERADESERVER_OUT - выходной узел, соединение с которым инициируется звеном SERVER_MIDDLE посредством openvpn клиента, как и было описано выше. Этото хост посредний данной трехзвенной архитектуре triple vpn и является выходной точкой в публичную сеть Интернет, ну или куда-то еще-)
Публичный ip адрес: 192.168.1.3 - то же самое, что и в первых двух вариантах
Внутренний адрес подсети VPN: 10.20.30.0 255.255.255.0
Порт: 23450
Код:
# torrc:
SocksPort 9050
HiddenServiceDir /openvpn/SERVER_OUT/hiddenservice
HiddenServiceVersion 3
HiddenServicePort 23450 127.0.0.1:23450
# openvpn_server.conf:
port 23450
proto tcp
dev tun_SERVER_OUT
server 10.20.30.0 255.255.255.0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/SERVER_OUT.crt
key /etc/openvpn/SERVER_OUT.key
tls-crypt /etc/openvpn/ta.key
crl-verify /etc/openvpn/crl.pem
verify-client-cert require
user nobody
group nogroup
ifconfig-pool-persist /var/log/openvpn/ipp_SERVER_OUT.txt
duplicate-cn no
client-config-dir /etc/openvpn/ccd-client
ncp-ciphers AES-256-GCM
cipher AES-256-GCM
auth SHA256
dh none
ecdh-curve X25519
client-to-client no
tls-server
remote-cert-tls client
tls-version-min 1.2
reneg-sec 3600
comp-lzo no
auth-nocache
persist-key
persist-tun
keepalive 10 120
verb 0
# sysctl.conf:
net.ipv4.ipforward=1
# iptables_rules:
iptables -A INPUT -p udp --dport 23450 -j ACCEPT
iptables -A FORWARD -i tun_SERVER_OUT -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun_SERVER_OUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.20.30.0/24 -o eth0 -j MASQUERADEНастраиваем клиента:
Код:
# torrc:
SocksPort 9050
# openvpn_client.conf
client
dev tun_CLIENT_TO_SERV_IN
proto tcp-client
remote 192.168.1.1 21290
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/CLIENT_TO_IN.crt
key /etc/openvpn/CLIENT_TO_IN.key
tls-crypt /etc/openvpn/ta.key
dh none
ecdh-curve X25519
ncp-ciphers AES-256-GCM
cipher AES-256-GCM
auth SHA256
remote-cert-tls server
tls-version-min 1.2
auth-nocache
verb 0
# sysctl.conf:
net.ipv4.ipforward=1В описанной выше трехзвенной конфигурации нетрудно было увидеть, что помимо дополнительного узла добавлися функционал проксификации промежуточных межсерверных соединений, устанавливаемых сервером приложений openvpn. В качестве транспортного сокс-прокси решения был выбран популярный tor:
Некоторые замечения по конфигурации:
torrc:
SocksPort 9050
HiddenServiceDir /openvpn/SERVER_IN/hiddenservice
HiddenServiceVersion 3
HiddenServicePort 21290 127.0.0.1:21290
В данном случае несложно догадаться о том, что все openvpn серверы расположенные на всех серверных узлах цепи VPN представлены как скрытые сервисы, а в качестве дополнительного обфускатора с функцией микширования потоков внутри tor сети применен встроенный obfs4 обфускатор, в виде строк torrc:
UseBridges 1
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy --managed
Bridge obfs4 x.x.x.x:443 3456856123DDFAEF224216659DAFBCD0124376 cert=MIIDFjKA
x.x.x.x - адрес любого моста.
Сами мосты(бриджи) придется выбирать либо самостоятельно, либо выстраивать их где-то отельно и самостоятельно. Это к слову так же вполне возможно, используя внутренние возможности встроенного решения. Например путем активации следующих параметров в файле конфигурации torrc:
RunAsDaemon 1
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy --managed
ServerTransportListenAddr obfs4 0.0.0.0:443
BridgeRelay 1
При этом следует понимать, что встроенный obfs4 как правило запускается сервером ТОР в специальном автоматическом режиме, поэтому чаще всего ТОР самостоятельно запускает obfs4proxy и создаст и сохранит необходимые ключи исходя из заранее подготовленной конфигурации.
И конечно обратим внимание на данный блок настроек в конфигах openvpn клиентов:
socks-proxy 127.0.0.1 9050
socks-proxy-retry
Эти настройки отвечают за проброс соединений через ТОР сеть.
Ну и напоследок напомню о том, что не следует использовать стандартные порты сетевых слубж.
Мы здесть поменяли порты для серверов openvpn, но не трогали другие, такие как tor-socks, но в боевой конфигрурации это все-таки лучше делать.
На этом наверное закончим, так как реализация подобных, но более сложных и тонких схем управления трафиком не предусмотрена настоящим повествованием. Это вступительная статья из единого ряда статей предполагаемых к выпуску по теме туннелирования и управления сетевым трафиком с целью обеспечения безопасности и анонимности и защиты от перехвата. Ну и в дальнейшем мы обязательно посмотрим на некоторые другие решения: в том числе проксификаторы, соксификаторы, переключатели с и без функций обфускации и шифрования управляемых потоков данных. Но рассматривать мы их будем поступательно, и только там, где это применимо и в целом целесообразно с чисто технической точки зрения. В следующей статье, еесли она выйдет, планируется раскрыть возможности другого, не менее популярного решения под названием wireguard vpn. И точно так же мы будем пытаться выстроить многозвенную структуру цепи VPN серверов с использованием дополнительных средств безопасности, по мере необходимости и в силу возможностей, в том числе к усвоению нового материала читателями. Считаю необходимым погружать читателя в подобного рода тематику постепенно и последовательно с целью более эффективной систематизации полученной информации. Чем мы, надеюсь, в дальнейшем продолжим заниматься.
PS: Данная публикация ни в коем случае не является рекламой VPN сервисов и призывом к обходу блокировок и призвана описать общеизвестные и разрешенные законом технологии, предназначенные для обеспечения личной информационной безопасности-)
Спасибо за внимание-)