Обновить
3
0

Пользователь

Отправить сообщение

Да, с некоторыми банками такое работает. Но есть и свои риски. Некоторые банки/брокеры совсем недавно начали рассылать запросы подтверждения резидентства. Причем принцип выборки для писем счастья пока не понятен.

И к сожалению, глобально это проблемы не решает, т.к. многие сервисы все чаще начинают сверять IP-адреса (при этом блокируя аккаунты если видят авторизации с VPN/proxy/IP датацентов), и геопозиции (это пока больше про приложения).

Некоторые же, увидев выписку из российского/санкционного банка просто закроют аккаунт на всякий случай.

Давайте разберемся с терминологией. Мультиплексирование - это когда клиент группирует несколько потоков в один TCP-коннект - в итоге немного падает максимальная скорость передачи (если канал плохой, то может и сильно упасть), но ускоряется установление новых соединений.иЯ как-то слабо вижу, как оно может коррелировать с количеством людей на сервере

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

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

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

и ещё если у вас на сервере Sing-box, а на клиенте XRay, то не будет работать XUDP (могут быть проблемы со звонками в месседжерах).

С обратной ситуацией (Xray сервер, Sing-box клиент) такой же расклад?

А что конкретно интересует? Для Reality (и вообще чего угодно использующего Vision) мультиплексирование обычно не применяют. А вообще в Sing-box с мульиплексированием все очень неплохо, есть несколько вариантов (smux, h2mux, и т.д.), одно НО - его алгоритмы мультиплексирования не совместимы с алгоритмом из XRay, так что если у вас на сервере sing-box, то для рабочего мултиплексирования на клиенте тоже должен быть sing-box.

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

А про ядро, вижу что большинство серверное XRay используют, но Sing-box клиентское больше нравиться, есть мысли на него и на сервере перейти. Пока минусов не нашел. Или есть они?

Как вариант, если включен IPv6 - выключить IPv6 в прокси, или наоборот, попробовать его использовать. Второй вариант - заворачивать весь трафик с прокси на Cloudflare Warp - гугл и прочие OpenAI будут очень довольны.

Спасибо, IPv6 пробовал - проблемы не решило. Скорее сервер с чистыми возьму. Хотя скорость на Hetzner хорошая.

WARP-модуль в 3X-UP видел, но разраб X-UI вроде напротив писал, что у него не будет, т.к. больше проблем с ним. Или есть смысл на клиенте домены туда заворачивать (NekoBox вроде профиля в один клик поддерживает, но роутинг самому нужно настраивать)?

Да, хочется именно как альтернативу рассмотреть. Там принцип разработки интересен - постепенно но достаточно быстро разрабатывают новые версии исходя из практических векторов атак и готовы рассматривать допфишки на будущее. Учитывая участившиеся блокировки Realty в Иране (пока есть подозрение что по аномальным объемам трафика либо количеству коннектов вычисляют подозрительные узлы, а далее эктив пробингом что-то делают, что грузит CPU на 100%) особенно интересно.

P.S. Как обстоят дела с мультиплексированием в Sing-box и если ли смысл переходить на это ядро на сервере (учитывая использование клиентов в основном на этом ядре)? С точки зрения скорости разницы с Xray не заметил вообще, но на достаточно мощном железе тестировал, возможно на слабых машинах дело обстоит иначе.

И еще может кто в курсе, у Hetzner все сети имеют плохую репутацию в Google и как следствие капчу в 10 итераций почти на любой запрос или только на конкретные IP-адреса? Проверил на парочке случайных, все печально, но выводы делать рано, т.к. не повезло и оба па базам как открытые прокси детектятся (вероятно что-то там когда-то было на них у предыдущих арендаторов).

Вопрос не по теме, но может кто уже пробовал ShadowTLS v3?

https://github.com/ihciah/shadow-tls/blob/master/docs/protocol-v3-en.md

В sing-box поддержка есть - https://sing-box.sagernet.org/configuration/outbound/shadowtls/

Интересует прежде всего стабильность работы и поддержка со стороны клиентов (из коробки завести в связке с SS2022 пока не удалось, но подробно еще не успел мануал прочитать).

Спасибо, разобрался. Не выспался и в SNI ошибку допустил. Порты на всякий случай проброшу.

Про запущенный веб-сервер (с дефолтной страницей Апача с логитипом Убунты из /var/www/html/index.html) возможно у конкретного хостера такая сборка, т.к. массовых жалоб на ошибку занятого 80 порт при установке сертификатов с запуском им временного веб-сервера не вижу. Позже посмотрю как оно у других хостеров.

Аналогично. У вас Reality на 443 порту (HTTPS), соответственно при любых запросах к этому адресу реагировать он будет точно так же, как и оригинальный сервер - в том числе в плане выдаваемого по HTTPS контента.

Если пробросите фаерволом 80-ый порт - то и по HTTP будет реагировать аутентично.

Да, но если попробуют без SNI, просто по реальному IP-адресу CDN-сервера зайти тогда получаем что некоторые CDN отдают страницу типа "я сервер CDN номер NL-1000500", а по IP Realty-сервера "домен не найден на нашей CDN или заблокирован".

Я понимаю, что можно придумать еще множество способов палить Realty, в т.ч. пассивных, по количеству коннектов, статистических и пр., но вот это прям в глаза бросается.

Это не имеет отношения к Reality (кроме варианта steal from yourself) - в чистом Reality вообще никак не задействован веб-сервер на вашем VPS, его там вообще не может и не должно быть.

С удивлением обнаружил такое поведение на инсталлах Ubuntu с 3X-UI, X-UI и Marzban.

Поменял index.html /var/www/html и подробно в причинах не разбирался.

Понятно, что это не имеет отношения к самому Realty.

Т. к. при запуске certbot с опцией --standalone еще до установки панели он ругался, что 80 порт уже занят, это намекает что на новых установках Ubuntu уже запущен вер-сервер. Чистая система Ubuntu 22.04 LTS.

Не знаю, это только на образах у отдельных хостеров, или стандартная ситуация для Ubuntu, что веб-сервер по дефолту запущен и дефолтную страницу Ubuntu отдает. Если второе, то подозреваю, что мало кто проверяет это, а палево сильное.

Да, пойдет без шифрования. Имейте в виду, что VLESS без TLS шифрования использовать не надо.

Если не доверяете промежуточным узлам или промежуточной CDN (если она есть) - то используйте с вебсокетами VMess. И не забывайте про early data.

Внутренний первекционист воротит нос от VMess.

В Marzban видел Trojan-ws среди дефолтных пресетов. Но про Trojan подробно не читал. Есть смысл?

Или лучше для вебсокетов тот же VLESS c TLS настроить?

P.S. Еще заметил странное поведение, что если в Realty настройках (3)X-UI мимикрируем под домен domain1.zone, который ссылается через CNAME на domain2.zone, почему-то Realty-сервер пытается мимикрировать под domain2.zone, используя его SNI.

  1. Как выбрать сервер, по который маскируемся в Realty? Критерии помимо того же хостера / пинга. Ведь на самом деле, Realty цензору легко спалить, как минимум:

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

По PTR. Далеко не все хостеры разрешают его менять.

По IP Whois. Если все IP домена например от какого-то CDN, а у вашего в WHOIS другая ASN другой компании.

По контенту. Многие CDN отдают несколько разные страницы, если видят, что домен к ним не привязан. Это если зайти по IP. Решается поиском таких, которые по IP реджектят коннект, а их мало. Или отдают статичную страницу, которую мы можем скопировать себе на сервер .

По разнице контента http / https. Там несколько тонких моментов, которые могут сыграть в разные стороны, в зависимости от алгоритма атакующего.

Кстати часто после установки оставляют стандартную index.html от Ubuntu, которая отдается по айпишнику, по http. Это прям совсем палево.

  1. Какой протокол разумно выбрать под Websocket транспорт? Если VLESS без Vision / галочки TLS в Security 3X-UI - пойдет без шифрования? По опыту обхода корп. фаерволов критичен ли порт и что важно?

@Stanner это тонкий намек, что странно бороться с блокировками в РФ, но советовать покупать домены в РегРу.

В компании, которая:

  1. с некоторых пор принадлежит специально назначенному порулить доменами Рунета самизнаетекем человеку;

  2. всячески поддерживает "суверенитезацию" интернета, обязательный СОРМ для РФ хостеров с 1 декабря (а другой рукой рассылает им предложения купить их бизнес за копейки, пока не поздно) и пр.;

  3. успех бизнеса которой и при старых владельцах напрямую был связан с ЕР и которая использовала админресурс в бизнесе.

Спасибо за статью, как раз в дополнение с 3X-UI c Shadowsocks-2022 и VLESS-Realty (боевая система) и X-UI/Marzban (там все остальное для тестов всякие Trojan, VMESS и пр. с gRPC / Websockets / mKCP транспортами) хотел поиграться c Hiddify-Manager и Hysteria2.

Но какие плюсы по сравнению с SS-2022 в РФ?
QUIC массово блокируется, а с доп. обфускацией OBFS теряется сам смысл - выглядит так же, шифрованный поток данных, непохожий ни на что.


И недавние события в Дагестане, показали, что такое полностью блокируют (там блокировали только TCP, но и с UDP провернуть это несложно).

По скорости / загрузке на слабом железе есть приемущества?

Пока остановился на XRay с SS-2022 и Realty для боевого применения, в планах еще вебсокеты через CDN добавить.

UPD. С сертификатами у них очень удобно сделано из коробки, в 3X-UI хотели подобное сделать, но там свой путь.

А домены можно по 0.55 в regway брать в неограниченных количествах (и крипту и карты РФ и ЯД принимают), дешевле нигде не видел.

Потому, что эта деталь Made in UA.

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

Маркировка "бытовых" газовых баллонов никакого отношения к маркировке деталей космической технике не имеет.

Примеры. Хвостовая части разгонного блока "Бриз-М" (со снятой теплоизоляцией):

Бриз-М
Бриз-М

Никакой цветовой маркировки ни на шаровых баках высокого давления (алюминиевого цвета) для компонентов топлива, ни на титановых шаробаллонах для гелия (темно-золотистого цвета) нет.

Найденный на Багамах в прошлом году (с очень большой долей вероятности, от американской ракеты Antares), никакой цветовой маркировки также нет:

Багамы, 2021. Antares
Багамы, 2021. Antares
Багамы, 2021. Antares
Багамы, 2021. Antares
Бразилия, 2012. Предположительно, Ariane-4,
Бразилия, 2012. Предположительно, Ariane-4,
Намибия, 2011. Предположительно, Союз-У.
Намибия, 2011. Предположительно, Союз-У.

Шар-баллон высокого давления.

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

Шар-баллоны могут использоваться для разных целей, в т.ч. для компонентов топлива.
Но конкретно в этом вероятно был гелий или азот, которые могут использоваться для питания двигателей малой тяги, ориентации и стабилизации, привода клапанов автоматики (и не только - может широко использоваться как надежный "механический" аналог АКБ), компенсации давления в баках и пр.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность