Вот сейчас проверил сутки спустя, Cloudflare и CDN77 заработали. Попробую включить DHT.
Через 5 минут после включения DHT проверил Cloudflare и CDN77 — перестали работать, выключил DHT, подождал 40 минут — блок сохранился, выключил роутер на 5 минут — IP CGNAT поменялся, Cloudflare и CDN77 работает. Жаль, что в Tixati нельзя проксировать DHT отдельно от UDP пиров. Блокировка похожа на триггер snowflake.
̶А̶ ̶к̶а̶к̶о̶й̶ ̶у̶ ̶в̶а̶с̶ ̶t̶o̶r̶r̶e̶n̶t̶ ̶к̶л̶и̶е̶н̶т̶?̶ Увидел.
Я недавно тоже заметил блокировку некоторых cdn, и добавил некоторые подсети через ВПН, в том числе cdn77.
И у меня тоже раздачи 24/7, но IP статический.
В qbittorrent дефолтные bootstrap ноды такие прописаны:
dht.libtorrent.org:25401, dht.transmissionbt.com:6881, router.bittorrent.com:6881, router.utorrent.com:6881, dht.aelitis.com:6881
Можете проверить телнетом, сработает ли триггер при обращении на них?
А как это сделать? DHT же по UDP работает, наверное nping нужен с содержимым d1:
, пока нет времени проверять, наверное как писали в соседней ветке про запрет можно попробовать фейк пакеты добавлять в хендшейк (а мне проще их завернуть в тунель).
Действительно, ноды по udp работают, что-то я об этом не подумал.
Но, я посмотрел у себя в дампе трафика, кроме bootstrap серверов, я ещё запрашиваю список пиров у других участников, возможно полученных через трекеры. И если вы говорите, что при отключенном dht блокировки нет, то скорее всего триггерит сам dht, а не bootstrap ноды.
Но я пока не вижу логики, как dht связан с блокировкой cdn.
Поддержка включила белый IP на полчаса, все ок на нем.
Видимо, белый IP спасает от этих фильтров непонятных.
@Razumist_Razumnii
на данный момент нет “единого” китайского файрвола
ТСПУ разные (москва, регионы, ЮГ, ДВ)
провайдеры сами чудят по всякому (вроде дом.ру что даже чужие ДНС режет)
не говоря о том что ПОКА еще
часть хостингов в РФ “мимо” ТСПУ (ну кроме магистральных блокировок на ТТК/Билайн/?)
редко банят/режут IPv6
так что совсем уж “рубильник” врядли отключат
я смотрю даже официальные СМИ нередко до сих пор пользуются google-analytics/etc
ria.ru вообще вон зачемто грузит
<script async="async" src="https://www.tiktok.com/embed.js"></script>
@kowak
я так понимаю они добавляют “разное”
пример
- Basic (Level 1) blocklist by Bluetack Internet Security Solutions.
- Bogon list by CIDR Reports.
- Fake servers list created and updated by me (part one, part two).
- Amazon AWS IP ranges
есть вообще чтото вроде
Список сетей государственных структур
Список взят с github.com/AntiZapret/antizapret.
Количество префиксов: 233, Количество адресов: 88924.
https://antifilter.network/download/govno.lst
http://roscenzura.com/roscomsos/gosip.txt
Словил блок ещё раз — заметил, что соединения к webtunnel мостам TOR начали зависать. Выключил UDP протокол в торрен-качалке полностью, посмотрим. Но этот тип блокировки есть и у пользователей, которые торрентами и псифонами не пользуются (опять CGNAT виноват?).
там похоже палят CDN77
и он не только для snowflake
так речь выше про webtunnel, он вообще не использует CDN (если только владельцы конкретных бриджей зачем-то не решили свои бриджит прикрыть за CDN), там простой HTTPS с вебсокетами.
phpmyadmin.net is used as domain front to talk to rdsys to request bridges.
Tor and Hetzner block in Russia - Support / Censorship Circumvention - Tor Project Forum
Я имел ввиду, что обнаружил эту блокировку по зависанию бриджей, которые хостятся на Ionos (сам сайт кстати тоже не открывается напрямую), но кое-что поменялось — теперь CDN77 блокируется, а Cloudflare заработал.
Так там как раз сказано, что он используется для запроса новых бриджей, а не для работы уже полученных (если речь идет про webtunnel, а не про snowflake).
этот же домен используется в moat. у меня был случай что случайно что-то не то нажалось в тор браузере пока настраивал для работы системного демона, так у меня потом пол интернета пропало. этот домен нужно убрать из extensions.torlauncher.bridgedb_front на него именно в браузере наложено какое-то проклятие необычайной силы. в том же курле на него такого феерического проклятия не было
“Шеф, всё пропало”
Сегодня перестали многие сайты открываться, которые раньше побеждались сменой стратегий в ByeDPI.
При этом отдача файла запинается, скажем там на размере около ~10кб. Если сайт(/index.html) или файл в этот размер вошли, то срабатывает, если нет, то останавливается.
Если ByeDPI якобы находит новую стратегию, то она тоже из разряда ~10кб на отдачу и сайт зависает и до конца уже не загружается.
Пока работает антитор.
Подтверждаю, именно так всё и выглядит. Создаётся “видимость доступности”. Сервисы пингуются, сайты начинают открываться, соединения начинают устанавливаться – и рубятся уже в процессе. Не знаю, результат ли это каких-то новых тестирований от РКН, или их новая тактика, но всё выглядит так, как будто нужно менять стратегию проверки методов обхода/доступности сервисов, чтобы начать учитывать стабильность соединения во времени и по объему переданных данных.
Мне совсем не понятно почему на это CF, Hetzener и прочих свет не сошелся. Я понимаю бороться с конкретными методами обхода но это что то другое. У того же тор стабильно 40к мостов работает уже который год
В китае же
n China, all obfs4 bridges (including the one I built) are blocked and cannot be connected. Please fix this problem. Thank you.
Нет это что то другое. Вспомнились слова про то что надо душить иностранные компании. Я думаю как раз причина в этом. То есть речь даже не о цензуре как таковой а об “импортозамещении” Если так то дело совсем уже в разнос пошло
Заметил, абсолютно все сайты, в том числе российские, которые используют Cloudflare для защиты от DDOSa, ни один не открывается.
Новый тип блокировок рубит и ломает всё!
У меня уже давно не открываются сайты, где надо поставить галку что ты не робот от cloudflare, ставишь галку, крутится и снова это окно или пишет сбой