Какую ошибку? Какая ОС?
Проверил .exe v2.1.0, на win11 успешно config переопределяется
win10 [!] Ошибка при загрузке внешнего config.py: Parser stack overflowed - Python source too complex to parse
Нажмите любую клавишу для выхода…
в итоге так и было сделано
Не знаю, по какому принципу сейчас добавляют таргеты в дефолтный список, но расскажу про свой случай -возможно, релевантно. Столкнулась с тем, что Steam (AS заблокирована, но домен явно в белом списке) при смене DNS с 9.9.9.9 на 8.8.8.8 перестал грузиться через браузер дальше шапки сайта.
Подробнее
Ранее у меня стоял Asus Мерлин с quad9 DoT, заменила на OpenWRT-роутер, где был установлен DoH гугла. Сразу напрягло, что еще до настройки каких-либо обходов на новом роутере главная стима в браузере дальше шапки не грузилась (в мобильном аппе не грузилась вообще, а десктопный клиент еще и при рестарте стал крашиться на двух разных машинах). Чего на старом роутере со стимом никогда не происходило.
Curl тоже намекал на 16кб:
$ curl -L -o /dev/null -w “downloaded: %{size_download} bytes\n” ``https://store.steampowered.com/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13814 0 13814 0 0 22 0 --:–:-- 0:10:14 --:–:-- 0
curl: (56) OpenSSL SSL_read: Connection timed out, errno 110
downloaded: 13814 bytes
Это меня озадачило, так как считала, что крупнейшие сервисы типа стима пока целиком в белых списках по AS, иначе засветились бы уже в заголовках. Почитала - временами и местами попадались случайные блокировки конкретных подсетей, но не более. Выявилось следующее:
nslookup store.steampowered.com 8.8.8.8 => 23.197.161.221
nslookup store.steampowered.com 77.88.8.8 => 184.30.24.74
nslookup store.steampowered.com 9.9.9.9 => 2.23.89.208
Прописала 9.9.9.9 на клиенте - главная стима стала грузиться, и curl моментом “downloaded: 817319 bytes”.
custom tcp16.json
[
{“id”: “STEAM-AK-01”, “asn”: “16625”, “provider”: “Akamai Steam (served by Google DNS)”, “ip”: “23.197.161.221”, “port”: 443, “sni”: “``store.steampowered.com``”},
{“id”: “STEAM-AK-02”, “asn”: “16625”, “provider”: “Akamai Steam (served by Yandex DNS)”, “ip”: “184.30.24.74”, “port”: 443, “sni”: “``store.steampowered.com``”},
{“id”: “STEAM-AK-03”, “asn”: “16625”, “provider”: “Akamai Steam (served by Quad9 DNS)”, “ip”: “2.23.89.208”, “port”: 443, “sni”: “``store.steampowered.com``”},
{“id”: “STEAM-AK-01-NS”, “asn”: “16625”, “provider”: “Akamai Steam (served by Google DNS) no SNI”, “ip”: “23.197.161.221”, “port”: 443},
{“id”: “STEAM-AK-02-NS”, “asn”: “16625”, “provider”: “Akamai Steam (served by Yandex DNS) no SNI”, “ip”: “184.30.24.74”, “port”: 443},
{“id”: “STEAM-AK-03-NS”, “asn”: “16625”, “provider”: “Akamai Steam (served by Quad9 DNS) no SNI”, “ip”: “2.23.89.208”, “port”: 443}
]
Проверка TCP 16-20KB блокировки Целей: 6 | timeout: 8.0s
┃ ID ┃ ASN ┃ Провайдер ┃ Alive ┃ Статус ┃
│ STEAM-AK-01 │ AS16625 │ Akamai Steam (served by Google DoH) │ Да │ DETECTED │
Read Timeout at 40KB │
│ STEAM-AK-02 │ AS16625 │ Akamai Steam (served by Yandex DNS) │ Да │ OK │ │
│ STEAM-AK-03 │ AS16625 │ Akamai Steam (served by Quad9 DNS) │ Да │ OK │ │
│ STEAM-AK-03-NS │ AS16625 │ Akamai Steam (served by Quad9 DNS) no SNI │ Да │ OK │ │
│ STEAM-AK-02-NS │ AS16625 │ Akamai Steam (served by Yandex DNS) no SNI │ Да │ OK │ │
│ STEAM-AK-01-NS │ AS16625 │ Akamai Steam (served by Google DoH) no SNI │ Да │ OK │ │
То есть из трех DNS лишь один выдает IP, который под 16кб блоком при использовании SNI? Это меня совсем запутало, ведь они все на одной AS. Я думала, если домен в белом списке, то важен не IP, а пара домен+AS. Или по подсетям тоже практикуют разделение? А главное - почему так вообще происходит? А то не ясно, намеренная это блокировка и пора мысленно отложить сайт в списки на обходы, либо же случайная и можно пока остановиться на смене DNS?
У меня как раз встал выбор публичного DoH в новый роутер, по какому их принципу теперь выбирают? Раньше я бенчмарки всякие делала, но теперь вот появился новый критерий.
Все это навело на следующие мысли - а много ли таких крупных сервисов на CDN, которые на разных DNS разные IP подают, чтобы при этом еще часть была под блоком, а часть - нет?
Не знаю, насколько такое массово и актуально, но появилась идея такого теста - сравнивать несколько публичных DNS по списку доменов, использующих CDN. И по дефолту наполнить его не только проблемными, но и просто популярными, которые случайно могли попасть под блок. И в результате - список публичных DNS с сортировкой по % успешности (бонусом будет дополнительный скоринг в духе BrainicHQ/DoHSpeedTest).
Релиз dpi-detector v3.0.1
Прокси
- Добавлена поддержка прокси
http/socks5-PROXY_URLв конфиге - По умолчанию программа теперь не использует системный прокси
Запуск с параметрами
- Добавена возможность запуска с параметрами. Подробнее в
README
Конфиг
- Новый
config.ymlформат - Удалены некоторые конфиги
Поиск SNI
- Переработана проверка с реалтайма обновлением на постепенный вывод
Обновление сайтов/эндпоинтов
- Удалены “сомнительные” домены из DNS проверки
- Удалено 2 умерших tcp16 эндпоинта
UI/UX
- Легенда вынесена в отдельный пункт меню и больше не появляется после тестов
Новые зависимости
- httpx[socks]>=0.28.1
- PyYAML>=6.0.3
Full Changelog: Comparing v2.1.0...v3.0.0 · Runnin4ik/dpi-detector · GitHub
AS16625 полностью под tcp16 блокировкой, не считая каких-то единичных IP
store.steampowered.com является белым SNI для этой AS и позволяет обходить блокировку IP даже не связанных со стимом.
Протестил эти IP на однострочном тестере, без SNI или с левым SNI дропает соединение на 2м запросе. Если указать store.steampowered.com то все работает норм. Через dpi-detector показывает ОК даже с левыми SNI, пока не понимаю почему.
Как минимум мне попадалась одна AS, где половина подсетей были под блокировкой, а половина нет. Либо внутри подсети половина IP под блокировкой а другая нет.
Посмотрим, но пока выглядит как какая-то нишевая проблема.
Видел в соседних темах инфу, что с ipv6 могут не работать 16kb блокировки. Есть смысл в тестер добавлять ipv4 и ipv6 для 16кб теста?
На МГТС как минимум действует 16КБ блок на сайты, которые хостятся на Cloudflare с IPv6-адресом.
прогонял по всем пунктам, подбор sni затянулся, решил прервать, так как уже было достаточно, но лог в текст с тем что было не сохранился, если есть желание можно пофиксить…
tcp16.json [
{“id”: “ME-01”, “asn”: “32934”, “provider”: “Meta”, “ip”: “157.240.205.60”, “port”: 443},
{“id”: “ME-01”, “asn”: “32934”, “provider”: “Meta”, “ip”: “57.144.249.32”, “port”: 443},
{“id”: “ME-01”, “asn”: “32934”, “provider”: “Meta”, “ip”: “31.13.72.52”, “port”: 443}
]
│ ME-01 │ AS32934 │ Meta │ Нет │ TIMEOUT │ TCP timeout (SYN Drop) │
│ ME-01 │ AS32934 │ Meta │ Нет │ TIMEOUT │ TCP timeout (SYN Drop) │
│ ME-01 │ AS32934 │ Meta │ Нет │ TIMEOUT │ TCP timeout (SYN Drop)
Поиск белых SNI для ASN AS: 1 | IP: 3 | SNI: 189 | батч: 5
Ни одна AS не заблокирована — перебор SNI не нужен.
│TCP 16-20KB √ 0/3 OK (0% ОК) │
хммм, так и должно быть или я что то не так делаю?
На форуме писали, что утилита лезет куда-то на украинские сайты (я так понял, которые в РФ считаются террористическими и т.п.) и это может быть опасно. Поподробнее можно объяснить?
Были только DNS запросы. Эти сайты убраны в v3
Эти IP либо недоступны в целом, либо блокируют соединения. В общем это не 16kb блокировка. Возможно без определенных sni Meta веб-сервер не отвечает. Если sni не указан, то по умолчанию используется example.com
у где-то 7 AS нет подходящих белых SNI, поэтому для них перебирается весь список - от того и долго. Исправлено не будет. Для сохранения отчета нужно дождаться окончания теста
А не хотите сделать подбор sni через curl? Он позволяет за пару секунд делать тысячи параллельных запросов - в итоге находит sni довольно шустро вроде бы.
Один IP точно пингует, а остальные да в блоке. SNI так указывать? Но в итоге все так же…
“id”: “ME-01”, “asn”: “32934”, “provider”: “Meta”, “ip”: “57.144.249.32”, “port”: 443, “sni”: “www.whatsapp.com”
ну да, это необязательно, лишний код, просто если что имейте ввиду кто будет прерывать, просто с экрана копируйте, может скриншот или разделите на два шага, чек и подбор сни…
Питон тоже справляется хорошо с одновременными соединениями, нет смысла тащить в зависимости curl. Проблема не в скорости, а в возможных рейтлимитах. Если для одного IP открывать сотню соединений, то есть шанс словить блок за DOS
В общем экспериментировать надо с этим. Claudflare точно не любит много запросов
Мне пока не удалось) А у вас какое число одновременных соединений?
Глобально у тестера - 100. У проверки sni батчи по 5шт для каждого AS одновременно, когда все завершаются - запускают следующие 5.
Понятно, спасибо. У меня без ограничений: берется список всех белых sni для asn домена и проверяется одним запросом в curl. Про ddos что-то действительно не пришло в голову учесть. А еще не учтен др. момент: на некоторых серверах белые sni есть, но там протокол udp к примеру. По tcp ничего не найдется в принципе. Или на сервере стоит авторизация - тоже ничего не найдется. В общем, имхо, нужно 2 режима подбора sni:
- ищем реально рабочие sni
- выдаем список потенциально рабочих sni для asn (и далее пусть проверяют вручную на своем сервере)
Релиз версии 3.1.0
Новая проверка замедления/доступности Telegram
- Тесты на download, upload и пинг дата-центров
Фиксы
- Исправлено автоматическое завершение после отображения легенды
UDP: у кого win7, проверьте, нормально тест отображается или данные прыгают?