Очищает ли zapret периодически ipset ipban? Я туда напихал своих айпишников, но с какой-то непредсказуемой периодичностью они оттуда исчезают. В конфиге GETLIST закомментирован.
ip файлы не стоит изменять - они генерируемые
надо вписывать в zapret-hosts-user-ipban.txt
и прогонять get_ipban.sh
Не, я прямо в ipset добавляю, не в файлы.
И это не хосты, а подсети (телеги). Я так понял, zapret не умеет их в ipset класть.
ipset-ы переписываются в create_ipset.sh, который вызывается раз в 2 дня через крон или системд таймер. если нужно добавлять что-то свое генерируемое, для этих целей есть ipset hook.
его задача получить имя ipset в $1 и выплюнуть в stdout на каждой строчке ip или cidr
ipv4/ipv6 определяется по имени сета
статику надо помещать в zapret-hosts-user-ipban.sh
А есть варианты, как их собрать в один файл и скормить в запрет?
Суть как раз в том, что для каждой ASN своя стратегия. Можно еще здесь взять списки для “популярных” CDN. Но, как я уже писал, они там не совсем точные
сорри за оффтоп, а что за тулза позволяет вывезти эт логи, которые в первом сниппете у тебя?
В F12 всё уходит в таймауты.
Пробовал и с фейком, и без, пробить их так и не смог.
Пришёл к выводу, что да, они просто блочат доступ моим провайдерским GGC во внешку, и они не могут закешировать ролик и отдать мне. То что они успели закешировать до введения этого блока, они отдают.
Так что можно сказать они нашли новый способ бороться с дурилками DPI для ютуба, на моём провайдере тестили его. Значит вскоре будут развёртывать это по всей стране.
Я тоже так думал что ничего не поможет. Есть опыт с одним мелким провайдером, очень вредным. Не все фейки подходят. Попробуйте stun.bin или создайте фейк от сайта ozon, avito, rzd. Ссылку на прогу по созданию фейка выложили выше.
Похоже, что обход 16 кб блокировок через подстановку SNI из белого списка работает только если включен DoH. Может так всегда было, но я только сегодня обратил внимание. У меня без DoH нет досупа к сайтам за CF, а вот за Amazon - есть.
Подозреваю, что наличие DoH влияет в вашем случае на то, резольвится ли ECH-конфигурация домена, или же только IP-адрес. Без DoH скорее всего ECH использоваться не будет, потому и возникает различие в поведении. Больше никакой разницы быть не должно, сомневаюсь, что хитрый ТСПУ делает пометки вроде “клиент зарезольвил такую-то пару домен-IP только что, замедлить весь трафик к этому IP независимо от SNI” (технически, конечно, такое возможно провернуть, но затратно в плане ресурсов и плохо поддаётся лоад балансингу).
Причём, на линуксе и win11 ECH может работать и без DoH. Хотя, в этом и нет особого смысла.
Смысл в некоторых ситуациях есть, например, DNS-сервер на роутере, принимающий запросы от клиентов в открытом виде, но запрашивающий у вышележащих DNS-серверов через DoH или другой протокол с шифрованием
Либо со включенным DoH DNS выдаёт IP, где фильтры менее строгие.
У меня несколько хостлистов с разными стратегиями. Сегодня долго не мог понять, почему обход перестал работать на части хостов. Оказалось, виной всему пустой хостлист в одной из стратегий (перенес хосты в другой лист, а в этом остались только закомментированные). Видимо, пустой хостлист равняется его отсутствию и стратегия применяется ко всем хостам, так что следующие по списку стратегии уже не будут работать. Наверное, правильнее было бы стратегию с пустым хостлистом ни к кому не применять, чем применять ко всем, раз уж юзер указал –hostlist.
Уже обсуждалось такое поведение.
Проще добавить в хостлист какой-нибудь example.com, а еще лучще использовать --skip для профиля, чем переписывать логику запрета.
Об этом и в доке сказано.
тут скорее всего dup включает глобальный режим пустых ack (который по умолчанию выключен) и соответственно cutoff переносится на +1
Так и есть
Я тут немного поторопился с выводами. Ситуация следующая. Есть два домена, по отношению к которым задействована 16 кб блокировка: dl-alps-2.gcdn.ac и dln1.ncdn.ec . (Это не сайты, оттуда скачиваются файлы). Они находятся за Cloudflare (ASN13335).
В Запрете применяю стратегию:
--dpi-desync=fake --dpi-desync-fooling=ts --dpi-desync-fake-tls-mod=sni=сайт_из_БС
в --hostlist записи:
cloudflare-ech.com
dl-alps-2.gcdn.ac
dln1.ncdn.ec
В Firefox 148 блокировка обходится, а в Chrome 145 - ни в какую.
У кого-нибудь есть какие идеи почему так происходит в Хроме? Все это у меня на Linux, на Windows не проверял. Я не знаю как там Запрет настраивать.
Вывод про DoH скорее всего правильный, т.к. в Фаерфоксе сейчас по умолчанию включается DoH от Cloudflare, а в Хроме надо ручками включить