Такое бывает, когда на хостинге много впнов. У меня такая же причина, забанили не мой IP, а хостинги. Найти такие, которые принимают карты РФ, и не на карандаше у РКН, уже практически нереально.
Лучше искать те, которые НЕ принимают карты рф, и НЕ дают платить криптой. Минимум шансов попасть на хостера с рф хвостами. Покупаешь предоплаченную карту США за крипту и оплачиваешь.
Да, согласен. А также не крупные (уже под блоком) и не упоминавшиеся на этом форуме. И желательно их AS тоже пробить по сообщениям тут. В идеале вы должны быть единственным пользователем впн в своей подсети (фантастика, но к этому идёт, банят по популярности).
Ещё немного уточню, а то из контекста возможно не понятно.
Западный дедик с рдп доступом, по rdp протоколу доступ закрыт уже как несколько месяцев, раньше рдп проходил, теперь и он заблочен.
Веб-сервер HTTPS, создал самоподписанный сертификат на *.stackoverflow.com, чтобы не было 16кб блока, и есть ещё сертификат по обычному домену на Lets encrypt, на который 16кб блок, но обычно по этому домену даже не пытаюсь открыть сайт.
Если заходить с того же Chrome, то блок проявляется спонтанно, он то есть, то исчезает. На данный момент блок вернулся, и спустя пару минут, пока писал это сообщение, блок снова исчез и снова попадаю на сайт нормально.
Нет какой-то определённой схемы действий. На сервере нет никаких VPN и прочего, если только RDP доступ не считать впном, хотя через рдп и так зайти больше нельзя напрямую.
Транспорт TCP поддерживает, если убрать "flow": "xtls-rprx-vision". До обнаружения TLS-in-TLS ТСПУ ещё не дошёл по моим наблюдениям (а сам Reality он тем более не отличает от обычного TLS 1.3).
Да, я понимаю. Симптомы у нас с вами разные, мне весь https наглухо перекрыли, вам палки в колёса ставят в плане https и перекрыли RDP, но результат один и тот же - нужно либо менять хостинг, либо подключаться через промежуточный узел.
Есть ещё идеи тестов на следующую блокировку
GitHub - axel-download-accelerator/axel: Lightweight CLI download accelerator · GitHub умеет качать файл в столько потоков, сколько вы ему скажете. Да, отпечаток у него будет точно не хромовский, но раз смена отпечатка не помогает, значит есть шанс поймать блокировку по количеству соединений таким способом.
Я где-то тут видел и другой способ триггерить блокировку по количеству соединений, но не нашёл сейчас.
curl --parallel --parallel-max 50 --http1.0 -m10 -k -s --show-error -o nul -w "%{response_code}\n" "https://yoursite/bigfileornot?[1-50]"
Сегодня как минимум на мобильном Билайне в Петербурге явно что-то подкрутили. Из моих четырёх домашних серверов живым остался только один. Ради интереса прогнал через DPI Detector проверку на замедление хостеров и CDN — впервые из 108 адресов у 64 в колонке Alive стоит «Нет», статус — TLS Drop, а в деталях отображается TLS Handshake timeout. В Wireshark во время теста видно огромное количество retransmissions.
Если вдруг vps на хостере “сломалась”, то в первую очередь я пробую reverse (vless-овский или portal - не важно, транспорт тоже неважно - можно vless encryption на верхний порт). Но для этого нужно на своей стороне иметь принимающую часть (ядро) и белый адрес.
awg2.0 пробовали?
dns протокол тоже заблочили? иранцы в самое жуткое время смогли пробиться через udp/53 и местные днс через dnstt когда положили весь https. у нас можно через нсди попробовать, но как болван говорил - вы лезете в пасть к зверю, но если у вас действительно ничего не работает (в чем я сомневаюсь), то только так
Не вижу ни одного xhttp и классического tcp reality
Руки тут не причем.
днс тунели работают
Жаль, что уже не отредачить первоначальное сообщение. Вот мой конфиг
Конфиг Nginx
server {
server_name xxx.ru;
listen 0.0.0.0:443 ssl;
listen [::]:443 ssl;
listen 443 quic;
listen [::]:443 quic;
http2 on;
http3 on;
quic_gso on;
index index.php;
root /.../html/;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:AES256-GCM-SHA384:AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_certificate /etc/letsencrypt/live/xxx.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/xxx.ru/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/xxx.ru/chain.pem;
ssl_early_data on;
…
location /123123 {
client_max_body_size 0;
grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_body_timeout 5m;
grpc_read_timeout 315;
grpc_send_timeout 5m;
grpc_pass unix:/dev/shm/xrxh.socket;
}
…
Конфиг xray
{
“log”: {
“loglevel”: “warning”
},
“inbounds”: [
{
“listen”: “/dev/shm/xrxh.socket,0666”,
“protocol”: “vless”,
“settings”: {
“clients”: [
{
“id”: “…”,
“level”: 0
}
],
“decryption”: “none”
},
“streamSettings”: {
“network”: “xhttp”,
“xhttpSettings”: {
“mode”: “stream-one”,
“path”: “/123123”
}
}
}
],
“outbounds”: [
{
“protocol”: “shadowsocks”,
“tag”: “western-vps”,
“settings”: {
“servers”: [
{
“address”: “100.100.100.100”,
“port”: 443,
“method”: “2022-blake3-aes-128-gcm”,
“password”: “…”
}
]
}
}
]
}
Конфиг подключения
vless://xxxxxx-yyyy-zzzz-nnnn-tttttt@xxx.ru:443?encryption=none&security=tls&``sni=xxx.ru``&alpn=h3&insecure=0&allowInsecure=0&type=xhttp&``host=xxx.ru``&path=%2F123123&mode=stream-one#Connect
Вроде бы всё правильно, по уму сделано, и по последнему тренду xhttp и http3. Но всё равно палит и блочит на некоторое время доступ с серваку. На несколько минут вроде бы, по всем портам, даже по 22 порту не достучаться. Сбросить блокировку можно включением режима самолёт (чтобы IP сменился) на мобильном интернете. Так вот и мучаюсь, блокировка может возникнуть и через 20 минут, и через минуту, не могу понять алгоритм. А может просто и не замечаю, как блокируется и разблокируется, особенно при просмотре Ютуба, благо там же буферизируется порой прилично видео.
И да, блокировка персональная на соединение. Если в этот момент попытаться открыть сайт с другого провайдера и\или проверить доступность через ping-admin, то всё работает.
И да, есть подозрение, что это какая-то блокировка на количество соединений и\или трафика. Если его аномально много, к примеру обычно элементы сайта не весят под сотни мегабайт, а вот контент с ютуба очень даже, то это и палит. Но это чисто теория. Просто тут высказывались подобные предположения. А что делать в такой ситуации то?
- Используется ли xmux на клиенте для ограничения кол-ва соединений?
- По симптомам похоже на динамическую блокировку по триггеру. Триггерить может что угодно: bittorrent-клиент, фоновые обращения каких-то программ и т. д., проверяйте методом исключения.
Лег сервак в нидерландах одного хостера нашего. нчиего не работало к ннму и не шло. после восстановления ссш пашет. vlessxtcp +reality sni не max.ru =) не работает.
Мобильный Билайн спб:
сервер 1 Хостер А
Нидерланды
ssh работает
xhttp+tcp-reality не работает (sni не макс.ру)
сервер 2 хостер Б
США
был за yandexcdn долго, позавчера прелетело письмо от РКН с баном
vless xhttp vless enc tls
ssh перестал работает
xray xdns туннель перестал работать сегодня
сервер 3 хостер Б
США
ssh перестал работать
vless xhttp tls vless enc свой домен -перестал работать
сервер 4 хостер Б
США
ssh перестал работать
vless xhttp reality vless enc РАБОТАЕТ (почти не использовался)
сервер 5 хостер С
Германия
ssh перестал работать
vless xhttp tls vless enc свой домен -перестал работать
DPI check от runnin4k выдает TLS drop tls handshake timeout на 60+% серверов вместо обычнеого замедления
На некоторых проводных похожая ситуация.. разве что почти нет tls drop
PS ничего не продавалось.было сделано под себя и родных\друзей
PS никакие торренты не использовались.
PS включил самолетик..отключил.заработал наш нидерландский сервер все остальнео также мертво )
Тоже столкнулся вчера с этим. Включайте в клиенте фрагментацию TLS Client Hello, если он позволяет, и проблема исчезнет. В Exclave это работает.
