Как соединить мысли?

1

Я пытаюсь разобраться в текущем многообразии инструментов для обхода интернет-блокировок, но пока немного запутался. Хотелось бы понять, какое решение на сегодняшний день выглядит наиболее разумным (не считая радикальных вариантов вроде переезда из страны или использования спутникового интернета).

У меня есть несколько идей и вопросов, но из-за недостатка опыта сложно собрать всё в цельную и правильную схему.

  1. Лучше ли настраивать доступ через один зарубежный сервер или делать цепочку вида: Россия → зарубежный сервер (например, в Европе)? Чтобы выглядело как сервер — сервер.

  2. Где лучше размещать основной сервер — у зарубежного провайдера или у российского? С одной стороны, зарубежный провайдер не подчиняется требованиям РКН. С другой — возможно, вероятность блокировки IP-адресов российских хостеров ниже.

  3. Я слышал о схеме обратного подключения, это когда сервер за пределами России инициирует соединение с сервером внутри страны. Правильно ли я вообще понимаю принцип? Как это обычно настраивается?

  4. Что разумнее использовать для настройки: AmneziaVPN, 3X-UI, ручную конфигурацию протоколов? Amnezia кажется удобной, но при этом довольно ограниченной в плане гибкости настройки.

  5. Как вообще идея держать резервный сервер, например в Google Cloud, и маскировать трафик под Google-сервисы?

  6. А основной сервер скрыть за Cloudflare?

  7. Правильно ли я понимаю, что сейчас важна поддержка нескольких разных протоколов? Таких как VLESS, Shadowsocks, AmneziaWG, OpenVPN+Cloak.

  8. Тут смешно, но всё же когда достаточно просто zapret?

  9. Насколько безопасно выдавать доступ к своему серверу относительно большой группе людей (например, семье из 10–15 человек)?

  10. Если использовать сервер в России, лучше ли маскировать его под собственный настоящий сайт или, например, под инфраструктуру Яндекса (разместив его в Yandex Cloud)?

  11. Правильно ли я понимаю, что если, например, бабушка случайно зайдёт в MAX с включённым VPN (даже если используется раздельное туннелирование), это может раскрыть всю схему? Есть ли способы с этим бороться (не оставляя бабушку без VPN)?

  12. Наверное, имеет смысл отдельно настроить MTProxy для Telegram, чтобы не приходилось постоянно включать VPN. Может ли использование MTProxy каким-то образом скомпрометировать сервер?

  13. Нормально ли направлять трафик YouTube через российский сервер, если на него напрямую нет таких блокировок? Или это тоже может повысить риск компрометации сервера?

  14. Может быть, для YouTube вообще имеет смысл сделать максимально простую схему — например, настроить обычный WireGuard на российский сервер и использовать его только для этого трафика?

Надеюсь, что ответы на эти вопросы будут полезны не только мне (а цензоры ничего с этим не сделают :). Всем спасибо.

UPD: 15. Вспомнил ещё насчёт разных IP-адресов для входа и выхода у сервера, это ведь наверняка добавит проблем цензорам?

2

IPv4(1) → РФ VPS → IPv4(2) → WARP \ DIRECT \ Foreign Upstream Proxy
По умолчанию сайты идут в WARP, всякий YouTube/игры → DIRECT
inbound IPv4 отличается от outbound IPv4 (купить два белых IPv4). Дефолтный в системе - outbound IPv4.
Сайты с геоблоком - upstream proxy.

Российского. Так ты получишь WARP в РФ, нужный для открытия РФ ресурсов, + пинг меньше.

Не нужно такое, сервер в РФ должен сам уметь подключаться куда угодно.

sing-box на ПК/OpenWRT роутере и sing-box на сервере. Протокол - VLESS-XTLS-uTLS-REALITY, транспорт TCP, без изысков. Стабильность важнее. Конфиги текстом, декларативные. Документация. К серверу подключаться по SSH over Tor через мосты/другой зарубежный прокси. Не палить провайдеру голый SSH. В inbound можно добавить другого пользователя для overlay сетей типа I2P.

Можно, но к ним внимания больше (и проверок!), лучше REALITY к SNI в той же подсети провайдера, где ты и держишь основной сервер.

Cloudflare CDN сейчас замедляют, так себе идея, к нему внимания много. Ладно ещё подменять SNI для доступа к какому-то ресурсу одиноразово, но не 24\7 же трафик к нему.

VLESS-XTLS-uTLS-REALITY, остальное лучше не надо, не меняй тип трафика, к этому внимания больше, если хоть один твой протокол выдадет прокси, забанят твой VPS по IP независимо от используемого протокола.

Не нужен, пусть провайдер не сует нос в твой трафик вообще, если тебе важен OPSEC, который прокси инфраструктура тебе предоставит. Не вижу смысла зависеть и танцевать с бубном вокруг этих опсовов-кровососов, если прокси стабильнее.

Вполне, но не забудь разделить inbound/outbound IPv4 и это супер-важно, сейчас любое приложение может шпионить и получать egress IP твоей прокси цепочки.

Под чей-то сайт в той же подсети того же хостера на котором этот сайт хостят. То есть IP слегка отличается. Иметь ввиду, что тот сайт может заблокировать твой IP если заметит постоянные прокси запросы к нему, это будет видно в Wireshark, где твой VPS IP долбится к их IP. Тогда снова SNI поменять на другой.

Разделить inbound/outbound IPv4. То есть купить два белых IP. Дефолтный в системе - outbound IPv4. Но в конфиге sing-box железно укажи забиндить трафик через outbound IPv4 на всякий случай.

И по дефолту пусть всё в WARP идет. Через Wireguard endpoint лучше, чем socks5 (warp-cli).

В этом случае утечки не страшны, ведь шпионские ПО не видят твой inbound Ipv4 без рут прав.

И я не просто так это говорю, как только я это сделал так сразу перестали дропать трафик. Предыдущий IPv4 сейчас в глухом бане, используется как outbound IPv4.

VPN должен быть включен постоянно 24\7. РФ сервисы пускать через WARP с Yandex DNS (на серверном sing-box принудительно через него резолвить). Остальное - Google DNS. Так всякие Госуслуги, Кинопоиск и т.д работать будут. ChatGPT/TikTok (к примеру) и прочие сервисы с геоблоком - upstream proxy. То даже на условном айфоне любые сервисы будут открываться. IPv6 отладить, чтобы AAAA-only сайты открывались, как этот форум.

На ПК sing-box лучше FakeIP настроить с внутренним пулом IPv4/IPv6. WARP автоматом IPv6 пробросит.

В итоге никакой MTProxy тут не нужен. Весь трафик идет через туннель, комар и носом не пошевелит теперь и не увидит куда ты подключаешься.

Да, я так и делаю, в DIRECT пускаю с outbound IPv4. Это абсолютно нормально, так как доверенный сервис.

Не нужен такой схематоз с разделением трафика. Лучше как можно к простой формуле инфраструктуру свести.

Ну вся информация - публичная, ничего нового я не рассказал. Я сам с этого форума много инфы черпал.

Ещё как! Раньше до того как я это сделал постоянно обрывы были, я не понимал какого хрена, теперь понимаю, шпионили собаки.

3

расскажи, пожалуйста, почему это плохо?

4

Интересно пишете, но, полагаете, простой пользователь осилит подобные изыски? Нужно либо искать хостеров, которые все это за денежку дополнительную настроят (хотя я подобных услуг еще не встречал нигде, возможно, в частном порядке удастся найти специалиста), либо пару месяцев потратить на изучение и внедрение подобного функционала. И это если есть хорошая база по сетям. А если базы нет и все знания на уровне “скачать ВПН-приложение на телефон”, то и того больше.

При этом лично я не совсем понимаю целесообразность подобных заморочек. РКН точечные блоки редко применяет, с вероятностью 95% в бан отлетит VPS-хостер целиком - и пофиг уже на сколько лично ты запарился с маскировкой трафика. Мне кажется, в таких условиях разумнее обходиться минимальным минимумом. У меня именно так сделано: VPS в Финляндии с VLESS XHTTP Reality… И, собственно, все. Никаких сайтов-заглушек нет, доменного имени тоже нет, голый айпишник. Единственное что сделано в плане безопасности, да и то скорее это самого сервера касается - это создание правила на файрволле, чтобы к 22 порту только с моего домашнего IP можно было подключиться. Все. Такая вот примитивная защита от хакинга.

Тратить же больше времени и сил на обход блокировок в нынешних условиях мне кажется неразумным. Хотя, конечно, с любопытством послушаю ваши контр-аргументы. В теме вы очевидно получше меня разбираетесь, возможно, я чего-то не понимаю и не осознаю ввиду малого опыта и необразованности.

5

Многих так деанонимизировали. К SSH серверу напрямую подключались. Очевидно что ты к своему серверу лезешь, и с условием такого объема трафика который ты к нему генерируешь, то можно уверенно подтвердить факт того что это прокси.

Иначе ты мог на любой сервис столько трафика генерировать, не банить же его без доказательств что это прокси сервер. А вот подключишься ты к нему по SSH - доказательства будут.

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

6

интересно, а direct для ютуба - потому что на udp туннель фактически (wg потому что) живет, и quic туда спокойно влезает? не нужно его в tcp пихать?

7

А ведь действительно, если ваш прокси прикидывается каким-нибудь Майкрософтом, а потом условный Вася Пупкин из Мухосранска заходит туда по SSH, разве это не разоблачает сразу же прокси?

8

Если self-steal, то это не будет выглядеть странным.

Чем self-steal вас не угодил?

Как минимум пинга меньше.

Уже обсуждали - Яндекс DNS вовсе не гарантирует выдачу рабочих IP адресов для WARP.

9

Вы слишком сильно пытаетесь продумать наперед, у нас таким заниматься нецелесообразно.
Идите от простого к сложному, решайте проблемы по мере их поступления.
Всегда начинайте с самых дешевых вариантов.

Около двух лет у меня все стабильно работает на одном зарубежном сервере (для ~15 человек, разбросанных по европейской части РФ).
Возьмите VPS у какого-то небольшого провайдера (без поддержки рублевых карт) с собственной инфраструктурой.
Поднимите там что-то вроде AnyTLS (TCP, выглядит как TLS, есть мультиплексирование) и AmneziaWG (UDP, настройте мусор так, чтоб был закос под какой-то протокол)
На клиентах сделайте разделение по geosite/geoip ru, пусть идет как есть.
Для зондированных СКАМоюзеров на сервере сделайте выход через warp, точка входа не должна совпадать с точкой выхода трафика.

10

Можно, но репутацию сайта выращивать надо. Что-то пошло не так - чуть что переехал, присосался к какому-то SNI с дистанцией в 1 мс.

Наигрался я с zapret, тем более хоп в ASN Ростелекома постоянно полудохлый через который у меня трафик маршрутизировался к Cloudflare CDN\Spectrum. Уж лучше какой-то стабильный рабочий канал. Понятно что для real-time игр (а для чего же ещё вам пинг) можно и проброс напрямую сделать, если уж совсем далеко хостятся от вас или реверс-прокси прям рядом с ними запустить.

На счёт этого не знаю, как минимум мне для госуслуг выдает рабочие, в отличие от Google DNS. Больше мне не надо. Клал я на всё остальное, то что мне надо - открывается. Для каких-то экзотически вражеских-для-WARP сервисов можете другие DNS использовать или другой upstream proxy.

11

Когда реализуют проверки на соответствие SNI к ответам от DNS-запросов, как уже делают в Иране, это уже не поможет.

Тот факт, что у вас работает, а у других - нет, означает, что это далеко не универсальное решение. Мне “правильные” IP адреса выдал Cloudflare DNS, а неправильные - выдал и Яндекс. А DNS на экзотичные сайты вообще не влияют, у того же mosmetro.ru (который далеко не “экзотичный”, а вполне типичный сайт в госсекторе) блок больше похож по входящему IP-адресу/CIDR, там только один IP-адрес.

12

Дак не надо сливать DNS запросы этим опсосам-кровососам. Всё через VLESS туннель должно идти.

Согласен, я методом проб и ошибок добивался чтобы госуслуги работали.

Да, я тоже к тому же пришёл, что они тупо IP заблокали. Ну и хрен с ними, нафиг этот сайт не нужен. Можно в какое-то upstream прокси завернуть.

13

Речь не про слитие DNS-запросов. Если они порешают сравнить SNI в ClientHello и IP адрес, к которому подключаетесь, с ответом от DNS-сервера на тот же SNI, как уже делают в Иране, работать будет только self-steal.

14

А, ну разные DNS дают разные IP. Например к тем же госуслугам Google DNS и Yandex DNS разные дают. Несовпадать могут по разным причинам.

И поэтому не сливать к какому именно DNS ты ходил.

15

А перебирать по DNS-серверам IP-адреса вовсе и не сложная задача, даже тут есть скрипты для этого.

Это вообще роли не играет.

16

Все не переберешь. Их может быть тысячи, ещё и приватные/неизвестные DNS. Более того, этим никто заниматься не будет. Слишком дорогая и ненадежная эвристика.

Играет, если перехватывают DNS, сравнивают ответ и SNI и IP подключения. Поэтому должно быть зашифрованно как минимум, а лучше не сливать DNS вообще.

17

Даже с учётом этого они могут просто заблокировать посторонние DNS (и всё движется к этому), тогда им будет без разницы, что выдаст ваш приватный DNS-сервер, будет важен лишь тот ответ, который выдаст провайдерский.

Причём тут тот факт, перехватывают или нет? Вы подключаетесь к серверу, используя доменное имя? DNS-сервер тут вообще не причём, вы никакие запросы не делаете. У вас ClientHello отправляется непосредственно к конкретному IP адресу без его участия.

18

Не имеют никакого права так делать. Это нарушение приватности, конституционное право. Никакие опсосы-кровососы не должны видеть куда я подключаюсь.

Я не обязан публиковать свой IP от reverse-proxy к моему сайту в какой-то там жалкий “провайдерский” DNS. Блокировать по такой эвристике - варварство. Я не обязан ничего никуда публиковать ни в какие там DNS которые они перебирают.

Ну так SNI и сертификат у них будет совпадать. Причем тут DNS тогда? Я не обязан публиковать ни в какие DNS ничего. Хочу - просто голый reverse-proxy который тупо TCP passthrough делает к моему реальному серверу.

19

Смешной у вас аргумент. Цензура-то тоже формально запрещена Конституцией РФ. Но офф-топ закончу на это.

Ничего не публикуется вами лично, вы вообще понимаете, как DNS работает?

Суть вы не поняли. Провайдер/ТСПУ/РКН (цензор) видит, что вы подключаетесь по SNI условного www.google.com к IP адресу 123.123.123.123. Затем цензор лезет в свой DNS, видит, что ответ для SNI www.google.com - 123.123.123.124, а не 123.123.123.123, и блокирует ваш сервер (так уже делают в Иране). Естественно, DNS запросов никаких не было с вашей стороны.

20

Я понял, публикуется A/AAAA запись и DNS сервера иерархически по цепочке её подкачивают.
Но не суть важно, я всё равно должен привязать условную A запись к какому-то IP. Если у меня реверс-прокси, я не обязан публиковать A запись для него (обычно у провайдера домена).

Хорошо, ну и что? Я не обязан публиковать, а точнее привязывать домен к реверс прокси.
Ну очевидно не к www.google.com, а к малоизвестному SNI в подсети провайдера. Я про это и написал в этом треде, не использовать популярные, а в той же подсети, обычно малоизвестные. Понятное дело лишних reverse-proxy у Google нет. А у какого-то малоизвестного шопа - почему бы и нет, для балансировки нагрузки, что-то обрабатывать на другом backend VPS.