ну тут много разных тем
тот же TLS1.3 или ECH могут блочить
curl --tls-max 1.2 -v -o NUL https://image-cdn-ak.spotifycdn.com/image/ab67706c0000da849d833ea669c1197dd2d6c381
или blockchek и аналоги с проверкой TLS 1.2 vs 1.3
Да, может Akamai (на котором сидят обложки Спотифая) блочат как Amazon или Hetzner, может TLS или ECH. Не особо шарю в сетях, и возможность проверить редко появляется (обложки не часто слетают). Надеюсь как-нибудь кто-нибудь скажет вообще в чем дело. Может вообще сервера Спотифая кривые, кто их знает.
можно через HOSTS попробовать
раз в примерах выше через DNS даже гео-блок обходится
Спойлер
A a1520.dscc.akamai.net. 23.53.40.48
A a1520.dscc.akamai.net. 23.53.40.56
A a1520.dscc.akamai.net. 23.53.40.82
A a1520.dscc.akamai.net. 185.5.161.193
A a1520.dscc.akamai.net. 185.5.161.209
A a1520.dscc.akamai.net. 2.21.240.234
A a1520.dscc.akamai.net. 2.21.240.99
A a1520.dscc.akamai.net. 195.175.176.129
A a1520.dscc.akamai.net. 195.175.176.211
A a1520.dscc.akamai.net. 195.175.176.209
A a1520.dscc.akamai.net. 195.175.176.170
A a1520.dscc.akamai.net. 195.175.176.178
A a1520.dscc.akamai.net. 195.175.176.169
A a1520.dscc.akamai.net. 195.175.176.201
A a1520.dscc.akamai.net. 195.175.176.137
A a1520.dscc.akamai.net. 164.215.74.18
A a1520.dscc.akamai.net. 164.215.74.34
ГеоБлоки через DNS обходят, это да. А вот блокировки по ТСПУ по-моему DNS не помогает. Ну как с Инстой было, когда надо использовать условный goodbyedpi + hosts, тогда да, блока не будет. Ну ладно, спасибо, попробую как-нибудь.
ну блоков много на ТСПУ
ip / sni / “fingerprint”
иногда чтото работает 1+2
то есть например “все” сети CloudFlare/Akamai + SNI
вопрос именно в том все ли ИП адреса попадают под “блок”
А те айпишники выше, они вообще по какому принципу выбираются? Например через dns запрос получаем айпишник(и) i.scdn.co. Эти айпишник(и) допустим заблокирован(ы). И какие-то новые адреса нужно искать, чтоб в hosts подставить, или как это работает?
curl
–connect-to HOST1:PORT1
у разных CDN и разных DNS по разному
ктото смотрит “страну” клиента и отдает разные ИП
Спойлер
a1520.dscc.akamai.net. A IN 20s 2.19.181.72 https://dns.google/dns-query 429ms
a1520.dscc.akamai.net. A IN 20s 2.19.181.64 https://dns.google/dns-query 429ms
a1520.dscc.akamai.net. A IN 20s 2.19.181.65 https://dns.google/dns-query 429ms
a1520.dscc.akamai.net. A IN 19s 23.73.2.137 one.one.one.one:853 510ms
a1520.dscc.akamai.net. A IN 19s 23.73.2.149 one.one.one.one:853 510ms
Допустим есть некий домен. Допустим, выполняю со своего ру-айпишника dns запрос через Google DNS. Получаю один айпишник. Он заблокирован, например. Далее пробую другие варианты: поменять DNS, и(или) поменять свой IP, и посмотреть, какие IP будут выдаваться тогда, и заблокированы ли они. Если не заблокированы, то подставляю их в hosts. Получается так?
да. ИМХО проще скачать какие нибудь doge/doggo/etc
и сделать батник
dig-doggo.CMD
Спойлер
doggo @https://dns10.quad9.net/dns-query --time A AAAA %*
doggo @https://doh.opendns.com/dns-query --time A AAAA %*
doggo @tls://dns.sb --time A AAAA %*
doggo @quic://dns.adguard-dns.com --time A AAAA %*
doggo @https://dns.google/dns-query --time A AAAA %*
doggo @tls://one.one.one.one --time A AAAA %*
запускаешь dig-doggo.CMD image-cdn-ak.spotifycdn.com
получаешь разные IP
пробуешь менять HOSTS
dig-doge.CMD
Спойлер
doge @dns10.quad9.net --tls --time A AAAA %*
doge @185.222.222.222 --time A AAAA %*
doge @dns.adguard-dns.com --tls --time A AAAA %*
doge @dns.comss.one --tls --time A AAAA %*
Releases · mr-karan/doggo
Release v0.2.7 · Dj-Codeman/dog_community · GitHub
Соглашусь пожалуй, что-то случилось, что перестали открываться многие сайты, особенно западные, хотя вроде как бы не должны были быть в списке забаненных.
Провайдер Йота и Мегафон, оба одинаковое поведение.
Есть дедик западный, к которому есть доступ, который 100% не должен быть забанен, однако доступ к нему по HTTPS перекрыт. Более того, на том же порту 443 есть распознание RDP трафика, так с этого порта прекрасно идёт перенаправление на RDP север, но если использовать RDG-proxy из под того же mstsc.exe, то трафик не проходит, так же, как и не проходит HTTPS трафик любых браузеров (для справки, mstsc.exe при использовании RDG-proxy сперва создаёт обычное HTTPS соединение, и только потом сквозь него пускает RDP трафик)
При этом запрос по IP без домена через браузер рубится точно так же!
Сделал пока что вывод, что рубится сам TLS трафик на корню независимо от SNI, а через этот же порт 443 прекрасно пропускает RDP трафик!
Тестировал через VPN, тогда сайт прекрасно открывается по HTTPS(на порту 443), (испробовал даже разные VPN) следовательно и скорее всего работает ТСПУ на стороне провайдера, который распознаёт TLS трафик и рубит его. Кстати, пробовал у браузеров форсировать TLS1.2, не помогло точно так же.
Проверил и zapret, и byedpi с разными стратегиями, ничего не помогает!
То есть надо уже учить программы не давать детектировать TLS трафик, а это, полагаю, на данный момент сделать нереально?!
Как и упомянул, не открываются многие сайты, уже как несколько дней продолжается эта вакханалия. При этом иногда, чаще с утра, сайты не работавшие до этого, вдруг оживают, но спустя какое-то время они снова чебурнетятся. Сейчас правда уже как два дня зачебурнетилось наглухо. Повторюсь ещё раз, RDP трафик на том же порту 443(просто там есть распознание и перенаправление rdp), он прекрасно проходит, но только не TLS!
Update: ещё интересный момент, TLS соединение как бы создаётся, но не даёт загрузить сайт до конца, словно позволяет только некоторое количество байт загрузить и стоп, с RDP трафиком такого не происходит, на нём всё летит.
В шапке топикстартера указан сайт pepper.ru, и с этим сайтом абсолютно идентичное поведение, даёт чутка загрузить несколько байт и отваливается. В принципе уже заметил, очебурнетились и многие российские сайты тоже, не только западные.
Выходит, VLESS не панацея и как запасное решение нужно маскировать трафик под другой протокол.
А нешифрованные HTTP сайты на 80 порту значит открываются?
Случайно ночью (около 3 по МСК) заметил, что в скфо сняли блокировки зарубежных хостингов — все работало как часы. К утру опять прикрыли.
На всех провайдерах блок? И на мобильных?
Лично у меня да. На мобильном Билайне тоже мертво.
А сайты компаний крупных зарубежных тоже не открываются?
S2022 работает?
Проверил чистый HTTP (пришлось отключить перенаправление на https, чтобы проверить, вчера было лень)
Точно такое же поведение, пару байт скачает и глохнет, будто бы не может скачать сайт до конца по чистому HTTP.
Но есть и приятный момент, если включить ByeDPI (не goodbyedpi), он у меня декстопный вариант на socks прокси, то чудесным образом по HTTP начинает открываться, но только не по HTTPS. По RDP по прежнему летает без танцев с бубнами.
Кстати, есть второй дедик, на нём сегодня всё заработало, и по https и по http, вчера только по rdp работало (на одном порту), а https рубилось (http вчера не проверял).
Первый дедик получается до сих пор в отвале лежит, работает только HTTP через ByeDPI (и RDP уже без бубнов на том же порту).
Полагаю, у ТСПУ какая-то выборочная стратегия, да ещё по времени, другого объяснения для себя не нахожу.
Тут вопрос, насколько крупные? Google открывается.
YouTube.com сейчас без ByeDPI даже не грузится сам сайт, возможно разные ТСПУ, раньше сам сайт грузился, но без ByeDPI видео в час по чайной ложке, а сейчас вообще даже сайт не грузится без ByeDPI. Йота и Мегафон, Краснодарский край.
Сегодня некоторые западные сайты грузятся, которые вчера не грузились. Сейчас грузится pepper.ru, хотя вчера просто висел, вопрос в том, как долго это продлится, не исключено, что к вечеру опять очебурнетится.
S2022 работает?
А конкретнее, что за сайт, в угадайку нет желания играть.
Это не сайт а прокси протокол shadowsocks 2022.
Было бы здорово потестить протоколы, которые НЕ маскируются под https: shadowsocks, hysteria, tuic, vmess, juicity
для каждой стратегии установите --dpi-desync-ttl=