zapret v70.4
- nfqws,tpws: префикс “^” перед доменом в хостлистах исключает поддомены из проверки
- nfqws,tpws: сборка через “make systemd” для поддержки явного оповещения systemd о старте юнита (Type=notify)
- systemd: шаблоны юнитов systemd для отдельного запуска nfqws и tpws без скриптов
- nfqws,tpws: отделение кода сброса UID/GID от дропа linux capabilities. Позволяет использовать минимальные ambient caps в systemd юнитах и запуск не от рута.
- tpws: детектирование WSL 1 и предупреждение о проблемах при использовании некоторых параметров
- blockcheck: предупреждение о проблемах md5sig с fakedsplit/fakeddisorder , когда применяется многосегментный TLS (kyber) и указана низкая сплит-позиция
добрый день. при использовании утилиты blockcheck, могу ли я пытаться достучаться до конкретного айпишника? вчера пытался починить себе дискорд, через wireshark смог вытащить конкретный айпи их сервера, к которому не получается достучаться, но не смог понять, на какой домен стоит пытаться пробиться, так как при использовании успешных стратегий из blockcheck и goodcheck для доменов дискорда:
Спойлер
updates.discord.com
discord-attachments-uploads-prd.storage.googleapis.com
cdn.discordapp.com
discord.gg
в комбинации с другими важными для меня доменами (в т.ч. этого форума и cloudflare), мне обе утилиты выдавали успешные стратегии, гудчек так вообще выдал несколько, где 12 из 12 доменов в используемом списке успешно заработали. тем не менее, почему-то дискорд с ними не завелся, я в итоге методом тыка перебирал стратегии, получилось завести его через syndata, но тогда все остальные сайты не работали, пришлось вытащить решение в отдельный профиль. хочу узнать на будущее, как поступить в такой ситуации, чтобы не пытаться искать решения методом тыка, ломая существующие, и что я сделал не так, потому что по ридми и этому форуму я могу ориентироваться успешно и настроить утилиту сам, но дальше этого у меня ноль познаний в нетворкинге, да и вообще в компьютерах.
blockcheck работает по доменам, а не IP адресам.
zapret не может обойти блокировку по IP
у дискорда есть веб часть и не-веб часть udp на верхних портах
они обходятся по-разному
веб дурится обычным образом для сайтов, а наверху разве что фейки прокатят в разном количестве (repeats). и блокчек для верхов бесполезен. он работает только по веб
чтобы понять где затык надо сначала сниффануть есть ли обращения на порты udp 50000-50099. если нет, то до media даже не доходит
может всё же кто-то подсказать?
попробуй убери порты 50000-50050 c udp и проверь останется ли проблема
если в этом хз как на вин приложении запрета решать проблему с войсами через ограничение по спискам ip, на роутере это реализуется через скрипт для дискорда где как раз прописано к каким ip применять дарение по этим портам
Убрал, проблема осталась. Вообще, отправка файлов в tg идёт по tcp же. На всякий случай почистил файл с хостами, оставил только от ютуба - тоже без изменений.
текущие настройки
C:\Soft\zapret\zapret-winws\winws.exe --wf-l3=ipv4 --wf-tcp=80,443 --wf-udp=443 --filter-tcp=80 --hostlist-auto=c:\Soft\zapret\zapret-winws\blocked.txt --dpi-desync=fake,split2 --dpi-desync-fooling=md5sig --dpi-desync-autottl --new --filter-tcp=443 --hostlist-auto=c:\Soft\zapret\zapret-winws\blocked.txt --dpi-desync=fake,fakedsplit --dpi-desync-fooling=datanoack --dpi-desync-split-pos=1 --dpi-desync-fake-tls=C:\Soft\zapret\my_fakes\tls_clienthello_drive_google_com.bin --new --filter-udp=443 --hostlist-auto=c:\Soft\zapret\zapret-winws\blocked.txt --dpi-desync=fake --dpi-desync-repeats=3 --dpi-desync-fake-quic=C:\Soft\zapret\my_fakes\quic_pl_by_ori.bin
Попробуй число репитов увеличить на 10 или 20
проверил, действительно) не знаю почему всегда считал что udp
PS
батька пояснил ниже в чём проблема)
повторы там на UDP, так что тоже бестолку
От этого никуда не уйти. Перехват пакетов и пересылка их из ядра в user mode процесс - штука затратная. Если в linux есть ограничитель в ядре connbytes, то в windivert его нет, поэтому весь отсылаемый трафик по фильтру идет в winws. В последних версиях предприняты меры для смягчения этой проблемы - пустые ACK не пересылаются. Но при upload пакеты не пустые, они пойдут все. На достаточно мощном проце со скоростями <100 мбит это практически незаметно. Если проц слаб, а линк толст, то будет жрать вплоть до целого ядра.
Только в телеграм, а не битторрент, потому что обычно ставится фильтр windivert --wf-tcp=443. Телега работает по 443 порту. В броузере при аплоаде будет тоже самое.
Возможное решение - перенос zapret на роутер.
Большое спасибо за ответ 
А что вы считаете за мощный процессор в данном контексте, вот есть какой-нибудь Ryzen 7800x3d, он мощный для игр, но мощный ли он для той задачи что вы описали или надо какой-нибудь 9950x 16 ядерный непонятно, можете внести ясность от какого процессора надо считать мощность
На core i7 12 поколения 650 mbit вызывает загрузку половины одного performance ядра.
При этом более 90% приходится на kernel mode, тк сам winws практически ничего не ест. Тяжела сама пересылка из windivert. На NFQUEUE или ipdivert та же картина, это by design. Но в linux есть connbytes. В BSD будет та же самая проблема
При 100 мбит будет <10% одного ядра, а ядер более десяти и еще потоки. Даже не заметите. Причем это только на мощном upload и только в прогах на 443 порту
Если проц intel до 8-10 поколения (точно не знаю), рекомендую отключить митигацию от meltdown. Импортнуть рег файл и ребутнуться.
Это может немного охладить проц. Поскольку часто идет переключение kernel<>user
Если проц новее, рег файл на скорость не повлияет. Узнать подвержен ли проц уязвимости можно через powershell. См хабр
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"FeatureSettingsOverride"=dword:02000003
"FeatureSettingsOverrideMask"=dword:02000003
такую прогу юзал когда на интеле сидел, inSpectre. Там вроде 2 патча отключает которые тормозят проц, либо реестром.
Это ничего не даст уже, на современных системах от этого с погрешности разница, лучше уж 24h2/2025 поставить, где все на sse4.2 перекомпилированно с поддержкой netadaptercx для разгрузки проца
спасибо за разъяснение! когда тыкался и смог завести дискорд, то после прогрузки самого приложения, медия и голосовой чат без проблем грузились, видимо, моя udp стратегия еще рабочая, на крайний случай всегда есть vpn. но пользоваться запретом все равно нравится больше, банально удобнее, да и самому решать проблемы всегда интереснее, пускай даже за помощью иногда приходится обращаться к другим, так что еще раз спасибо за отзывчивость, в следующий раз попробую посмотреть, что там на udp происходит
Разницы не будет на системах, не подверженных атаке meltdown, поскольку ОС обнаруживает такие системы и не включает митигацию.
На подверженных будет значительная разница, когда идет частое переключение колец защиты, тк митигация сбрасывает при этом кэш в проце. Любой сисколл - сброс кэша. Падение будет до 30%
@bolvan спасибо за v70.5, теперь в хроме по h3 YT стал с первой попытки подключаться.
возвращаясь к теме с quic
да. теперь не обязательно указывать --origin-to-force-quic-on чтобы видео грузилось по h3
правда напрямую ggc так и не открывается)
множественные фейки - это имеется ввиду?
--dpi-desync-fake-quic="%~dp0fake\quic_3.bin" --dpi-desync-fake-quic="%~dp0fake\quic_2.bin" --dpi-desync-fake-quic="%~dp0fake\quic_1.bin"