LIMB
Вероятно, эта тема будет закреплена. Здесь предлагается не только задавать вопросы о существующих способах развертки своих VPN, но и вопросы о обходе блокировок, настройке софта(как клиентов, так и софта со стороны сервера), предлагается делиться способами и методиками, которые знаете лично Вы.
Думаю, актуальность темы ни у кого не вызывает каких-то вопросов. Многие из Вас, уважаемые посетители, прямо сейчас находятся в условиях высокой степени цензуры(Российская Федерация, Китай), от чего использование привычных технологий, про которые уже было снято не одно кино и писаны не едины мануалы, становится крайне проблематичным или вовсе невозможным; либо же, популярные и хорошо одокументированные технологии Вам по какой-то причине не подходят, от чего Вы ищете иные варианты построения своей инфраструктуры.
В теме я предлагаю создать атмосферу открытого обсуждения, плодотворную для взаимовыгодного обмена Вашими знаниями и практиками, а начну я с небольшого введения, раскрывающего актуальность данной темы, и нескольких практик, которые применяются в процессе выполнения достаточно широкого спектра задач.
Актуальность, альтернативы
Ни для кого из посетителей, проживающих в регионах повышенной степени цензуры, не секрет, что привычный Wireguard завести может быть крайне непростой задачей. Даже относительно стойкий и ранее часто применимый вариант развертки, при котором объединялись OpenVPN-TCP через классические, свойственные веб-инфраструктуре, порты и технология Cloak, согласно отзывам многих пользователей, полностью перестал выполнять свои функции/делает это спустя некоторое время.
Сдались в большинстве регионов Российской Федерации и популярные коммерческие решения, ранее имевшие достаточно хороший уровень эффективности против систем цензурирования интернет-трафика(Windscribe с его stealth-режимом и возможностью конфигурирования OpenVPN-подключений, Mullvad с его обфускацией через ShadowSocks, ранее по-настоящему популярный сервис PIA VPN). Не легче и альтернативным путям: большинство провайдеров SOCKS5-прокси(особенно это касается датацентровых пулов адресов) эффективно блокируются, либо же работают с ощутимыми перебоями; Tor же в принципе достаточно давно работает не очень корректно в условиях домовых ISP, на данный момент в связи с развитием инфраструктуры(включая средства ТСПУ) теряют эффективность и ранее работавшие методы обхода его блокировки через мосты Snowflake.
И отсюда вытекает первая причина актуальности: искать нужные методы стоит просто потому, что это залог не только доступа к технологиям анонимизации, но и доступа к информации без цензуры, что нужно большинству людей в принципе.
Но если рассуждать о второй причине актуальности этой темы, то все становится чуть более мрачным. Совсем недавно сервис "First VPN", предоставляющий услуги анонимизации, как многие уже видели из громких заголовков, накрыли. Новости, как всегда, нацелены на псиоп и устрашение, что можно проследить по громким строкам о "огромном объеме логов", как например заявляется в этом популярном издании.
Но все таки, несмотря на привычные преувеличения со стороны компетентных органов в их громких заявлениях, подобные ситуации действительно несут огромную угрозу для Вашей анонимности. Сам же сервис "в тейкдауне" имел достаточно продолжительную историю развития, и в целом соответствует типичному портрету "анонимного" сервиса, коими напичканы многие маркеты и площадки.
И здесь следует сформулировать следующий вопрос: чему же в сухом итоге доверить свой инкогнито?
По опыту многих людей, на протяжении достаточно длительного срока нуждавшихся в подобных услугах, и опыту с завидной регулярностью весьма плачевному, можно дать немного конкретики будущему ответу: явно не сервисам, кричащим о невероятнейшей анонимности. Часто под фантиком такого сервиса скрывается либо хонепот, либо орда сисадминов в ноль лет, попросту не способных настроить инфраструктуру своего сервиса адекватно, в сухом итоге остается лишь одно: слова о приватности остаются красивым, грязным маркетингом. На примере многих "сейзнутых" сервисов можно и сделать вывод о том, что нередко пытаясь выйти на трек экзитскама или даже(в особенно наивных головах действительно возникают такие идеи) продолжить свою работу в прежнем режиме "до дефейса от FBI", владельцы подобных пострадавших сервисов будут стараться вас заверить в том, что все данные в безопасности и сервис будет восстановлен.
И, как следует из крылатого выражения, принимающего разные формы, "опсек - дело рук пользователя, а не площадки", свою безопасность стоит сделать зоной именно своей ответственности. Вдобавок, это не так и сложно: с настройкой многих вариантов разберется и глубоко начинающий.
Имеющиеся варианты, особенности и архитектура
Актуальность мы четко обозначили. Далее можно обозначить типовые варианты связок под работу, которые будут достаточно надежными для нее, их критерии и их особенности. Но начать стоит с простого: с чем бороться, и, самое главное, как?
Как многим уже известно, на данный момент в РФ повсеместно введены белые списки на мобильный интернет, не исключен и вариант развития событий, при котором белые списки затронут и домашние, "проводные" ISP: тот же Ростелеком на своих проводах нередко более привиредлив к "обходнякам", чем его коллеги. Не работают адекватно уже и на проводном интернете многие популярные VPN-сервисы, чьи пулы давно занесены в "черные списки". Но здесь стоит провести важное разграничение, которое поможет выбрать оптимальные способы построения своей инфраструктуры корректно:
Исходя из этих деталей, не углубляясь в подробности, можно сделать следующий вывод: если у Вашего VPN есть задача "выживать" при включении белых списков, стоит куда дотошнее производить его настройку, чтобы с предельной достоверностью мимикрировать под обычный веб-серфинг.
На домашних "проводных" ISP сложность конфигурации же будет куда более низкой.
Подобная степень напичканности современных провайдеров всевозможным неприятным для людей оборудованием выявляет и следующую важную черту действительно безопасной связки: все не должно упираться в один сервер/VPS. Данные сохраняются(что было и до этого, ведь все причастные помнят пакет Яровой), на основе данных происходит анализ существующих методов, доработка систем блокировки, данные всегда лежат "где-то там, куда не дотянутся руки", от чего возникает необходимость не выдавать тот адрес, к которому вы же и подключаетесь, во время работы - действительно безопасная инфраструктура начинается с многослойности. И двойной роутинг при условии разных провайдеров и разных учетных данных уже может называться безопасным, хотя многие применяют и тройные цепочки. Именно в связи с этим в рамках "связок для работы" не будет рассмотрено приложение от amnezia.org, в автоматическом режиме производящее установку нужного протокола после ввода данных VPS: этот вариант строится вокруг доверия к одной ноде, в многослойном формате развертка подобной инфраструктуры куда проще без приложения(хоть AmneziaWG, форк Wireguard от разработчиков амнезии, и до сих пор является жизнеспособным, не говоря уже за опционал развертки своих XRay+Reality коннектов и т.д. - в полностью автоматическом режиме).
Перейдем к практической реализации.
Мануал 1: селфхост на своих серверах
Первый вариант инфраструктуры полностью основывается на покупных серверах.
При выборе провайдера следует полагаться на существующую у хостингов репутацию. Изначально "темные" варианты брать не стоит(по примеру с ферст впн, который отвалился, забрав с собой часть данных своих пользователей), однако, никогда не стоит брезговать покупкой железа у хостингов с юрисдикцией в СНГ. Такие мало чувствительны к приходящим к ним письмам.
Также, вариант с 4vps.su тоже следует отмести в связи с недавним финтом ушами с их стороны(о чем отдельно и честно высказались TheGentlemen, пострадавшие от инцидента, советую ознакомиться). Варианты с санкционочкой по типу Aeza, замеченной в помощи наркоплощадкам(за что наказание изначально куда более суровое, и хлестают таких провайдеров все службы вне зависимости от гео) тоже следует отметать еще при первом просмотре.
В сценарии, при котором наша нужда - обход белых списков, нам понадобится тот самый упомянутый ранее белый IP. Краткий мануал и способы его добычи чуть позже будут добавлены в этот тред вместе с другими методами по мере поступления(скорее всего, вместе с автоматическим софтом).
В нашем случае будет продемонстрирован простой и скрытный сценарий без белого адреса на 2 серверах от разных провайдеров, но все еще работающий практически при любых условиях, при котором мы будем использовать SNI, ассоциированный с x5.ru(официальный сайт пятерочки) - с его сабдоменом, отвечающим за подгрузку медиа. Крупные объемы трафика на него не выглядят подозрительными, вдобавок, моя первая нода как раз находится "недалеко" от адресов, имеющих *.x5.ru-домены. Выяснить, кто сидит неподалеку от нашего входного адреса, можно с помощью утилиты Reality TLS Scanner, ассоциированной с разрабами ядра xray. С ней ознакомимся несколько позже.
Для этого дельца лучше всего подойдут Debian последней версии.
Заходим на оба VPS, и прежде всего обновляем пакеты, имеющиеся на системах:
sudo apt update; sudo apt upgrade -y
После чего докачиваем нужные утилиты, которых часто может и не быть на "голых" дебианах:
sudo apt install wget curl git ufw fail2ban
Дожидаемся завершения установки, после чего приступаем к установке нужного софта. Использоваться в данном примере будет панель 3X-UI, недавно прошедшая через достаточно масштабное обновление. Ее более чем достаточно для селфхост-решения.
Устанавливаем напрямую по репозиторию:
git clone https://github.com/MHSanaei/3x-ui
Ждем завершения установки, после чего переходим в появившуюся директорию:
cd 3x-ui
Внутри ищем файл x-ui.sh, который и будет использован для автоматической развертки панели. Через ls смотрим, является ли он исполняемым, если не является(не подсвечен) - прогоняем его через chmod +x.
При его запуске откроется следующее меню:
Нам потребуется опция под номером 1 - установка. Ее мы и выбираем. Установка запустится, автоматически скачивая все необходимое, от нас требуется лишь ожидание. Далее установщик попросит выбрать базу для хранения, порт для панели, настройки SSL. Выбираем sqlite как более стабильный вариант из коробки, даем панели сгенерировать порт наобум, генерацию SSL-серта пропускаем:
Что же дальше? Панель спросит, хотим ли мы закрыть панель сразу же под 127.0.0.1(внешний доступ к веб-админке будет невозможен), и выдаст креды для подключения.
На скриншоте я выбрал опционал закрытия панели сразу же под 127.0.0.1 отключить, так как сам по себе 3X-UI генерирует довольно неплохие юзернеймы и пароли, и за 10 минут их точно не сбрутят, но вы можете уже на этом этапе включить доступ только через локалхост. Тогда, чтобы продолжить конфигурацию, нужно будет провести туннель через SSH примерно таким образом:
ssh root@ip_addr -L panel_port:localhost:panel_port
После авторизации заходите в браузере на ссылку, выданную установщиком, только IP меняете на 127.0.0.1, и авторизуетесь - все точно так же. Подобный функционал как раз добавлен с обновлением; раньше от SSL отказаться было нельзя, что порой ломало развертку.
Панель будет выглядеть следующим образом:
Все интуитивно понятно, и умником быть не нужно.
Для начала, следует проследовать в раздел "inbounds" - это раздел, отвечающий за инбаунды - входящие подключения. Тут и формируются коннекты для пользователей.
Выбираем опцию "создать подключение", и именно здесь начинается конфигурация.
Выбираем следующий опционал:
- Аутентификацию выбираем X25519 - она переваривается большинством клиентов без ошибок, в отличие от более современного аналога.
- Настройки соединения желательно оставить на TCP(Raw) - это наиболее оптимальный выбор, который уже хорошо обкатан в связке с Reality. При правильной конфигурации живет вечно.
Далее самая "ответственная" часть. Настройки реалити. Выбираем в разделе security именно его.
И как следует из простой логики, дефолтные встроенные значения по типу доменов инвидии, амазона, оракла нам здесь не подойдут(недавно пытались вдарить даже по гитхабу).
Первая же активная аппробация этого соединения выдаст его сущность, после чего адрес будет "внесен в черный список" как потенциальный VPN-сервер, если это белые адреса от популярных компаний по типу Yandex/VK Cloud/Sentinel, то это грозит и блокировкой услуги.
В зависимости от того, где находится первая нода, можно выдать SNI/Target следующим образом:
- Если Вы купили белый адрес из пула VK Cloud, можете смело ставить в значение SNI медиа-домены vk.ru или домен max.ru. Оба домена являются членами "белого списка", реальные адреса, закрепленные за их поддоменами и CDN, действительно относимы к пулам именно этого хостинга. Это не будет выглядеть аномально со стороны.
Можете проверить это собственными руками: смотрим на домен max.ru, определяем CIDR, к которому принадлежит адрес, бьем его через хуррикан(по моему мнению, один из наиболее удобных инструментов для подобных исследований).
- Если белый адрес принадлежит пулу Yandex, мы по прежней аналогии берем домен из их зоопарка(экосистемы) сервисов.
Отсюда, вывод напрашивается довольно простой: нужно мимикрировать под предельно естественное веб-соединение к этим сервисам, которые принадлежат белым спискам, дабы не палить контору. Никаких различий между доменом и пулом адресов, никаких странных портов и странных типов соединения(какой gRPC на ya.ru?). Мы должны выглядеть нативно.
В моем случае, как и упоминалось, один из ближайших соседей - это *.x5.ru. Я взял запись ads, так как она связана с подгрузкой значительного количества медиа и связана с крупными объемами трафика.
Однако, как эффективно узнать, кто соседи, если это не прежние два варианта или если хочется соригинальничать?
На то и нужен упомянутый ранее софт. Установка проста: переходим во вкладку релизов, качаем по прямой ссылке через wget.
wget https://github.com/XTLS/RealiTLScanner/releases/download/v0.2.3/RealiTLScanner-linux-amd64
Для удобства переименуем в tlscanner, перекинем в /usr/local/bin для доступа в любом месте и придадим права исполняться:
mv RealiTLScanner-linux-amd64 tlscanner
sudo mv tlscanner /usr/local/bin
chmod +x /usr/local/bin/tlscanner
Утилита несложная: просто берем свой адрес, скармливаем ей, на выходе получаем своих "соседей". Однако, стоит упомянуть, что у нее есть опционал установки числа потоков, который желательно не трогать: в слишком агрессивном режиме сканирования "своих же" хостинг может выдать желтую карточку.
tlscanner -addr <VPS_IP>
В ответ получим соседушек, под которых можем мимикрировать. Однако, большинство из них вряд ли будут подходить для обхода БС, и работать подобный конфиг будет преимущественно на проводке. Тем не менее, если сканирование пущено с "белых пулов", можно найти и тех, кто в списках присутствует:
Подробнее конкретно об обходах БС с сравнениями по провайдерам будет далее; я возьму сабдомен пятерочки, который ранее нашел.
Помимо выставления SNI/Target в конфиг надо сгенерировать пару ключей(приват/паблик), остальное трогать нежелательно. Сниффинг мы тоже не включаем: чаще он ломает конструкцию, чем улучшает ее.
Сохраняем инбаунд. Я создал два инбаунда, один из которых соединяется "через один сервер", а другой - "даблхоп". На яндексе так делать не рекомендую: зайдете в какое-то русское приложение, и оно о вас настучит.
Подобным образом устанавливаем и разворачиваем панель на втором VPS/N-ном VPS, зависит от того, какую цепочку вы выберете. На последующих серверах(уже не в РФ-гео) нет смысла так запариваться, и можно выбрать любой рабочий SNI, предлагаемый самой панелью. Допустим, oracle.com. Если ваш первый сервер в цепочке - "обходной", и принадлежит той самой троице провайдеров, соединять его со вторым я рекомендую только через VLESS: все из названных провайдеров любят детектить у себя впн-серверы, дабы заставить клиента еще раз заплатить за новый адресок, а вайргуард/шедоусокс и так далее сложно не заметить.
Получаем инбаунд на второй панели.
После обновления нельзя сразу забрать подписки в том же меню: нужно создать клиентов. Этим и займемся на обоих VPS, перейдя в поле "Clients". Второй VPS:
Жмем "Add clients", ничего можем не менять, кроме "закрепленных соединений" - "Attached Inbounds".
Далее забираем подписку в формате той самой, узнаваемой "влесс-ссылки" через клавишу-QR код, указанную рядом с клиентом. Первый QR-код и первую ссылку не трогаем, это ссылка подписки, берем вторую ссылку.
Забираем ее на первый VPS, и теперь создаем аутбаунд - исходящее подключение. Делаем это через "Xray Config" в боковой панели, зайдя в "Outbounds". Создаем аутбаунд через клавишу с плюсом и переходим в раздел JSON - там есть автоматический импорт конфига по одной лишь ссылке:
Почти что финишная прямая. После добавления сверху прожимаем "Save" и переходим в графу "Routing Rules". Там надо создать правило, согласно которому трафик с первого соединения будет перенаправляться на второе на второй VPS. Сделать это не так сложно. Создаем новое правило, и делаем следующим образом:
Отдельно замечу, что советы на ютюбе про "исключения" на "русские приложения", при которых трафик идет сразу с первого VPS, вредоносны, если вы используете айпи из пула яндекса/сентинела/вк клауда. Сейчас приложения активно собирают статистику и стучат, этот адрес будет с высокой вероятностью заблочен и помечен как VPN. Если цель стоит только в обходе ограничений/БС, следует просто взять второй VPS все так же в России, но уже в любом провайдере за крипту, как вам угодно. У меня цепочка под проводной интернет, и оба сервера не принадлежат БС, куплены за крипту.
Перетаскиваем новое правило роутинга повыше, сначала жмем "сейв", потом "рестарт".
Финальным штрихом так же создаем клиента на первом VPS, забираем его себе. Стоит сразу сказать, что если изначально вы выбрали установку через привязку к локалхосту(один из вопросов установщика), то следует в каждом созданном инбаунде напрямую указывать адрес вашего VPS. До сих пор панели 3X-UI свойственен баг, при котором все втупую ломается, и панель под локалхостом вставляет в Listen IP 127.0.0.1.
Если вы такую опцию не выбирали, то после создания всех нужных клиентов и инбаундов следует в каждой панели перейти в "Panel Settings" и проставить в Listen IP 127.0.0.1, чтобы закрыть панель от внешнего интернета, после чего снова сделать "Save" и "Restart Panel". Если вы не туннелировали порт панели, она сразу пропадет из вашего доступа в браузере, и это нормально.
Забираем подписку в клиент, который у нас уже есть, о чем речь пойдет несколько позже. Допустим, это V2RayN. Получаем следующее:
У меня создано 2 сабки, и обе работоспособны.
Как итог, у нас появляется свой VPN, пропущенный в идеале через несколько юрисдикций, что крайне замедлит потенциальный сбор информации о Вас. Вдобавок, подобная реализация позволяет и обходить существующие ограничения, касающиеся мобильного интернета, при определенных условиях.
Среди основных:
Конструкция может быть с легкостью расширена в условиях обхода БС до 3 серверов, что даст достаточную анонимность(белый адрес - VPS 1 - VPS 2), и в целом разворачивается относительно просто. Однако, среди ее потенциальных минусов все еще остается факт того, что вы и еще, возможно, пара человек(хотя это и крайне редко) - ее единственные пользователи. Трафик не замиксован, а любой детектор по типу 2ip.ru сразу же говорит, кто ваш провайдер. Будучи лишь клиентом-физическим лицом, вы остаетесь в рамках клиента этого хостинга.
Но что, если исправить это?
Мануал 2: свой "мост" для популярного VPN-провайдера
А что, если использовать, как и раньше, какой-то из крупнейших VPN-сервисов, имеющий оборот в сотни тысяч клиентов и больше? В потенциале это помогает еще больше запутать следы за счет дележки одной ноды с кучей пользователей, что возможно в случаях, когда VPN действительно мало знает о вас(и тут следует упомянуть всякие уже ставшие классическими PIA, Mullvad и прочие часто используемые провайдеры) или в случаях, когда VPN вообще связи с вами не имеет и был перекуплен/добыт из логов.
Однако, большинство подобных провайдеров на данный момент времени эффективно блокируются, и их использование может вылиться в отдельное приключение. И в каком-то смысле это даже играет нам на руку.
Многие уже слышали о проекте, названном gluetun. На данный момент у него есть как свой развитый репозиторий с частыми обновлениями, так и свой образ на докерхабе.
Сами разработчики позиционируют его "швейцарским ножом" по работе с коммерческими VPN, и это в целом-то не так и далеко от истины. Можно сказать, что это универсальный клиент, поддерживающий OpenVPN/WireGuard/DNS-over-TLS соединения и кучу прочих нужных вещей, созданный для работы практически со всеми широко известными впн-сервисами. Так почему бы не использовать его в своей инфраструктуре?
Идея проста. В начале мы ставим VPS, на котором развернут VPN, способный обходить нынешние ограничения - можно сказать, что это селфхост-часть. А далее мы перенаправляем трафик, выходящий из селфхоста, в популярный VPN-сервис, который нами желаем. Для этого с докерхаба возьмем два образа: один - с любым удобным и чистым форком 3X-UI(оригинал пока что нередко багуется в сложных сетапах после обновы), другой - с gluetun самим по себе. И объединим их в единую сеть, в которой доступ 3X-UI возможен только через впн-коннект и публично доступный порт для входящего соединения. Выглядит пример конфигурации следующим образом:
Структура строится на трех сервисах. Как можно заметить, два из них в основе своей являются образами от одного автора, что и не мудрено: deunhealth - отдельная утилита, поддерживающая совместную работу с gluetun и способная обеспечить его стабильную работу(например, производить переподключения и мониторить общее состояние сервиса). Многие юзают их совместно:
Подобная реализация уже была озвучена многими, и далеко не раз. Однако, наша будет минимально функциональной, без излишеств.
Мы отдельно закрепляем доступ xui в интернет только через gluetun; порт 54321 в данном случае дефолтно отвечает за админ-панель и вынесен лишь на localhost. Он будет доступен через SSH-туннель на 127.0.0.1:54321:
ssh root@<VPS_IP> -L 54321:localhost:54321
В данном случае(в память бастерлорду :D) выбран PIA VPN, до сих пор используемый многими без особых проблем. Формат выставлен в OpenVPN. Однако, это далеко не единственный поддерживаемый функционал - поддерживается большое количество VPN, какому верите больше - решение стоит за вами.
Добавляем docker-compose.yml на свой VPS, устанавливаем туда Docker и Docker Compose - установка зависит от дистрибутива и прямо закреплена на официальных ресурсах докера.
mkdir VPNBridge/
mv docker-compose.yml VPNBridge/
Переходим в директорию, и запускаем оркестр:
docker compose up -d
Первый запуск может быть долгим. Ожидаемый результат следующий:
После этого переходим в docker compose logs -f и ждем, когда все сервисы поднимутся и начнут полноценную работу.
Основные строки, которых следует ожидать, следующие:
deunhealth | <time> INFO No container found to restart when becoming unhealthy
deunhealth | <time> INFO Monitoring new container double-gluetun-1 to restart when becoming unhealthy
Это свидетельствует об успешном старте сервиса-мониторщика.
gluetun-1 | <time> INFO [ip getter] Public IP address is <ip> (Sweden, Stockholm, Stockholm - source: ipinfo+ifconfig.co+ip2location+cloudflare)
Это свидетельствует об успешном подключении к VPN со стороны gluetun.
xui-1 | INFO - Web server running HTTP on [::]:54321
Это свидетельствует об успешном старте форка 3X-UI и его панельки. Переходим и конфигурируем по схожей схеме. Управление отличается лишь в одной черте: нам не нужно создавать отдельного клиента, доступ к подписке находится сразу в инбаундах.
Вдобавок, в данном случае ничего настраивать со стороны панели НЕ нужно: она и так не пойдет дальше, чем локалхост самого VPS, так заложено в докер конфиге.
Процесс создания инбаунда же схож с предыдущим мануалом, разве что менюшка в данном случае отличается. Поле под IP мы оставляем обязательно пустым, и подписку нам выдаст в формате ссылки со 127.0.0.1: так происходит потому, что 3X-UI в связи с сетевой конфигурацией сам не понимает, где находится. В подписке нужно вручную поменять 127.0.0.1 на IP от VPS.
Как итог, получаем структуру, где на входе встречает самоделка, а на выходе - популярный коммерческий продукт, который перемешивает нас с остальными пользователями, спокойно смотрящими нетфликс.
И здесь, несмотря на относительное соблюдение принципа нулевого доверия к коммерческому продукту, тоже есть фундаментальный вопрос, кроющийся в вашем доверии к тому или иному сервису. Тем не менее, это куда анонимнее, чем использовать его напрямик.
В скором времени приложу к теме два софта, один из которых позволит производить ротацию такого "моста" удаленно, а второй будет нацелен на облегченную развертку многослойного VLESS.
А что с клиентами?
Относительно длительный промежуток времени VLESS-впны претерпевали единую проблему, особенно неприятную в ситуациях, когда нужна анонимность, и проблема довольно простая: большинство клиентов некорректно работали с TUN-режимом(как раз таки режимом виртуального сетевого интерфейса, в который все перенаправляется) и к тому же не имели киллсвитча.
Однако, на данный момент уже было выпущено приложение, поддерживающее данный функционал и постепенно замещающее устаревшие Nekobox/Happ и прочие клиенты - INCY.
Решение хоть и довольно молодое, но кроссплатформенное:
Функционал kill-switch доступен и на Windows, и на Linux, что является отличным решением для тех, чья хостовая машина - винда, и для тех, кому лень копаться с ufw и своим киллсвитчем.
Для православных пользователей линукса на хостовой машине я бы порекомендовал как более надежную во многих планах альтернативу использовать ufw и V2RayN, который прекрасно с ним работает.
После установки V2RayN(имеющего такую же кроссплатформенность) и добавления профиля сначала устанавливаем ufw:
sudo apt install ufw ##для Debian, полагаю, дистрибутивы на его базе у большинства пользователей десктопного линукса
sudo ufw enable ##включаем файерволл
sudo ufw allow in on lo
sudo ufw allow out on lo ##разрешаем обмен данными с локалхостом, чтобы система не сдурела
sudo ufw default deny incoming
sudo ufw default deny outgoing ##явно запрещаем всему трафику входить и выходить
Далее узнаем, как называется интерфейс от V2RayN, через ifconfig. Обычно это singbox_tun:
sudo ufw allow out on singbox_tun
sudo ufw allow in on singbox_tun ##разрешаем трафик через конкретно этот интерфейс
Однако, для того, чтобы туннель был инициализирован, нам нужно в начале подключиться к серверу(VPS). Для этого следует создать отдельное исключение:
sudo ufw allow out to <IP_входящего_VPS>
По факту, на этом этапе киллсвитч уже будет работать, и хватит лишь одного sudo ufw reload, чтобы он запустился.
Однако, многие работают с виртуалками, имеющими свой локальный диапазон, и это важно учесть: если не разрешить явно работу с этим диапазоном, то по логике "запрещено все, что не разрешено", которую мы воссоздали, интернета в виртуалках не будет. Их конфигурации так же узнаются через ifconfig: будет видно отдельные виртуальные интерфейсы, связанные с ними. В случае KVM, например, это обычно диапазон 10.0.2.0/24:
Разрешим его.
sudo ufw allow to 10.0.2.0/24
sudo ufw allow from 10.0.2.0/24
В таком случае после sudo ufw reload получим готовый к работе киллсвитч под V2RayN, который будет работать, что можно проверить отдельно на тестах с определителями айпи.
В чем итог? За короткий промежуток времени можно получить достаточно интересные самостоятельные реализации своего собственного VPN с интеграцией популярного сервиса или без него, которые при правильном применении определенно способны защитить их пользователя. Хватит базовых навыков администрирования, чтобы управиться с такой инфраструктурой.
Варианты, продемонстрированные здесь, могут применяться как для обхода ограничений в средне-тяжелых условиях, так и для анонимизации, и это является их общей чертой несмотря на изначально разное предназначение и разную учтенную модель угроз.
Актуальная методология поиска белых IP для создания обхода на белые списки будет чуть позже приложена отдельной инструкцией под этим топиком, сюда же будут поститься другие варианты развертки своего VPN/обхода ограничений, на разные цели и задачи. Уважаемым участникам нашего сообщества могу сказать, что эта ветка открыта для обсуждения, и каждый может делиться чем-то своим, благо, инструментов уже очень много, и с каждым днем они становятся все более продуманными и развитыми.
Я же буду продолжать пополнять эту ветку интересными информацией, решениями и вариантами, которые удалось найти и проверить уже мне(в нынешних условиях мне приходится просить помощи у другого человека, чтобы он тестировал решения, нацеленные на борьбу с такими острыми проявлениями цензуры, как белые списки).
Будьте внимательнее при выборе сервисов, от которых зависит ваша анонимность. Никогда не ленитесь потратить пару часов своего времени, чтобы разузнать репутацию продукта. Ну а в случае чего - всегда есть решения, которые позволяют развернуть вашу собственную крепость ;)
Думаю, актуальность темы ни у кого не вызывает каких-то вопросов. Многие из Вас, уважаемые посетители, прямо сейчас находятся в условиях высокой степени цензуры(Российская Федерация, Китай), от чего использование привычных технологий, про которые уже было снято не одно кино и писаны не едины мануалы, становится крайне проблематичным или вовсе невозможным; либо же, популярные и хорошо одокументированные технологии Вам по какой-то причине не подходят, от чего Вы ищете иные варианты построения своей инфраструктуры.
В теме я предлагаю создать атмосферу открытого обсуждения, плодотворную для взаимовыгодного обмена Вашими знаниями и практиками, а начну я с небольшого введения, раскрывающего актуальность данной темы, и нескольких практик, которые применяются в процессе выполнения достаточно широкого спектра задач.
Актуальность, альтернативы
Ни для кого из посетителей, проживающих в регионах повышенной степени цензуры, не секрет, что привычный Wireguard завести может быть крайне непростой задачей. Даже относительно стойкий и ранее часто применимый вариант развертки, при котором объединялись OpenVPN-TCP через классические, свойственные веб-инфраструктуре, порты и технология Cloak, согласно отзывам многих пользователей, полностью перестал выполнять свои функции/делает это спустя некоторое время.
Сдались в большинстве регионов Российской Федерации и популярные коммерческие решения, ранее имевшие достаточно хороший уровень эффективности против систем цензурирования интернет-трафика(Windscribe с его stealth-режимом и возможностью конфигурирования OpenVPN-подключений, Mullvad с его обфускацией через ShadowSocks, ранее по-настоящему популярный сервис PIA VPN). Не легче и альтернативным путям: большинство провайдеров SOCKS5-прокси(особенно это касается датацентровых пулов адресов) эффективно блокируются, либо же работают с ощутимыми перебоями; Tor же в принципе достаточно давно работает не очень корректно в условиях домовых ISP, на данный момент в связи с развитием инфраструктуры(включая средства ТСПУ) теряют эффективность и ранее работавшие методы обхода его блокировки через мосты Snowflake.
И отсюда вытекает первая причина актуальности: искать нужные методы стоит просто потому, что это залог не только доступа к технологиям анонимизации, но и доступа к информации без цензуры, что нужно большинству людей в принципе.
Но если рассуждать о второй причине актуальности этой темы, то все становится чуть более мрачным. Совсем недавно сервис "First VPN", предоставляющий услуги анонимизации, как многие уже видели из громких заголовков, накрыли. Новости, как всегда, нацелены на псиоп и устрашение, что можно проследить по громким строкам о "огромном объеме логов", как например заявляется в этом популярном издании.
Не удалось прогрузить медиа
Но все таки, несмотря на привычные преувеличения со стороны компетентных органов в их громких заявлениях, подобные ситуации действительно несут огромную угрозу для Вашей анонимности. Сам же сервис "в тейкдауне" имел достаточно продолжительную историю развития, и в целом соответствует типичному портрету "анонимного" сервиса, коими напичканы многие маркеты и площадки.
И здесь следует сформулировать следующий вопрос: чему же в сухом итоге доверить свой инкогнито?
По опыту многих людей, на протяжении достаточно длительного срока нуждавшихся в подобных услугах, и опыту с завидной регулярностью весьма плачевному, можно дать немного конкретики будущему ответу: явно не сервисам, кричащим о невероятнейшей анонимности. Часто под фантиком такого сервиса скрывается либо хонепот, либо орда сисадминов в ноль лет, попросту не способных настроить инфраструктуру своего сервиса адекватно, в сухом итоге остается лишь одно: слова о приватности остаются красивым, грязным маркетингом. На примере многих "сейзнутых" сервисов можно и сделать вывод о том, что нередко пытаясь выйти на трек экзитскама или даже(в особенно наивных головах действительно возникают такие идеи) продолжить свою работу в прежнем режиме "до дефейса от FBI", владельцы подобных пострадавших сервисов будут стараться вас заверить в том, что все данные в безопасности и сервис будет восстановлен.
И, как следует из крылатого выражения, принимающего разные формы, "опсек - дело рук пользователя, а не площадки", свою безопасность стоит сделать зоной именно своей ответственности. Вдобавок, это не так и сложно: с настройкой многих вариантов разберется и глубоко начинающий.
Имеющиеся варианты, особенности и архитектура
Актуальность мы четко обозначили. Далее можно обозначить типовые варианты связок под работу, которые будут достаточно надежными для нее, их критерии и их особенности. Но начать стоит с простого: с чем бороться, и, самое главное, как?
Как многим уже известно, на данный момент в РФ повсеместно введены белые списки на мобильный интернет, не исключен и вариант развития событий, при котором белые списки затронут и домашние, "проводные" ISP: тот же Ростелеком на своих проводах нередко более привиредлив к "обходнякам", чем его коллеги. Не работают адекватно уже и на проводном интернете многие популярные VPN-сервисы, чьи пулы давно занесены в "черные списки". Но здесь стоит провести важное разграничение, которое поможет выбрать оптимальные способы построения своей инфраструктуры корректно:
- На мобильном интернете(за исключением случаев с иностранными eSIM, работающими эффективно, но не всегда стабильно) работает прежде всего схема "запрещено все, что не разрешено в отдельном порядке" - на этом принципе и строятся т.н. "белые списки", портящие жизнь не только тем из нас, кто предпочитает левый SIM в качестве источника интернета, но и обычным гражданам. Добыть "белые" адреса, которые состоят в списке "разрешено", можно на данный момент у ограниченного количества провайдеров(Yandex, VK Cloud, Sentinel), часто это адреса, на которых ранее располагались сервисы, оставлявшие заявку на включение в списки в официальном порядке. На данный момент их, к сожалению, не так много, и живут они далеко не во всех диапазонах названных провайдеров.
- На мобильном интернете вопрос про поведенческие признаки обстоит гораздо острее: куда больше шанс, что Ваш VLESS, который через Reality уводит на SNI: "max.ru", но при этом почему-то сидит на диапазоне Яндекса, споткнется. То же касается и "неправильного" внешнего вида трафика: на HTTPS-подобный трафик, идущий на какие-то дремучие порты в огромных объемах, мало кто клюнет.
Исходя из этих деталей, не углубляясь в подробности, можно сделать следующий вывод: если у Вашего VPN есть задача "выживать" при включении белых списков, стоит куда дотошнее производить его настройку, чтобы с предельной достоверностью мимикрировать под обычный веб-серфинг.
На домашних "проводных" ISP сложность конфигурации же будет куда более низкой.
Подобная степень напичканности современных провайдеров всевозможным неприятным для людей оборудованием выявляет и следующую важную черту действительно безопасной связки: все не должно упираться в один сервер/VPS. Данные сохраняются(что было и до этого, ведь все причастные помнят пакет Яровой), на основе данных происходит анализ существующих методов, доработка систем блокировки, данные всегда лежат "где-то там, куда не дотянутся руки", от чего возникает необходимость не выдавать тот адрес, к которому вы же и подключаетесь, во время работы - действительно безопасная инфраструктура начинается с многослойности. И двойной роутинг при условии разных провайдеров и разных учетных данных уже может называться безопасным, хотя многие применяют и тройные цепочки. Именно в связи с этим в рамках "связок для работы" не будет рассмотрено приложение от amnezia.org, в автоматическом режиме производящее установку нужного протокола после ввода данных VPS: этот вариант строится вокруг доверия к одной ноде, в многослойном формате развертка подобной инфраструктуры куда проще без приложения(хоть AmneziaWG, форк Wireguard от разработчиков амнезии, и до сих пор является жизнеспособным, не говоря уже за опционал развертки своих XRay+Reality коннектов и т.д. - в полностью автоматическом режиме).
Перейдем к практической реализации.
Мануал 1: селфхост на своих серверах
Первый вариант инфраструктуры полностью основывается на покупных серверах.
При выборе провайдера следует полагаться на существующую у хостингов репутацию. Изначально "темные" варианты брать не стоит(по примеру с ферст впн, который отвалился, забрав с собой часть данных своих пользователей), однако, никогда не стоит брезговать покупкой железа у хостингов с юрисдикцией в СНГ. Такие мало чувствительны к приходящим к ним письмам.
Также, вариант с 4vps.su тоже следует отмести в связи с недавним финтом ушами с их стороны(о чем отдельно и честно высказались TheGentlemen, пострадавшие от инцидента, советую ознакомиться). Варианты с санкционочкой по типу Aeza, замеченной в помощи наркоплощадкам(за что наказание изначально куда более суровое, и хлестают таких провайдеров все службы вне зависимости от гео) тоже следует отметать еще при первом просмотре.
В сценарии, при котором наша нужда - обход белых списков, нам понадобится тот самый упомянутый ранее белый IP. Краткий мануал и способы его добычи чуть позже будут добавлены в этот тред вместе с другими методами по мере поступления(скорее всего, вместе с автоматическим софтом).
В нашем случае будет продемонстрирован простой и скрытный сценарий без белого адреса на 2 серверах от разных провайдеров, но все еще работающий практически при любых условиях, при котором мы будем использовать SNI, ассоциированный с x5.ru(официальный сайт пятерочки) - с его сабдоменом, отвечающим за подгрузку медиа. Крупные объемы трафика на него не выглядят подозрительными, вдобавок, моя первая нода как раз находится "недалеко" от адресов, имеющих *.x5.ru-домены. Выяснить, кто сидит неподалеку от нашего входного адреса, можно с помощью утилиты Reality TLS Scanner, ассоциированной с разрабами ядра xray. С ней ознакомимся несколько позже.
Для этого дельца лучше всего подойдут Debian последней версии.
Заходим на оба VPS, и прежде всего обновляем пакеты, имеющиеся на системах:
sudo apt update; sudo apt upgrade -y
После чего докачиваем нужные утилиты, которых часто может и не быть на "голых" дебианах:
sudo apt install wget curl git ufw fail2ban
Дожидаемся завершения установки, после чего приступаем к установке нужного софта. Использоваться в данном примере будет панель 3X-UI, недавно прошедшая через достаточно масштабное обновление. Ее более чем достаточно для селфхост-решения.
Устанавливаем напрямую по репозиторию:
git clone https://github.com/MHSanaei/3x-ui
Ждем завершения установки, после чего переходим в появившуюся директорию:
cd 3x-ui
Внутри ищем файл x-ui.sh, который и будет использован для автоматической развертки панели. Через ls смотрим, является ли он исполняемым, если не является(не подсвечен) - прогоняем его через chmod +x.
При его запуске откроется следующее меню:
Не удалось прогрузить медиа
Нам потребуется опция под номером 1 - установка. Ее мы и выбираем. Установка запустится, автоматически скачивая все необходимое, от нас требуется лишь ожидание. Далее установщик попросит выбрать базу для хранения, порт для панели, настройки SSL. Выбираем sqlite как более стабильный вариант из коробки, даем панели сгенерировать порт наобум, генерацию SSL-серта пропускаем:
Не удалось прогрузить медиа
Что же дальше? Панель спросит, хотим ли мы закрыть панель сразу же под 127.0.0.1(внешний доступ к веб-админке будет невозможен), и выдаст креды для подключения.
На скриншоте я выбрал опционал закрытия панели сразу же под 127.0.0.1 отключить, так как сам по себе 3X-UI генерирует довольно неплохие юзернеймы и пароли, и за 10 минут их точно не сбрутят, но вы можете уже на этом этапе включить доступ только через локалхост. Тогда, чтобы продолжить конфигурацию, нужно будет провести туннель через SSH примерно таким образом:
ssh root@ip_addr -L panel_port:localhost:panel_port
После авторизации заходите в браузере на ссылку, выданную установщиком, только IP меняете на 127.0.0.1, и авторизуетесь - все точно так же. Подобный функционал как раз добавлен с обновлением; раньше от SSL отказаться было нельзя, что порой ломало развертку.
Панель будет выглядеть следующим образом:
Не удалось прогрузить медиа
Все интуитивно понятно, и умником быть не нужно.
Для начала, следует проследовать в раздел "inbounds" - это раздел, отвечающий за инбаунды - входящие подключения. Тут и формируются коннекты для пользователей.
Выбираем опцию "создать подключение", и именно здесь начинается конфигурация.
Не удалось прогрузить медиа
Выбираем следующий опционал:
- Порт, соответствующий тенденциям "настоящего веба". Это должен быть порт, на котором можно встретить HTTPS-подобный трафик(то есть, условные 80 и 3306 нам не подойдут, выбор делаем в пользу 443/6433/8443 - так натуральнее).
- Несмотря на появление всяких Hysteria2(тут не поддерживается) и прочих прелестей жизни, выбираем в данном случае именно VLESS. Он обкатан, стабилен, клиенты под него уже достаточно развиты, чтобы их использование не было мучением; как бы служба на три веселых буквы не вопила о его блокировке, он все еще работает и будет работать, пока не сломают половину интернета.
Не удалось прогрузить медиа
- Аутентификацию выбираем X25519 - она переваривается большинством клиентов без ошибок, в отличие от более современного аналога.
Не удалось прогрузить медиа
- Настройки соединения желательно оставить на TCP(Raw) - это наиболее оптимальный выбор, который уже хорошо обкатан в связке с Reality. При правильной конфигурации живет вечно.
Далее самая "ответственная" часть. Настройки реалити. Выбираем в разделе security именно его.
Не удалось прогрузить медиа
И как следует из простой логики, дефолтные встроенные значения по типу доменов инвидии, амазона, оракла нам здесь не подойдут(недавно пытались вдарить даже по гитхабу).
Первая же активная аппробация этого соединения выдаст его сущность, после чего адрес будет "внесен в черный список" как потенциальный VPN-сервер, если это белые адреса от популярных компаний по типу Yandex/VK Cloud/Sentinel, то это грозит и блокировкой услуги.
В зависимости от того, где находится первая нода, можно выдать SNI/Target следующим образом:
- Если Вы купили белый адрес из пула VK Cloud, можете смело ставить в значение SNI медиа-домены vk.ru или домен max.ru. Оба домена являются членами "белого списка", реальные адреса, закрепленные за их поддоменами и CDN, действительно относимы к пулам именно этого хостинга. Это не будет выглядеть аномально со стороны.
Можете проверить это собственными руками: смотрим на домен max.ru, определяем CIDR, к которому принадлежит адрес, бьем его через хуррикан(по моему мнению, один из наиболее удобных инструментов для подобных исследований).
Не удалось прогрузить медиа
Не удалось прогрузить медиа
- Если белый адрес принадлежит пулу Yandex, мы по прежней аналогии берем домен из их зоопарка(экосистемы) сервисов.
Отсюда, вывод напрашивается довольно простой: нужно мимикрировать под предельно естественное веб-соединение к этим сервисам, которые принадлежат белым спискам, дабы не палить контору. Никаких различий между доменом и пулом адресов, никаких странных портов и странных типов соединения(какой gRPC на ya.ru?). Мы должны выглядеть нативно.
В моем случае, как и упоминалось, один из ближайших соседей - это *.x5.ru. Я взял запись ads, так как она связана с подгрузкой значительного количества медиа и связана с крупными объемами трафика.
Однако, как эффективно узнать, кто соседи, если это не прежние два варианта или если хочется соригинальничать?
На то и нужен упомянутый ранее софт. Установка проста: переходим во вкладку релизов, качаем по прямой ссылке через wget.
wget https://github.com/XTLS/RealiTLScanner/releases/download/v0.2.3/RealiTLScanner-linux-amd64
Для удобства переименуем в tlscanner, перекинем в /usr/local/bin для доступа в любом месте и придадим права исполняться:
mv RealiTLScanner-linux-amd64 tlscanner
sudo mv tlscanner /usr/local/bin
chmod +x /usr/local/bin/tlscanner
Утилита несложная: просто берем свой адрес, скармливаем ей, на выходе получаем своих "соседей". Однако, стоит упомянуть, что у нее есть опционал установки числа потоков, который желательно не трогать: в слишком агрессивном режиме сканирования "своих же" хостинг может выдать желтую карточку.
tlscanner -addr <VPS_IP>
В ответ получим соседушек, под которых можем мимикрировать. Однако, большинство из них вряд ли будут подходить для обхода БС, и работать подобный конфиг будет преимущественно на проводке. Тем не менее, если сканирование пущено с "белых пулов", можно найти и тех, кто в списках присутствует:
Не удалось прогрузить медиа
Подробнее конкретно об обходах БС с сравнениями по провайдерам будет далее; я возьму сабдомен пятерочки, который ранее нашел.
Помимо выставления SNI/Target в конфиг надо сгенерировать пару ключей(приват/паблик), остальное трогать нежелательно. Сниффинг мы тоже не включаем: чаще он ломает конструкцию, чем улучшает ее.
Не удалось прогрузить медиа
Сохраняем инбаунд. Я создал два инбаунда, один из которых соединяется "через один сервер", а другой - "даблхоп". На яндексе так делать не рекомендую: зайдете в какое-то русское приложение, и оно о вас настучит.
Подобным образом устанавливаем и разворачиваем панель на втором VPS/N-ном VPS, зависит от того, какую цепочку вы выберете. На последующих серверах(уже не в РФ-гео) нет смысла так запариваться, и можно выбрать любой рабочий SNI, предлагаемый самой панелью. Допустим, oracle.com. Если ваш первый сервер в цепочке - "обходной", и принадлежит той самой троице провайдеров, соединять его со вторым я рекомендую только через VLESS: все из названных провайдеров любят детектить у себя впн-серверы, дабы заставить клиента еще раз заплатить за новый адресок, а вайргуард/шедоусокс и так далее сложно не заметить.
Не удалось прогрузить медиа
Получаем инбаунд на второй панели.
После обновления нельзя сразу забрать подписки в том же меню: нужно создать клиентов. Этим и займемся на обоих VPS, перейдя в поле "Clients". Второй VPS:
Не удалось прогрузить медиа
Жмем "Add clients", ничего можем не менять, кроме "закрепленных соединений" - "Attached Inbounds".
Не удалось прогрузить медиа
Далее забираем подписку в формате той самой, узнаваемой "влесс-ссылки" через клавишу-QR код, указанную рядом с клиентом. Первый QR-код и первую ссылку не трогаем, это ссылка подписки, берем вторую ссылку.
Забираем ее на первый VPS, и теперь создаем аутбаунд - исходящее подключение. Делаем это через "Xray Config" в боковой панели, зайдя в "Outbounds". Создаем аутбаунд через клавишу с плюсом и переходим в раздел JSON - там есть автоматический импорт конфига по одной лишь ссылке:
Не удалось прогрузить медиа
Не удалось прогрузить медиа
Почти что финишная прямая. После добавления сверху прожимаем "Save" и переходим в графу "Routing Rules". Там надо создать правило, согласно которому трафик с первого соединения будет перенаправляться на второе на второй VPS. Сделать это не так сложно. Создаем новое правило, и делаем следующим образом:
Не удалось прогрузить медиа
- Network: TCP/UDP(перенаправляем и TCP, и UDP - весь трафик)
- Inbound Tags - выбираем тот инбаунд с первого впс, который станет даблхопом, если он у вас и так один, то его и ставим.
- Outbound Tags - выбираем наш аутбаунд из доступных(тот, что мы добавили).
Отдельно замечу, что советы на ютюбе про "исключения" на "русские приложения", при которых трафик идет сразу с первого VPS, вредоносны, если вы используете айпи из пула яндекса/сентинела/вк клауда. Сейчас приложения активно собирают статистику и стучат, этот адрес будет с высокой вероятностью заблочен и помечен как VPN. Если цель стоит только в обходе ограничений/БС, следует просто взять второй VPS все так же в России, но уже в любом провайдере за крипту, как вам угодно. У меня цепочка под проводной интернет, и оба сервера не принадлежат БС, куплены за крипту.
Перетаскиваем новое правило роутинга повыше, сначала жмем "сейв", потом "рестарт".
Финальным штрихом так же создаем клиента на первом VPS, забираем его себе. Стоит сразу сказать, что если изначально вы выбрали установку через привязку к локалхосту(один из вопросов установщика), то следует в каждом созданном инбаунде напрямую указывать адрес вашего VPS. До сих пор панели 3X-UI свойственен баг, при котором все втупую ломается, и панель под локалхостом вставляет в Listen IP 127.0.0.1.
Если вы такую опцию не выбирали, то после создания всех нужных клиентов и инбаундов следует в каждой панели перейти в "Panel Settings" и проставить в Listen IP 127.0.0.1, чтобы закрыть панель от внешнего интернета, после чего снова сделать "Save" и "Restart Panel". Если вы не туннелировали порт панели, она сразу пропадет из вашего доступа в браузере, и это нормально.
Не удалось прогрузить медиа
Забираем подписку в клиент, который у нас уже есть, о чем речь пойдет несколько позже. Допустим, это V2RayN. Получаем следующее:
Не удалось прогрузить медиа
У меня создано 2 сабки, и обе работоспособны.
Как итог, у нас появляется свой VPN, пропущенный в идеале через несколько юрисдикций, что крайне замедлит потенциальный сбор информации о Вас. Вдобавок, подобная реализация позволяет и обходить существующие ограничения, касающиеся мобильного интернета, при определенных условиях.
Среди основных:
- максимально подобное вебу поведение на сетевом уровне: реалистичные порты, реалистичный внешний вид трафика(о чем говорилось ранее в сравнении с gRPC/прочим редким категориям в неестественных для них местах)
- соответствие указанных SNI - Server Name Indication - условиям, в которых находится сервер.
- доменное имя для SNI, потенциально входящее в белый список
- наличие "белого адреса", выловленного из пулов, в которых они обычно обитают.
Конструкция может быть с легкостью расширена в условиях обхода БС до 3 серверов, что даст достаточную анонимность(белый адрес - VPS 1 - VPS 2), и в целом разворачивается относительно просто. Однако, среди ее потенциальных минусов все еще остается факт того, что вы и еще, возможно, пара человек(хотя это и крайне редко) - ее единственные пользователи. Трафик не замиксован, а любой детектор по типу 2ip.ru сразу же говорит, кто ваш провайдер. Будучи лишь клиентом-физическим лицом, вы остаетесь в рамках клиента этого хостинга.
Но что, если исправить это?
Мануал 2: свой "мост" для популярного VPN-провайдера
А что, если использовать, как и раньше, какой-то из крупнейших VPN-сервисов, имеющий оборот в сотни тысяч клиентов и больше? В потенциале это помогает еще больше запутать следы за счет дележки одной ноды с кучей пользователей, что возможно в случаях, когда VPN действительно мало знает о вас(и тут следует упомянуть всякие уже ставшие классическими PIA, Mullvad и прочие часто используемые провайдеры) или в случаях, когда VPN вообще связи с вами не имеет и был перекуплен/добыт из логов.
Однако, большинство подобных провайдеров на данный момент времени эффективно блокируются, и их использование может вылиться в отдельное приключение. И в каком-то смысле это даже играет нам на руку.
Многие уже слышали о проекте, названном gluetun. На данный момент у него есть как свой развитый репозиторий с частыми обновлениями, так и свой образ на докерхабе.
Не удалось прогрузить медиа
Сами разработчики позиционируют его "швейцарским ножом" по работе с коммерческими VPN, и это в целом-то не так и далеко от истины. Можно сказать, что это универсальный клиент, поддерживающий OpenVPN/WireGuard/DNS-over-TLS соединения и кучу прочих нужных вещей, созданный для работы практически со всеми широко известными впн-сервисами. Так почему бы не использовать его в своей инфраструктуре?
Идея проста. В начале мы ставим VPS, на котором развернут VPN, способный обходить нынешние ограничения - можно сказать, что это селфхост-часть. А далее мы перенаправляем трафик, выходящий из селфхоста, в популярный VPN-сервис, который нами желаем. Для этого с докерхаба возьмем два образа: один - с любым удобным и чистым форком 3X-UI(оригинал пока что нередко багуется в сложных сетапах после обновы), другой - с gluetun самим по себе. И объединим их в единую сеть, в которой доступ 3X-UI возможен только через впн-коннект и публично доступный порт для входящего соединения. Выглядит пример конфигурации следующим образом:
Не удалось прогрузить медиа
Структура строится на трех сервисах. Как можно заметить, два из них в основе своей являются образами от одного автора, что и не мудрено: deunhealth - отдельная утилита, поддерживающая совместную работу с gluetun и способная обеспечить его стабильную работу(например, производить переподключения и мониторить общее состояние сервиса). Многие юзают их совместно:
Не удалось прогрузить медиа
Подобная реализация уже была озвучена многими, и далеко не раз. Однако, наша будет минимально функциональной, без излишеств.
Мы отдельно закрепляем доступ xui в интернет только через gluetun; порт 54321 в данном случае дефолтно отвечает за админ-панель и вынесен лишь на localhost. Он будет доступен через SSH-туннель на 127.0.0.1:54321:
ssh root@<VPS_IP> -L 54321:localhost:54321
В данном случае(в память бастерлорду :D) выбран PIA VPN, до сих пор используемый многими без особых проблем. Формат выставлен в OpenVPN. Однако, это далеко не единственный поддерживаемый функционал - поддерживается большое количество VPN, какому верите больше - решение стоит за вами.
Добавляем docker-compose.yml на свой VPS, устанавливаем туда Docker и Docker Compose - установка зависит от дистрибутива и прямо закреплена на официальных ресурсах докера.
mkdir VPNBridge/
mv docker-compose.yml VPNBridge/
Переходим в директорию, и запускаем оркестр:
docker compose up -d
Первый запуск может быть долгим. Ожидаемый результат следующий:
Не удалось прогрузить медиа
После этого переходим в docker compose logs -f и ждем, когда все сервисы поднимутся и начнут полноценную работу.
Основные строки, которых следует ожидать, следующие:
deunhealth | <time> INFO No container found to restart when becoming unhealthy
deunhealth | <time> INFO Monitoring new container double-gluetun-1 to restart when becoming unhealthy
Это свидетельствует об успешном старте сервиса-мониторщика.
gluetun-1 | <time> INFO [ip getter] Public IP address is <ip> (Sweden, Stockholm, Stockholm - source: ipinfo+ifconfig.co+ip2location+cloudflare)
Это свидетельствует об успешном подключении к VPN со стороны gluetun.
xui-1 | INFO - Web server running HTTP on [::]:54321
Это свидетельствует об успешном старте форка 3X-UI и его панельки. Переходим и конфигурируем по схожей схеме. Управление отличается лишь в одной черте: нам не нужно создавать отдельного клиента, доступ к подписке находится сразу в инбаундах.
Не удалось прогрузить медиа
Вдобавок, в данном случае ничего настраивать со стороны панели НЕ нужно: она и так не пойдет дальше, чем локалхост самого VPS, так заложено в докер конфиге.
Не удалось прогрузить медиа
Процесс создания инбаунда же схож с предыдущим мануалом, разве что менюшка в данном случае отличается. Поле под IP мы оставляем обязательно пустым, и подписку нам выдаст в формате ссылки со 127.0.0.1: так происходит потому, что 3X-UI в связи с сетевой конфигурацией сам не понимает, где находится. В подписке нужно вручную поменять 127.0.0.1 на IP от VPS.
Как итог, получаем структуру, где на входе встречает самоделка, а на выходе - популярный коммерческий продукт, который перемешивает нас с остальными пользователями, спокойно смотрящими нетфликс.
Не удалось прогрузить медиа
И здесь, несмотря на относительное соблюдение принципа нулевого доверия к коммерческому продукту, тоже есть фундаментальный вопрос, кроющийся в вашем доверии к тому или иному сервису. Тем не менее, это куда анонимнее, чем использовать его напрямик.
В скором времени приложу к теме два софта, один из которых позволит производить ротацию такого "моста" удаленно, а второй будет нацелен на облегченную развертку многослойного VLESS.
А что с клиентами?
Относительно длительный промежуток времени VLESS-впны претерпевали единую проблему, особенно неприятную в ситуациях, когда нужна анонимность, и проблема довольно простая: большинство клиентов некорректно работали с TUN-режимом(как раз таки режимом виртуального сетевого интерфейса, в который все перенаправляется) и к тому же не имели киллсвитча.
Однако, на данный момент уже было выпущено приложение, поддерживающее данный функционал и постепенно замещающее устаревшие Nekobox/Happ и прочие клиенты - INCY.
Решение хоть и довольно молодое, но кроссплатформенное:
Не удалось прогрузить медиа
Функционал kill-switch доступен и на Windows, и на Linux, что является отличным решением для тех, чья хостовая машина - винда, и для тех, кому лень копаться с ufw и своим киллсвитчем.
Для православных пользователей линукса на хостовой машине я бы порекомендовал как более надежную во многих планах альтернативу использовать ufw и V2RayN, который прекрасно с ним работает.
После установки V2RayN(имеющего такую же кроссплатформенность) и добавления профиля сначала устанавливаем ufw:
sudo apt install ufw ##для Debian, полагаю, дистрибутивы на его базе у большинства пользователей десктопного линукса
sudo ufw enable ##включаем файерволл
sudo ufw allow in on lo
sudo ufw allow out on lo ##разрешаем обмен данными с локалхостом, чтобы система не сдурела
sudo ufw default deny incoming
sudo ufw default deny outgoing ##явно запрещаем всему трафику входить и выходить
Далее узнаем, как называется интерфейс от V2RayN, через ifconfig. Обычно это singbox_tun:
sudo ufw allow out on singbox_tun
sudo ufw allow in on singbox_tun ##разрешаем трафик через конкретно этот интерфейс
Однако, для того, чтобы туннель был инициализирован, нам нужно в начале подключиться к серверу(VPS). Для этого следует создать отдельное исключение:
sudo ufw allow out to <IP_входящего_VPS>
По факту, на этом этапе киллсвитч уже будет работать, и хватит лишь одного sudo ufw reload, чтобы он запустился.
Однако, многие работают с виртуалками, имеющими свой локальный диапазон, и это важно учесть: если не разрешить явно работу с этим диапазоном, то по логике "запрещено все, что не разрешено", которую мы воссоздали, интернета в виртуалках не будет. Их конфигурации так же узнаются через ifconfig: будет видно отдельные виртуальные интерфейсы, связанные с ними. В случае KVM, например, это обычно диапазон 10.0.2.0/24:
Не удалось прогрузить медиа
Разрешим его.
sudo ufw allow to 10.0.2.0/24
sudo ufw allow from 10.0.2.0/24
В таком случае после sudo ufw reload получим готовый к работе киллсвитч под V2RayN, который будет работать, что можно проверить отдельно на тестах с определителями айпи.
В чем итог? За короткий промежуток времени можно получить достаточно интересные самостоятельные реализации своего собственного VPN с интеграцией популярного сервиса или без него, которые при правильном применении определенно способны защитить их пользователя. Хватит базовых навыков администрирования, чтобы управиться с такой инфраструктурой.
Варианты, продемонстрированные здесь, могут применяться как для обхода ограничений в средне-тяжелых условиях, так и для анонимизации, и это является их общей чертой несмотря на изначально разное предназначение и разную учтенную модель угроз.
Актуальная методология поиска белых IP для создания обхода на белые списки будет чуть позже приложена отдельной инструкцией под этим топиком, сюда же будут поститься другие варианты развертки своего VPN/обхода ограничений, на разные цели и задачи. Уважаемым участникам нашего сообщества могу сказать, что эта ветка открыта для обсуждения, и каждый может делиться чем-то своим, благо, инструментов уже очень много, и с каждым днем они становятся все более продуманными и развитыми.
Я же буду продолжать пополнять эту ветку интересными информацией, решениями и вариантами, которые удалось найти и проверить уже мне(в нынешних условиях мне приходится просить помощи у другого человека, чтобы он тестировал решения, нацеленные на борьбу с такими острыми проявлениями цензуры, как белые списки).
Будьте внимательнее при выборе сервисов, от которых зависит ваша анонимность. Никогда не ленитесь потратить пару часов своего времени, чтобы разузнать репутацию продукта. Ну а в случае чего - всегда есть решения, которые позволяют развернуть вашу собственную крепость ;)
👍30
🔥6
😮6
👏6