Добрый вечер,bolvan! Можете пожалуйста в Zapret добавить на запас фичу пригодится обход блокировки протокола DHT и протокола BitTorrent чтоб как на Ubuntu линукс так и на роутере на MIPS процессоре с поддержкой OpenWRT было .Потому как по непроверенной информации от знакомого так как не чекал вновь пользователи «Ростелекома» в Уральском регионе начали жаловаться на невозможность скачивания файлов через torrent-протокол. Техподдержка якобы отвечает, что торренты это пиратство, поэтому они теперь блокируются и что блокировка торрентов была снята спустя пару дней, но лишь частично. Протокол DHT остаётся заблокированным, то есть пользователи не могут качать торренты, используя magnet-ссылки. И просьба автоскачивание с api Роскомсвободы блок листа с забаннеными сайтами на TCПУ и просто blacklist реализовать в Zapret пригодится фича.

Вы скажите им, что через торренты Linux раздают. И почти в каждом линуксе при установке есть bittorrent клиент.

DHT работает по udp, и единственный потенциальный метод обхода - это nfqws fake.
Сейчас это уже можно пробовать через custom script или полностью вручную.
Проносить “обход DHT” в основной инсталятор и основные скрипты мне не кажется разумным, потому что это скорее вводит людей в заблуждение, давая ощущение волшебной таблетки.
На самом же деле не факт, что метод будет работать надежно. Например, на QUIC, этим методом удается пробить начальный handshake, но потом сеанс застревает.
К тому же если на http(s) есть возможность проверить работоспособность той или иной стратегии через curl, то как проверять на dht ? Тем более в условиях потенциального застревания сеанса дальше.

Я понимаю, вам хочется чтобы “все просто и удобно”. Но я не преследую целей создать простое решение для всех. zapret - это инструментарий для реализации методов обхода DPI, а не однокнопочное решение.

Сейчас мне было бы интересно, чтобы те, у кого блокируется DHT, попробовали вручную метод nfqws fake и сообщили результаты и своего провайдера/город. Как можно больше, чтобы иметь представление что там происходит. Тогда сделаю готовый custom script

Забаненных на ТСПУ сайтов там порядка 40 шт.
Какой смысл скачивать лист, который сработает только на них и не сработает на всех остальных ?
Проще добавить в zapret-hosts-user.txt
По поводу blacklist не совсем понял. zapret-hosts-user.txt содержит юзерский список доменов, которые надо обходить. zapret-hosts-user-exclude.txt - которые не надо обходить
Кроме того, и nfqws, и tpws, могут применять неограниченное количество списков как черных, так и белых, если использовать их в ручном режиме без скриптов zapret

И еще такой момент. Стратегия для обхода ТСПУ может отличаться от стратегии обхода реестра РКН. Нужно 2 теста блокчека и потом обьединять стратегии (надо соображать, автомата нет).
Так что это тоже такой вопросик не однокнопочный. Даже если я совмещу 2 списка РКН и ТСПУ, то ТСПУ может не срабатывать, если юзер пошел по пути копи-пасты стратегий rutracker.org из blockcheck

Ниже процедура преобразования json листов с рублаклист для openwrt и linux/freebsd

curl -L --fail https://reestr.rublacklist.net/api/v3/dpi | jsonfilter  -e '@[*].domains[*]' | sed -e 's/^https:\/\///' -e 's/^http:\/\///' -e 's/\/$//'
curl -L --fail https://reestr.rublacklist.net/api/v3/domains | jsonfilter  -e '@[*]' | sed -e 's/^https:\/\///' -e 's/^http:\/\///' -e 's/\/$//'

curl -L --fail https://reestr.rublacklist.net/api/v3/dpi | jq -r '.[].domains[]' | sed -e 's/^https:\/\///' -e 's/^http:\/\///' -e 's/\/$//'
curl -L --fail https://reestr.rublacklist.net/api/v3/domains | jq -r '.[]' | sed -e 's/^https:\/\///' -e 's/^http:\/\///' -e 's/\/$//'

Было бы интересно узнать как именно блокируется DHT. По сигнатурам или просто блокируется домен router.utorrent.com
Если второе, можно попробовать клиент Tixati, он не использует DNS. Или qBittorrent, он использует много других адресов начальных нод.
Если по сигнатурам, то можно также попробовать пропатчить торрент клиент. Здесь подойдут только opensource клиенты, например qBittorrent. Это будет также полезно, потому что некоторые VPN тоже блочат DHT и патчинг торрент клиента был бы весьма полезным и для них тоже.

Блокировка вроде если верить что мне говорят люди такая же как была у Уфанет 19 сентября 2021 года где клиенты BitTorrent по крайней мере некоторые, похоже, просто отбрасывают неизвестные пакеты по UDP, поэтому можно отправить какой угодно «мусор» реальным пирам в первом пакете, и DHT начнёт работать.Вы еще писали тогда идея на будущее для доработки nfqws и goodbyedpi
пока видится 2 варианта : fake для QUIC и zero/random для остального,вот такое реализовать бы в Zapret c возможность обхода подходила на операторах Мегафон,Билайн,Теле2,МТС.

Оно уже реализовано. Можно использовать руками или с помощью custom script.
Фильтр можно использовать такой. udp, поле данных начинается с “d1:”, connbytes 1:1 или cutoff=d2 в nfqws.
Пусть расскажут как работает на таком варианте. Не застревает ли.

Такой метод очень прост для определения и блокировки насколько мне известно.Может есть стратегия обхода посложнее?

Метод fake для udp расчитан исключительно на stateful фильтр. В расчете, что он не анализирует каждый пакет, а видит не-DHT и заносит “connection” в белый список.
Против stateless фильтра это не работает.

Теоретически помогла бы фрагментация на уровне IP, но на практике этот метод для инета фактически не применим, потому что фрагменты практически всегда режутся или склеиваются, не могут пройти NAT

Возможно, какой-то DPI купится на дополнительные хедеры в ipv6, но это тоже сомнительно. Не везде есть ipv6, а если есть, то пакеты с доп хедерами часто режутся

Адаптировать Zapret для IOS,MacOS пользователей возможно как-то ,чтоб собрать приложение готовое попробовать по типу GoodbyeDPI?

docs/bsd.txt

Bolvan в репозитории к Zapret я в описании не увидел продолжение,насчет того что если провайдер заворачивать на squid или если соединение проходит через фильтр, способный реконструировать TCP соединение.Как такой обойти DPI к примеру,просто мне кажется такой фильтр стоит у провайдера Дом.ру или тот же ТТК и хотелось бы знать заранее как обход блокировок через Zapret настраивать ,чтоб обходить фильтр, способный реконструировать TCP соединение или же завернутый на squid программный пакет, реализующий функцию кэширующего прокси-сервера для протоколов HTTP, FTP, Gopher и HTTP ?

Если TCP проксируется, а проверка выполняется уже после полноценного реконструктора уровня ОС, а не DPI, то вариантов немного.
Для https их вообще нет. Для http теоретически может прокатить изменение собственно данных запроса (–hostcase, --methodleol и тд), но только если соединение дальше прогоняется в неизменном виде, а не вызывает отдельные запросы с кэширующего сервера.

DPI тоже часто реконструируют TCP, но делают они это в упрощенном для них варианте, не учитывая все случаи. Против такого и работают методы десинхронизации типа split, disorder

Собственно, сейчас смысла в кэширующих серверах практически нет, поскольку почти все идет через https. Они требуют огромной вычислительной мощности в рамках крупного провайдера, потому их содержать смысла никакого нет. Потому вряд ли провайдер использует эту технологию.
Проверить достаточно просто. Сделать telnet на любой нерабочий IP адрес, и если соединение устанаваливается, а потом виснет или прерывается, то это оно самое.

Домру проверял не далее , чем полгода назад, в СПБ. Обходилось
Домру подменяет DNS, даже на другие сервера

Bolvan предложение у меня по развитию программы Zapret, добавьте возможность обхода блокировки по ТСПУ протокола OpenVPN UDP/TCP ,ну и обход блокировки протокола Wireguard. Ну и на всякий пожарный еще обход возможной блокировки в будущем это IKEv2/IPsec

Принципиально методы обхода для всех протоколов примерно одинаковы.
По умолчанию nfqws распознает протокол, и применяет дурение только к распознанным элементам протокола (типа TLS ClientHello).

nfqws умеет работать и с любыми протоколами с помощью ключа --dpi-desync-any-protocol .
–dpi-desync-cutoff позволяет задать точку отсечения десинхронизации. Попросту говоря номер пакета или количество данных в соединении, после которого прекращаются любые действия по десинхронизации. Этого же эффекта в linux можно достичь через iptables -m connbytes, в nftables тоже есть аналог.

Если начнут массово блокировать те или иные протоколы, я добавлю в nfqws/tpws распознавалку, чтобы не использовать cutoff. Пока же говорить еще рано. Тестировать не на чем.

Что касается простой поддержке в сетапе, то посмотрим стоит ли ее делать. VPN это вам не 80,443, а может быть на любом порту, и придется заворачивать весь трафик для анализа , ну или по крайней мере по connbytes. К тому же тут неуместны фильтры по заблокированным сайтам. Выпадает несколько из логики.
Вероятно напишу custom-ы, в которых можно будет указать номера портов. Заранее смысла делать нет. Примерно как сейчас сделано с QUIC

update: QUIC переведен в main функционал, протащеный через скрипты

Bolvan верно я понимаю на провайдере sknt.ru как вы говорите он сделал качественную блокировку по SNI (идет расшифровка на DPI) как на ipv4, так и на ipv6, по списку заблокированных доменов. Обход ban QUIC через nfqws не проканает,так как хороший качественно настроенный DPI cтоит?

Совсем неверно.

DPI вовсе не качественный. Модуль парсинга QUIC плохой. Он не может распознать запросы от curl с quiche и от firefox. Но зато блокирует от curl с nghttp3 и от chrome based browsers.
Получается, что от firefox запросы вообще не блокируются.
Но если все-таки использовать блокируемый клиент, то там картина довольно качественная. Идет выпарсивание SNI и блокировка по нему в stateful mode.

Потому при включении обхода в nfqws начинают работать ранее не работавшие клиенты, а работавшим и так пофигу.
И что самое важное - так стало на большинстве провайдеров.
Раньше был хаос. Блочили непойми как , порой вообще наглухо. А если пробивалось, то потом висло. Сейчас же QUIC становится разрешенным. Значит после обмана не должно быть зависаний