В общем появилась новость, что Microsoft штрафанули на 3.5 млн. рублей и как понимаю, могут поблокировать сайты и их сервера. С этим возникают вопросы, может быть кто лучше подскажет:
- Сейчас идёт мимикрия под сайт microsoft, на какой лучше сменить? Или лучше свой развернуть?
- Если лучше свой, то где лучше брать домен и подешевле, а также ещё лучше через крипту?
- Как настроить правильно так, чтобы при всех ответах, кроме VLESS отправляло на сайт, а определённые ответы от VLESS на xray core?
- Как заныкать правильно панель 3xui, чтобы также её не было видно?
- Стоит ли ещё изучать заместо VLESS-Reality другие способы? (WebSocket, SplitHttp, HttpUpgrade). Если да, то какой самый лучший по отзывчивости и скрытию?
- Есть ли способы, чтобы работал не только TCP, но и UDP?
- Оставаться на Xray core или sing-box чем-то будет лучше?
От себя: я пытался читать и понять отличия от Reality других (WebSocket, SplitHttp, HttpUpgrade), но до конца не вкурил по мануалам, чем они будут лучше. По доменам - не нашёл регистратора, чтобы как можно меньше данных спрашивал (хостеры благо такие есть, где данных им мало надо) + чтобы была оплата криптой.
Хороший вопрос. Часть общедоступных серверов, которые я видел, мимикрирует под speedtest.
- Лучше всего выбирать что-нибудь из сети того же хостера, на сервере которого поднят прокси. Это должен быть иностранный сервер (вне РФ), не забаненный по домену Роскомнадзором, поддерживающий подключения по TLSv1.3 и HTTP/2, имеющий заглавную страницу, которая не переадресовывает на какой-нибудь другой домен. Для этого есть специальный инструмент: GitHub - XTLS/RealiTLScanner: A TLS server scanner for Reality. Можешь посмотреть вот тут, как его используют. Прим: из РФ статья не открывается.
- Свой всегда лучше, так как в таком случае вы не зависите от доступности другого сайта: технические работы и прочее. Где брать домен не подскажу, так как маскируюсь под чужой сайт.
- Почитайте статью, там всё более менее нормально написано. Можно ещё гайд с ProjectX посмотреть, там вообще с нуля написано как VPS настроить и все дыры закрыть. Но он только для VLESS, без Reality. Можно эти два источника совместить, настроить VPS по гайду ProjectX, а XRay настроить по статье с харбра.
- Панели X-UI или 3X-UI стоит перевесить со стандартного порта на какой-нибудь нестандартный сильно повыше. В идеале стоит вообще заставить ее слушать на 127.0.0.1 (localhost), а подключаться к ней через SSH: например, если панель у вас на 127.0.0.1 и порту 48888, то сделав
ssh -L 8080:127.0.0.1:48888 user@serveradd -p <ssh_port>
вы сможете попасть на панель пройдя браузером по адресу http://127.0.0.1:8080.
Источник. Прим: из РФ не открывается. - Всегда стоит, чтобы быть на шаг впереди цензоров. Кроме того, стоит их тоже сейчас поднять, чтобы разобраться и сразу же был резервных канал на очень чёрный день. Ну это для совсем уже параноиков, типо меня.
- Если вопрос про VLESS+Reality, то надо установить Packet Encoding в xudp на клиенте. У меня, по крайней мере, в NekoBox работает, но только в TUN режиме.
- У меня сервер на XRay, клиент на sing-box. Не знаю, говорили раньше, что клиент на xray глючнее.
this Ъ
всё как miracleptr завещал)
Всё так. Прочитал все его статьи по обходу блокировок. Именно с них и начал заниматься этой темой. Спасибо ему большое за это. Жаль, что он тильтанул и больше не пишет.
- Лучше развернуть свой, чтобы как меньше зависеть от других
- У Namecheap бывают очень выгодные предложения в определённых зонах. Лишнего не спрашивают, оплату криптой принимают.
- Очень просто. В конфиге Inbound’а в строке listen прописываем 127.0.0.1:порт. Порт указываем тот, на котором работает собственный сайт. Можно как-то сделать, чтобы веб-сервер и Xray работали на одном 443 порту, но я пока с этим не разобрался.
Можно навесить nginx на порт и делать распределение трафика на этапе stream по доменам (preload)
А более подробнее можно для тех, кто не имел дела с nginx? Я просто про него знаю, что он скажем так аналог IIS на винде, только более лучше на линуксе.
Не очень разбираюсь в теме, сисадмин по принуждению поляется. Настраивал свой сервер по Васян-гайдам, но вроде дыры закрыл. Волнует теперь только проблема как раз таки “маскировки”. Тема вроде уже есть, создавать свою не хочу, Задам парочку (возможно глупых) вопросов здесь:
Перебрал утилитой рейндж айпишников (он под конец начал сыпать тем, что подключиться не может, оставлял на ночь, думаю там уже все) - в ответ получил кучку сайтов сомнительного содержания. Смущает меня, конечно, факт того что я буду стучатся к какому-то случайному серверу с траффиком трубы, не странно ли это будет? Или еще одна особенность, сайты которые я находил это регион Саудовская Аравия и Турция. В Турции, как известно, не работает Дискорд, например, что просиходит в Аравии мне представить страшно, если честно. Влияет ли это вообще как-то? Или лучше вообще дальше сидеть на www.amazon.com и не занимать себя лишними делами? Хотя я слышал и что-то про ужасы того, что, мол, распознают что я в Нидерланды хожу а не на местный цдн…
Плюс, где-то читал что для “достоверности” нужно открывать/закрывать порты примерно так же как и у домена, под который я маскируюсь. Это как вообще делается? Через хостера? Локально, на машине? Я за всю свою жизнь только для серверов в Майнкрафте порты открывал.
А вообще мне кажется что я параноией зазря занимаюсь, но все равно, как-то неспокойно. Буду благодарен за любые наводки.
я буду стучатся к какому-то случайному серверу с траффиком трубы, не странно ли это будет?
Нет, не странно, потому что трафик Youtube будет зашифрован по HTTPS. Насколько я понимаю, снаружи он выглядит как просто какой-то валидный трафик HTTPS до вашего сервера, который прикидывается некоторым сайтом. Если цензор почему-то заподозрит неладное и захочет проверить к какому серверу вы подключаетесь (так называемый active probing, если я не ошибаюсь в терминологии, я не настоящий сварщик), то просто обнаружит на вашем сервере сайт, под который вы маскируетесь, с валидными сертификатами.
Т.е. для цензора это будет выглядить так, что вы просто активно сёрфите сайт маскировки.
Или еще одна особенность, сайты которые я находил это регион Саудовская Аравия и Турция. В Турции, как известно, не работает Дискорд, например, что просиходит в Аравии мне представить страшно, если честно. Влияет ли это вообще как-то?
Это зависит от расположения вашего сервера. Если он расположен в Турции или Саудовской Аравии, то это проблема, так как их местные блокировки будут влиять на ваш тарфик. Лучше не выбирать сервера в таких странах.
Сайты, найденные с помощью RealiTLScanner, просто расположены в сети того же хостера, что и ваш сервер. Маскировка под них просто добавляет правдоподобности.
Или лучше вообще дальше сидеть на www.amazon.com и не занимать себя лишними делами? Хотя я слышал и что-то про ужасы того, что, мол, распознают что я в Нидерланды хожу а не на местный цдн…
Отвечу цитатой из гайда по настройке VLESS+Reality:
Очень важно, не использовать крупные сайты в качестве DEST/SNI*
Множество крупных сайтов имеют CDN в стране, поэтому их использование не рекомендуется (это например касается Google и других крупных игроков, хотя Microsoft в 22 году отключила CDN в РФ).
Ведь если у сайта есть сервера в стране, то с точки зрения наблюдателя (цензора) в нормальных условиях, вы должны обращаться к локальным адресам внутри страны, а не выходить за ее пределы.
…
Никто и никогда, в здравом уме, не станет использовать Google в качестве dest.
Я в начале тоже сидел под маскировкой под крупный сайт. Каких либо блокировок своего сервера я не словил. Тут решать вам, какой уровень маскировки вам хватит.
Но на будущее лучше всё же маскироваться под сайт из сети своего хостера или вообще под свой сайт на том же сервере. Это повысит устойчивость вашего прокси к обнаружению и он прослужит вам таким образом дольше. Не надо будет менять IP или вообще хостера и настраивать всё заново, когда РКН научится выявлять такие случаи.
Плюс, где-то читал что для “достоверности” нужно открывать/закрывать порты примерно так же как и у домена, под который я маскируюсь. Это как вообще делается? Через хостера? Локально, на машине?
Сам я такой штукой не занимался, просто поднял повыше порт SSH и всё. SSH порт не удастся закрыть вообще, так как вам как-то же надо подключаться к серверу и администрировать его. Вроде бы видел совет добавить фильтрацию по IP-адресу в SSH, чтобы вы могли подключаться только со своих IP-адресов. Не знаю, насколько это увеличивает маскировку сервера, но безопасность точно.
Насколько я понимаю для начала вам нужно выяснить, какие порты открыты у сайта, под который вы маскируетесь. Для этого существует утилита nmap. Сканируете IP сайта с вашего локального компьютера, он вам выдаст список открытых портов. Скорее всего для сайта будут открыты порты 80/tcp под HTTP и 443/tcp и 443/udp под HTTPS. Их нужно будет открыть на вашем сервере и пробросить до целевого сайта. Сервер XTLS-Reality сам пробросит 443/tcp-порт, так что вам останется только пробросить 443/udp и 80/tcp вот так:
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 443 -j DNAT --to-destination fake_site_ip:443
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination fake_site_ip:80
где fake_site_ip – IP-адрес сайта, под который вы маскируетесь; eth0 – сетевой интерфейс сервера. IP-адрес сайта можно отрезолвить с помощью nslookup, ping или какого-нибудь онлайн-сервиса, например вот этого.
Прим: Правила iptables не сохраняются после перезагрузки сервера, поэтому их нужно как-то сохранить на постоянке. Это можно сделать через firewall, например ufw или с помощью пакета iptables-persistent. Лучше посмотреть, что подходит для вашего сетапа и дистрибутива Linux.
Поправьте меня знающие люди, если я где-то накосячил.
А вообще мне кажется что я параноией зазря занимаюсь, но все равно, как-то неспокойно.
Надейся на лучшее, а готовься к худшему.
Огромное спасибо за такой развернутый ответ! Готовимся и правда к худшему.
Немного наводящих:
Насчет “странности”. Про то что значит последняя буква в HTTPS я знаю (zashifrovano, ага). Проблема не в самом траффике, а скорее в его объеме. Ютуб, как известно, это по несколько гигабайт под видео, некоторые по-длиннее так вообще десятки. А тут, получается, тонны инфы прилетет на какой-нибудь условный сайт турецкой клиники лечения ног (реальный сайт в моей подсети). Можно, наверное, подумать, что я фут-фетешист, но не настолько же… Но вот это уже скорее всего и есть та параноя.
Насчет блокировок: сервер находится в Нидерландах. Сглупил немного, потому что как-то и не подумал о том как вообще протокол работает. Но если и правда это только для “правдоподобности”, то действительно не особо важно.
ссшку сам поднял в небеса, к этому всему добру поднял аутентификацию по ключам, думаю пока этого хватит… пока.
Будем разбираться. Ещё раз спасибо.
Проблема не в самом траффике, а скорее в его объеме . Ютуб, как известно, это по несколько гигабайт под видео, некоторые по-длиннее так вообще десятки. А тут, получается, тонны инфы прилетет на какой-нибудь условный сайт турецкой клиники лечения ног (реальный сайт в моей подсети).
Я думаю, что это работает только потому, что проверка идёт в автоматическом режиме. Т.е. программа или “коробочка” цензора подключается к сайту, видит, что он валидный и не заблокированный и разрешает подключение к нему. Программа или “коробочка” не понимает содержание сайта, и что с этого сайта такие объёмы трафика очень сложно гонять. Это всё условно конечно.
С развитием алгоритмов цензурирования, введением новых эвристик или вообще нейросетей, конечно такие штуки уже скорее всего не прокатят. Но это очень затратно по вычислительным ресурсам, поэтому тут цензору нужно искать баланс.
Ну либо тупая ручная фильтрация трафика. Но фильтровать такие объёмы трафика вручную тоже проблематично, как вы понимаете.
Ндя. Страшно жить. Ну, пока можно и так, живем. Живем и надеемся…
Есть ещё port knocking. По умолчанию порт закрыт, пока не постучишься в другие в своей последовательности.
Чем больше ограничений, тем лучше 
Такую штуку хорошо проворачивать с дополнительным jump-host. Тут и белый ip будет для указания в настройках соединения ssh и дополнительная цепь для доступа к серверу
Интересно. Спасибо большое за информацию. Как найду время, потестирую.
Программа или “коробочка” не понимает содержание сайта, и что с этого сайта такие объёмы трафика очень сложно гонять. Это всё условно конечно.
Вот тут, как мне кажется, очень поможет свой собственный сайт и маскировка под него. Если скачивание тонны инфы с википедии, например, может выглядеть станно, то со своего собвстенного - вполне. Кто ж знает что там у тебя.
Надо еще придумать какой тип собственного сайта может много есть трафика, но при этом будет выглядеть безобидно. Собственный файловый хостинг за границей, с постоянным большим трафиком одновременно с нескольких ip…хз, тут главное еще и другие ведомства не заинтересовать:-D 
Но, мне кажется это задел на будущее. Хоть и есть пакет Яровой, но постоянный анализ трафика на соответствие сайту, имхо, ещё не под силу.
UPD
Как по мне, главное тут разношёрстность маскировки, чтобы было как можно меньше общих паттернов поведения прокси. Кто-то ставит свой сайт, кто-то ближайший по ip, кто-то что-то большое, но подальше и т.п.
Стоит изучать иные способы, да. Например REALITY + HTTP2, мультиплексацию (MUX), вообщем, не стоит держать все яйца в одной корзине
Насчет доменов, уже упоминали namecheap, домен вроде 456375.xyz (6 случайных цифр точка xyz) стоит $0.85/год (продление тоже). Также свободно гуглятся способы получить домен 3-его уровня бесплатно. Самое простое, что нашел - pp.ua, к CF привязывается, но сам домен может привлечь внимание кого не надо, это минус.
можно вообще не платить, бесплатно субдомен получить на FreeDNS например. Или палиться будет?
upd: а, ну да, не заметил
Также свободно гуглятся способы получить домен 3-его уровня
Бесплатные домены третьего уровня не делегировать, например, на Cloudflare. На счет палиться - не думаю что это сильно влияет, сервис же для того и существует, чтобы за домен не платить тем, кому он нужен для свиох проектов.
this, ява ще отсюда беру https://freemyip.com/ ток чёт он походу заблолчен, я хз как оно продолжает работать ваще 
(ns сервера походу не заблочены или прост мойи домемы уже везде закешировались)
…
ну вы тут конечн ребят замарочились я ваще не парюсь нис портом эсэсаша нис содержанием сайта мамскирововчного, ну заблочат да и х с им другой подыму, ето всё все равно не панацея кокда происходят какието беспарятки они прост блочат трафик за границу и всех дел
яду маю тут начнётся интересное кокда они начнут блочить понтсети хостеров которые не из ихнего реестра (амы к етому придём я думайю) ну или прост натренеруют свои нейронки чтобы айпишник сопостовлял по whois’у если пренадлежит какомуто вася-хостеру то блочить и всех дел
а зачем SSH закрывать? В чем палево? Разве сайты под которые идет маскировка, их сервера не имеют открытого SSH?
Закрывать порт нужно от сетевых сканнеров, так как даже поднятый в небеса порт SSH эти сканнеры вполне находят. И тут я думаю со стороны цензора может применяться следующая эвристика: если на сервере есть открытый SSH порт, то есть вероятность что это не оригинальный сайт, а маскировка под него. Естественно, это не достоверная информация и должно найтись ещё что-то, что скомпрометирует ваш сервер. Думаю, что это одна из “улик”.
Насчёт того, открыты ли SSH порты у оригинального сервера сайта или нет, это хороший вопрос. Я никогда не админил сайты и не знаю их стандартных практик по поводу администрирования: закрывают они SSH порты или нет. И если закрывают, то каким образом тогда получают доступ к серверу для работы на нём.
Поэтому я думаю и существует рекомендация просканировать оригинальный сайт на открытые порты. Если у него есть открытый порт SSH, то это нам как нельзя кстати. Просто вешаем свой SSH на такой же порт, и вот наш сервер мимикрирует гораздо правдоподобнее.
Если говорить про практическую полезность этих действий, то я думаю, что эти предосторожности по портам и прочие заморочки направленны не на текущую цензуру (я ещё не слышал про блокировку серверов с открытыми SSH портами или с не проброшенными портами 80/tcp и 443/udp до оригинального сайта, по крайней мере в РФ), а условно на завтрашнею.
SSH лучше закрыть белым списком своих адресов. В крайнем случае, попасть на ssh можно через тот же vless. Либо можно войти в консоль через панель хостера.
Тут могут быть сложности:
- Сталкивался сам и видел вопросы других к тех.поддержке хостера на предмет авторизации через консоль в панели. Похоже что консоль в панели хостера не корректно воспнинимала вставку определенных символов пароля (при этом из локального терминала авторизация проходила).
- Авторизацию по паролю скорее всего лучше отключить, есть ощущение (возможно ошибаюсь), что консоль в панели хостера не сможет получить доступ к ключу.
Возможно проще перед завершением сессии SSH останавливать SSH сервис?
При очередной перезагрузки VPS, SSH сервис будет автоматически запущен.
абсолютно согласен, даже больше скажу, обычный HTTP over TLS прокси так же прекрасно работает, провайдер так же видит обычные TLS соединения к домену, отличие от Реалити, нужен свой/бесплатный домен с сертификатом и все.
Для простоты, можно через Proxerver поднять такой прокси сервер
Сканирую диапазон зарубежного хостера и наткнулся на зеркало rutube. И вообще много отечественных сайтов попадается.
Это нормальная идея под него замаскироваться? Если нет, то почему?
Это точно зеркало или чей-то reality? )
UPD: действительно, имеется rutube.com, и он в Германии
inetnum: 185.53.177.0 - 185.53.177.255
netname: DC-Germany
country: DE
Ай-яй-яй )
По 4 пункту, если делать не как в идеале, то хотя бы можно если дома статичный IP, через UFW разрешить доступ к порту вебморды только с вашего IP, но в отличии от способа который в идеале, всё равно цензорам будет видно соединение на порт, на который у всех остальных доступа нет, что возможно будет подозрительно
А вообще UFW классная штука которую многие как будто упускают из вида, но перед тем как её включить надо конечно не забыть все порты прокинуть которые нужно что бы торчали наружу)
Ну настройки файервола на сервере - это то, что стоит делать всегда.
Ещё есть всякие мелочи, типа работа под новым не root пользователем, отключение авторизации в root через SSH и использвание RSA ключей вместо паролей. Довольно хорошо база по настройке всего этого есть в гайде по Xray. Всё это не относится к проксированию, а просто повышает безопасность вашего сервера.
Хотя это не сильно кричично на обычном прокси сервере, который используется для просмотра картинок “котиков” в инстаграмме, который не жалко потерять.
Ну кстати, работает, пока не мере на двух серверах, на одном чет не заводится )
Первая ссылка в третьем пункте заблокирована, может есть аналоги данной статьи?
Добавь habr.com в маршрут для проксирования (ты же как-то пишешь на заблокированном сайте?) и внезапно увидишь статью.
Пишет, что статья удалена из публичнчого доступа, с ВПН и захожу своего
Статья на своем месте, просто вы плохо заходите. Версия из веб архива от конца февраля с непокусанными комментариями.
Спасибо
Добрый день, правильно ли я понимаю что для проброса 80 и 443 нужно nginx устанавливать ? В самой 3x панели не нашёл способа чтобы заставить пробросить её 80 порт без спецификации протокола.
“port”: 80,
“listen”: “0.0.0.0”,
“protocol”: “vmess”,
“settings”: {
“clients”:
Нет. Это делается на уровне iptables или всяких файерволов, типо ufw.
В моём сообщении вроде всё написано, даже команды даны, которые проброс делают.
И ещё, зачем пробрасывать 80 порт самой панели? Вы что хотите этим добиться? Возможно, я вас неправильно понял.
Если на сервере стоит только панель (фаерволов нету), оно же не будет работать, нужно сделать чтобы серв этот порт слушал ? По дефолту панель только 443 порт смотрит, не ?
Сделал по вашему гайду предварительно открыв порт, не фурычит
По дефолту панель только 443 порт смотрит, не ?
Я не эксперт в панелях, никогда их не использовал. Вы сейчас говорите про саму панель или про сервер xray или sing-box, которые конфигурируются через эту панель?
Ситуация такая - есть свой vps, на котором установлена только панель.
Смотрел на открытые порты, был открыт только 443, который сама панель открывает по дефолту для своих нужд.
Прочитал ваш гайд о переброске, почекал сайт под который маскируюсь - на нём открыт 80 порт.
Поэтому с помощью iptables настроил сначала открытый порт 80, потом по указанной команде написал прероут. Но порт так и показывался закрытым. На мой вопрос чат жпт ответил что не достаточно просто открыть порт, нужно заставить веб панель его слушать (3x / nhginx/ кади и тд). Поэтому в самой панели в джейсоне указал открытый 80 порт. После этого порт показывался открытым (проверял веб сервисами), но прероут всё так же не работает по какой-то причине. Возможно нужно FORWARD вместо INPUT, прошу прощения я не особо шарю за сети (вообще не шарю)
Уберите prerouting. Если вы повесили панель на 80 порт, то она и так должна быть доступна, т.к. внешний ip находится на вашем сервере.
В xray или sing-box указывайте 443 порт, и домен для маскировки.
iptables вам нужен только для того, чтобы прикрыть лишние доступы, желательно ssh и панель.
Цель этих махинаций - отправлять все запросы по 80 порту на сервер под который маскируюсь, тут нужен прероутинг ?
Подскажите пожалуйста как протестировать что запросы по 80 порту уходят на сервер под который маскируюсь.
Мое мнение, открывать такие же порты как и на подставном сайте, бессмысленная затея. Если например сайт в кластере, и на каждом сервере открыты разные порты, это нормально, и ещё не повод подозревать что за каким-то адресом находится прокси. К тому же, active probing’ом ркн пока не занимается.
Если вам так сильно хочется заморочится, то вашу панель нужно перевесить на другой порт, т.к. 80 вы редиректите. Считайте, что он занят.