VLESS REALITY: TCP handshake проходит, а payload - нет. Обнаружение vless трафика?

Internet censorship all around the world Russia
1

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

Инфраструктура — Remnawave + Xray. Сейчас Xray 26.7.28. Основной протокол долгое время был VLESS + reality + xtls-rprx-vision, обычный RAW/TCP. Параллельно начал разворачивать Hysteria2 + Gecko на UDP.

Ноды находятся у разных хостеров в разных странах: были случаи с Польшей, Эстонией и США, сейчас похожее начинается на свежей Финляндии. (Азия на удивление живёт как и раньше)

Типичный сценарий следующий.

Сервер после установки какое-то время работает нормально. Потом с некоторых российских подключений перестают нормально устанавливаться новые сессии. При этом сам сервер не мертвый: ping, ssh, SYN → SYN/ACK → ACK, порт снаружи доступен, панель видит ноду конечно же, часть клиентов продолжает работать, до переключения, ну тут в целом ясно почему.

В логах xray рисует:

REALITY: processed invalid connection from <CLIENT_IP>:<PORT>:
failed to read client hello

Самое интересное видно в tcpdump:
CLIENT → SERVER SYN
SERVER → CLIENT SYN/ACK
CLIENT → SERVER ACK
CLIENT → SERVER 1396 bytes
SERVER → CLIENT ACK 1397

После этого продолжения ClientHello на сервере уже нет. Клиент создаёт следующее соединение и повторяет то же самое. На сервере при этом Xray пишет failed to read client hello. И так в цикле и идёт. Просто обрезка после которой хэндшейк падает.

Если тестить просто на TCP порту без чего-либо через ncat, подключаешься, всё ок, пишет что Connected, на обоих сторонах всё ок. Но если внутри подключения попробовать отправить просто текст типа TCP_HELLO - ничего на ноде не появляется.

В общем проводил различные тесты, смотрел вайршарк, читал логи - пакеты просто режутся по пути, TCP или UDP, неважно.

Конечно же пробовал всё, фингерпринт, SNI, всякие добавки типо finalmask (во всех реализациях), sockopt и тп.
Более того, на проблемной ноде пробовал вообще VLESS RAW/TCP без REALITY/TLS (security:none). Симптом с TCP тоже сохранялся. Поэтому проблема явно не сводится исключительно к fingerprint reality ClientHello.

Далее пробовал hy2 + gecko / salamander. Свежая FIN-нода сначала работала нормально, но буквально на следующий день тоже начала работать нестабильно/через раз. То есть HY2 в моём случае пока не оказался универсальным решением проблемы.
В итоге на каждой ноде сейчас планирую держать одновременно:
TCP/443 → VLESS REALITY Vision
UDP/443 → Hysteria2 Gecko
Или вообще свой сайт-заглушку на ноду для vless + оба протокола. В общем вариантов уйма, а выхлопа - ноль.

Очевидно, если IP обнаружен как враг народа, делать особо нечего, кроме как крутить на новый, но нельзя же каждый день этим заниматься.
Есть ли смысл дальше пытаться маскировать прямой клиент → зарубежная нода, если уже обычный plaintext TCP_HELLO после успешно установленного TCP иногда не проходит.
Особенно интересен опыт с RU bridge. Теоретически тогда для провайдера пользователя соединение заканчивается на российском IP, а международный участок уже становится DC → DC. Помогает ли это сейчас на практике? И в чём опасность вообще аренды впс в рф для какого либо впна на нём.
Ну и если есть другой транспорт/архитектура, которая лучше переживает подобное поведение?

Буду благодарен за направление, особенно пальцем, куда копать, а то уже устал над хладными телами нод сидеть.:smiling_face_with_tear:

4

Помогает

Опасность такая же, как и при использовании vpn с зарегистрированной на вас симки/домашнего инета.

Можно сделать self-steal, через reality xhttp или vless xhttp

5

Благодарю, про self-steal почитаю.

По поводу нод в рф слышал только за отключение без возврата шекелей и вероятно бан акка. Много тряски было по поводу того что рф хостеры мол отслеживать должны.
Сегодня ещё мысль посетила, использует ли кто то мост через Казахстан или Беларусь? А то инфы по этому поводу ни разу не видел, а так вроде сразу двух зайцев хапаешь, и за безопасность/законодательство и за доступность. Или ркн в сторону стран СНГ тоже банит?

6

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

ты бы еще голый gre-тунель поднял бы, чтоб наверняка в бан отлететь.

7

Продаваны тоже нужны, без них люди, далекие от IT, не смогли бы получить доступ в открытый интернет за условные 10$ в месяц. А обижаться в данном случае имхо нужно только на себя, ведь брать VPS под self-hosted VPN при текущей вандальной политике РКН надо исключительно у тех хостеров, у которых в TOS явный запрет на публичные VPN.

10

А с чего ты решил что у меня открытый впн? Я ремну использую только из-за удобства, та же x3ui вообще не зашла. У меня в нём людей немного, близкий круг. И откуда ты взял про “ноды раскатывать”, “денег дофига”? Пока что тут только ты плачешься, за продаванов.

12

Ты идешь по какому-то сложному пути, тебе нужно сделать так, чтобы не палился входной адрес твоей ноды. Делай цепочку из двух нод (можно в качестве выходной взять уже дохлую), либо выводи весь трафик через WARP. Далее, на входной ноде не должно торчать никаких панелей и странных портов, всё убрано за нжинкс на tcp/443, закрыто роутингом по SNI. Желательно не воровать домены от CDN, там палево при сканах

13

В основном всё так и делаю, разбочий 443, до панели порт только в IP панели открыт.
Вот тут как раз и вопрос главный, какой мост брать, РФ или в целом страны снг типо Беларуси и Казахстана.

14

Если подключено мостом через РФ, то нет, нельзя. Дохлые айпи отлетают очень мощно и последняя волна банов 21 сентября это подтвердила

45.149.234.85 - один из забаненных айпи, на check-host можно убедится, что к ssh коннектятся все ноды, кроме российских (иногда коннектит спб, там криво работает тспу). Но если проверить этот же айпи на globalping io по http, то абсолютно 90% ру нод (как минимум вся москва включая яндекс клауд, cloud ru, timeweb и т.д) уйдут в тайм аут, на деле же должно вернуть просто connection refused т.к 80 порт там закрыт.

check-host

image

globalping

image

16

Мост в рф это не мост, это максимум хаб для удобства администратора. Тебе нужно именно две зарубежные ноды, без разницы где они расположены (но лучше наверное поближе друг к другу просто чтобы задержка была поменьше). Входная нода ничего не выпускает в директ, только форвардит на выходную. Вторая может быть уже забанена РКН - без разницы, к ней все равно не будет прямых подключений из рф

17

Если ты о том что с дохлой ноды не будут доступны какие то РФ сервисы - то это решается маршрутизацией на клиенте.

18

Я про то, что сама выходная (дохлая) нода не будет иметь связь с мостом, если он находится в РФ. Очень жестко айпи банится

Я попал под волну 21 сентября в тот момент, когда в очередной раз настраивал cdnvideo и 2 часа тупил почему у меня не открывается даже пустой сайт и воввращает 502 gateway time out

19

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

20

Одна нода (на вход и на выход)

Скрепный софт на гаджете стучится сюда

https://redirector.googlevideo.com/report_mapping?di=no

Получает выходной IP = входной IP. РКН банит его, плати бабки, меняй входную ноду.

Две зарубежные ноды (одна на вход другая на выход)

Скрепный софт на гаджете стучится сюда

https://redirector.googlevideo.com/report_mapping?di=no

Получает выходной IP <> входной IP. РКН банит его, входная нода жива, всё продолжает работать.

Хостер для выходной ноды крайне желательно чтобы был уже забанен на территории РФ, выбор огромный и все они отличные: hetzner, ovh, buyvm, racknerd и прочие “счастливчики”. Чтобы не подставлять тех, до которых РКН еще не добрался.

21

С логикой понял, входной не светится как итоговый ip, весь выход идёт через выходную ноду.
Тогда остаётся вопрос по самому соединению клиент → вход. Что обычно используете на этом участке как протокол? Что в такой схеме защищает именно входную ноду от фильтрации (типо моей проблемы что описана в теме)?

22

А если входную делать на ру впс..использовать как напрмиер в Remnawave устроено,т е влесс нода-влесс нода. или обычным форвардиргом? Что менее палевно? или может через другой туннель делать связь какой

23

Я сторонник мимикрии, причем максимальной на стороне ноды. Т.е. как минимум отвечать на http заросы должен реальный веб-сервер с сайтом заглушкой, своим доменом (не обязательно платным) и валидным ssl-сертификатом от этого домена. В идеале с включенным hsts и отбрасыванием любых иных http запросов без корректного sni с именем вышеуказанного домена. Т.е. если бы я поднимал реальный сайт, то сделал бы именно так. А прокся находиться за ним и уметь работать в такой связке.

24

Любой балансировщик или веб сервер с возможностью l4 до заграничной ноды с ру ноды и все. Так и не надо мучаться с большим количеством конфигов xray, чтобы все на 443 порту было, и менее палевно, если хостера заставят прочекать, чё там на сервере.

25

Окей, буду тогда в эту сторону двигаться.
И всё таки, какой вариант туннеля можете посоветовать между клиентов и входной нодой? Я смотрю в сторону vless+xhttp+tls.
В любом случае, благодарю за объяснение.

26

к сожалению ваш селф стил dead on arrival, тк никто ваш домен никто не будет добавлять в белый список, а там 16кб блок. У меня именно так лег мой сервер в январе этого года. Вы полагаетесь на милостыню ркна и на то существует ли вообще белый сни для спуфа для вашего хостера через какой-то нибудь запрет? Например люди не однократно писали что до сих пор не могут найти белый сни для франтека как будто его и не существует вовсе