У меня свой домен и свои сертификаты, но работает через xtls. Если переключить на простой tcp-tls, начинается палево tls-in-tls и растет время отклика. Чтобы этого избежать, придется включать mux, а это ещё увеличивает время отклика и накладывает ощутимый оверхед, особенно при работе через транзитный узел. Нужна тонкая настройка таймингов в policy, иначе бывают отвалы длинных соединений, тех же ws
Здравствуйте примерно 30 апреля перестал работать vless настроенный через websocket cdn Gcore, смена доменного имени у своего сайта и SNI не помогли.
Непонятно толи блокировка TLS 1.3 идет, в Gcore пробовал принудительно выставить TLS 1.2 не помогло. Работало так все раньше с 2023 года.
Пока что заработало напрямую без CDN c reality и xtls-rprx-vision, вместо обычного TLS.
Непонятно толи CDN Gcore попал под блокировку, но про него никто вроде не писал что блочут, толи блочат TLS 1.3, а напрямую с xtls-rprx-vision работает как я понимаю потому что не используется стандартный TLS 1.3 ?
this. у меня любые сайты за ним не грузятся.
Это не связано с блокировкой tls 1.3
Курлом хендшейк проходит, с tls 1.2 и 1.3, а заголовки уже не грузит.
Да, именно это я и имел в виду говоря про “завернуть vless в ssh”. Более того, ssh уже шифрует весь трафик, так что VLESS внутри можно гонять и без TLS.
Я в этом деле только осваивающий, поэтому подскажите, чтобы использовать такую схему, необходим дополнительный VPS или это как-то на рабочей машине настраивается? И какой клиент, допустим, для включения того же TUN использовать? Да, рабочая машина - это Винда
Какой провайдер? Регион? Нашел какой-то github.ddnsfree.com, который смотрит CNAME-ом на *.gcdn.co. Скорее всего чей-то xray с fallback на github.com - нормально открывается с TLS 1.3. 1.2 не поддерживает сервер.
Во всяком случае fallback открывается, не знаю, что будет если идти туда xray-ем. МСК, Вымпелком.
*.gcdn.co. это gcore, теперь перестал открываться, gcore попал под блок.
Кстати, да. У меня тоже курлом хендшейк проходит 1.2 и 1.3, а именно панель x-ui не открывается и Vless+reality не подключается
примерно с 30 апреля или 1 мая. Ростелеком, впс на PQ. Но у меня была маскировка под microsoft.com, потом ign.com. Переделал позже маскировку на steal oneself, но видимо поздно уже, спалили)))
бан ко всей подсети сразу. ничего там не палили. просто сразу всю подсеть хостера в банлист добавили
Ну примерно как-то так
Спойлер
{
"serverName": "domain.name",
"rejectUnknownSni": true,
"allowInsecure": false,
"alpn": ["h2", "http/1.1"],
"minVersion": "1.2",
"maxVersion": "1.2",
"certificates": [
{
"certificateFile": "/path/to/cert.pem",
"keyFile": "/path/to/key.pem"
}
]
}
Там есть ещё опции, но они необязательные. Работать будет и так.
А настройки Nginx можно в доках глянуть. И вообще там много полезной информации есть.
У меня не reality, а пару лет стабильно работал xray-xtls-vision с сайтом заглушкой.
Сегодня перевёл на TLS 1.2 - на проводном интернете через раз стал открываться сайт заглушка, на мобильном - ничего не поменялось - тупо не работает.
Интересно, что параллельно был gRPC через WebSocket - перестало работать и на мобильном и с проводного.
Единственное, что работает на проводном: ShadowSocks2022 и Hysteria2
На мобильном: ShadowSocks2022 не работает, Hysteria2 - минуту ожидание коннекта - потом летает.
Какой-то жёсткий идёт DPI. Причем, как я писал выше, если добавить ByByDPI - все протоколы открываются и сайт заглушка также работает и на TLS 1.2 и на 1.3.
Провайдер: Vultr
Домашний интернет: Ростелеком
Мобильный: Т2 (Ростелеком)
Еще момент интересный - попробовал iperf3 подкинуть пакеты по UDP на тот же порт, что и Hysteria - всё работает. Т.е. DPI явно как-то определяет коннект по Hysteria.
Ростелеком. ДВ.
Я проверял основной сайт https://gcore.com. При чем, иногда курл пробивался до заголовков на обоих tls, а иногда даже до них не доходил, висел на Trying 92.223.84.84:443…
С github.ddnsfree.com тоже самое, только на tls 1.3.
Ну значит все же рубят не тупо все. Выходит, что как-то детектят? Тогда почему в некоторых случаях и заглушка попадает под блокировку?
Я тоже прихожу к такому выводу, тспу как-то научились/учатся детектить именно подключения к xray. Пока это обкатывают на сетях отдельных хостеров, но при успешной реализации начнут делать это на всем трафике за границу.
Судя по всему, похоже мощную на блокировку Cloudflare, начавшуюся в Сибири. А тогда отлетела и Amnezia (UDP). Это была очень странная и мощная блокировка. Не факт, что нацелена именно на xray, скорее на TLS. Возможно, белый или чёрный список протоколов. Трудно и ненадёжно пробивалась. Кажется, был белый список отпечатков сайтов.
Если говорить о блоке PQ Hosting.
Еще эксперимент на Hysteria на проводном и мобильном.
Если не включать обфускацию, то Hysteria не работает нигде - значит определяют QUIC сигнатуры и блочат.
Если включить обфускацию - на домашнем начинает летать, на мобильном через 3-4 минут пробивает и работает со сбоями.
Вывод: явно не тупо блочат, а сигнатуры и т.п.
Здесь никто упорно не пишет размер сайта-заглушки, хотя известно, что еще во время мартовского бана Cloudflare подключение обрывалось далеко не сразу, и сравнительно небольшие страницы иногда успевали пролезть. Тот факт, что почти все сообщения в этой ветке из серии “заглушка то загружается, то нет, то без картинок”, наводит на схожее поведение ТСПУ.
В моём случае заглушка - это ретранслятор на http действующий сайт, в котором и картинки и страницы есть. Всё тыкается и работает. Это не просто одна страничка. Просто на моей стороне http заворачивается в https, сертификаты LetsEncrypt
Дошли руки эту схему протестировать, все работает на текущий момент. Гнать дикий (относительно) объем трафика по ssh, очевидно, будет разрешено до поры до времени, но прямо сейчас оно работает. Выглядит схема предельно просто:
- Есть впска на PQ с до недавних пар рабочим reality. Просто так сейчас он уже не пашет. Никаких настроек в конфиге на ней с тех пор не менялось, вот просто как была до этого так и осталась.
- Берем некое устройство в локалке, в идеале роутер/любое linux устройство типо малинки, но и обычный ПК на винде вполне сойдет.
- Коннектимся с этого устройства к впске следующим образом (X и Y соответственно подставляем свои):
ssh -N -L 0.0.0.0:443:XXX:443 root@XXX -p YYY
Обращаю внимание что первый XXX нужен именно внешний адрес впски, локалхост не катит, по крайней мере у меня. - Меняем конфиг reality (на клиенте!) чтобы коннект шел к локальному адресу этого устройства (на винде соответственно будет локалхост).
- ???
- Profit. Пока ssh сессия жива, контакт есть. Сессия кончается (втч от закрытия терминала винды) - сказочке конец.
Конечно схема максимально топорная, но до конца срока аренды мерзкой PQ-шной впски должно хватить. Если есть возможность без лишних телодвижений это запустить на скажем малине - то можно вообще сделать красиво без всяких там лишних терминалов на каждом клиенте:
autossh
-M 0
-o “ServerAliveInterval 15”
-o “ServerAliveCountMax 3”
-o “ExitOnForwardFailure=yes”
-N
-L 0.0.0.0:443:XXX:443
root@XXX
-p YYY
и коннектиться соответственно к малина:443 со всех клиентов.