Если вы решите использовать штатные DoH или DoT, то в разделе «Дополнительный обход фильтрации DNS-запросов провайдером» вы пропускаете всё, что касается dnscrypt (до строки "Откройте в редакторе скрипт /opt/bin/unblock_ipset.sh:"). А во всех скриптах этого раздела меняете порт 9153 на необходимый (например, 40500).

Или если хотите, чтобы все запросы шли через штатные DoH или DoT (а не только для ресурсов из unblock.txt), то раздел «Дополнительный обход фильтрации DNS-запросов провайдером» вообще не делаете.

В 10-м шаге (редактирование файла dnsmasq.conf) добавляете все ваши прокси DoH и DoT. Вот пример моих:

no-resolv
server=127.0.0.1#40500
server=127.0.0.1#40508

Не забудьте удалить строку "server=8.8.8.8", если она у вас была.

В KeeneticOS версии 3.1 появилась поддержка DNS-over-TLS и DNS-over-HTTPS. Работают они в виде прокси-сервиса. И продолжают работать после применения dns-override. Это значит, что в разделе "Дополнительный обход фильтрации DNS-запросов провайдером" (если провайдер фильтрует DNS) вы можете отказаться от dnscrypt.

Посмотреть, на какие порты назначены DNS-прокси, можно с помощью команды:

cat /tmp/ndnproxymain.stat

Вот пример:

~ # cat /tmp/ndnproxymain.stat
# ndnproxy statistics file

Total incoming requests: 5059
Proxy requests sent:     5059
Cache hits ratio:        0.000 (0)
Memory usage:            3.24K

DNS Servers

                      Ip   Port  R.Sent  A.Rcvd  NX.Rcvd  Med.Resp  Avg.Resp  Rank
               127.0.0.1  40500       1       1        0      32ms      32ms     4
               127.0.0.1  40508    5058    5058        0      33ms      33ms     4
~ #

В моём случае прокси для DNS-over-TLS висит на порте 40500, а DNS-over-HTTPS на 40508.

Вы теперь легко можете использовать 127.0.0.1:40500 или 127.0.0.1:40508 вместо 127.0.0.1:9153 (dnscrypt).

После одного прочтения, я не понял, какую суть хотел донести автор. В любом случае, настройки Tor в описанном методе обхода блокировок не позволяют Tor выступать ни в качестве выходного узла, ни в качестве промежуточного узла. Только клиент.

Прочитал несколько восторженных отзывов о том, что Mozilla в конце месяца начнёт постепенное и плановое включение по умолчанию DNS-over-HTTPS (DoH) и Encrypted SNI (в TLS 1.3). Первая волна будет у части пользователей в США, потому будет распространяться дальше, зависимо от результатов работы.

Google тоже обещает начать внедрение DoH и ESNI в Chrome по умолчанию до конца года.

Если вы не поняли, что это значит, кратко расшифрую. Браузер теперь самостоятельно через DoH будет резолвить доменные имена по зашифрованному каналу. Т.е. никто со стороны не сможет узнать, IP-адрес какого домена вы хотите уточнить. ESNI (Encrypted Server Name Indication) — это расширение протокола TLS для передачи имени хоста в зашифрованном виде. Т.е. никто со стороны не сможет узнать, к какому именно домену вы обращаетесь, только его IP.

В реальности всё это классно. Но суть восторженных российских отзывов заключается в том, что Роскомнадзор теперь "не сможет блокировать ресурсы". Это в корне неверно, потому что у российских пользователей теперь появится больше проблем.

Если сейчас провайдеры через DPI могут выявлять обращение к заблокированному домену, анализируя SNI. То с ESNI этот фокус не пройдёт. И провайдерам для исполнения требований Роскомнадзора придётся блокировать IP-адрес полностью (а не обращения к конкретному хосту), на котором находится домен. Это значит, что будут заблокированы все хосты (домены), которые находятся на этом IP-адресе. Это значит, что все хосты, которым будет присвоен этот IP-адрес (если он принадлежит CDN) автоматически будут заблокированы.

Т.е. существенно вырастет количество ресурсов, которые перестанут работать, хоть они и не заблокированы Роскомнадзором — побочные жертвы. Их количество будет расти. При этом ранее заблокированные ресурсы так и будут заблокированы, если вы не используете методы обхода блокировок.

Внедрение DoH и ESNI в большинстве случаев не повлияет на работу описанного в статье метода обхода блокировок.

Здравствуйте.

Список всех интерфейсов:
ifconfig -a

Редирект добавлять в шаге 9.

Статья актуальная. Инструкция полностью работоспособна на последней прошивке KeeneticOS 3.1 и последних прошивках Padavan (32a93db) и Padavan-linaro (56960f9).

В статье не идёт речь о блокировке рекламы. Только в комментарии. И там же уточнение:

Тут нужно быть аккуратным, потому что список рубит лишнее, и что-то нужное может перестать работать.

Могли быть с dnsmasq проблемы, если настраивали давно и обновляли прошивку на Keenetic. Просто переделайте пункт 10, он несколько месяцев назад был подправлен.

В Firefox по умолчанию включен параметр "network.dns.blockDotOnion" — блокировка onion-доменов. Его можно отключить (в about:config).

Где-то допустили ошибку (другого варианта нет).

Rutor пару недель назад включил фильтрацию выходных узлов Tor при доступе по основному домену. Ранее они уже это делали (зачем, спросите у них).

Используйте официальный домен в зоне onion, там фильтрация выключена — rutorc6mqdinc4cz.onion. Как включить доступ к .onion, написано в конце статьи.

Время не теряют. Вторая попытка? Первая была буквально две недели назад. В АП тогда оказались не готовы и дали заднюю (дали распоряжение отклонить поправки в ГД).

Если убрать всю шелуху и оставить только суть, то основной бенефициар этого закона — Яндекс. Она же основной лоббист. Сам закон в реальности направлен против компании Apple. Т.е. они захотели провернуть тот же финт, которой они провернули с помощью административного ресурса с Google (когда шансов запрыгнуть в уходящий поезд мобильного трафика больше не осталось). Но зашли теперь с другой стороны и постарались всё завуалировать. При первой попытке административный ресурс им отказал в помощи, но это дело времени. Вот и вторая попытка. Какую цену платит Яндекс за использование административного ресурса и за нерыночные инструменты конкурентной борьбы, все прекрасно знают — бабушки у подъезда любому расскажут про Яндекс.Новости и прочие прелести жизни.

В статье как раз об этом написано. Посмотрите раздел "Основные методы диагностики ошибок после настройки" и "Дополнительный обход фильтрации DNS-запросов провайдером".

Скорее всего, фильтрация DNS провайдером.

Хорошая статья. Половину после первого прочтения не понял (буду вникать по второму разу), но сама тема формирования рекомендаций очень значимая для операторов VoD-контента. Для спортивного интереса и оценки своего видения поучаствую в песочнице на Boosters.

Для себя сделал некоторые выводы:

• В основной массе все смотрят новинки. Т.е. если в VoD-сервисе присутствуют "рекомендации" в виде простого списка новинок по дате релиза или по рейтингу за определённый интервал времени, основная масса будет ориентироваться именно на такие рекомендации. Подобные "рекомендации" никак не связаны с предыдущими действиями пользователей.
• Рекомендации другого вида нужны не потребителю, а оператору, чтобы продвигать определённый контент. Пользователь будет ориентироваться на рекомендации в любом случае (он просто любит рекомендации и советы), достаточно лишь приблизительно соответствовать его потребностям и не дискредитировать саму систему рекомендаций, например, перекосом из-за маржинальности, которая может разочаровать потребителя. Т.е. рекомендации больше важны для VoD-сервиса, чем для потребителя, чтобы продвигать свои интересы. Чтобы навязать требуемый контент, а вовсе не для того, чтобы пользователь получил больше подходящий ему контент.
• Для рекомендаций важны внешние факторы, которые не связаны с внутренними действиями пользователя. Т.е. ускорять продвижение требуемого контента можно на основе внешних факторов.
• Локальный рейтинг контента (отдельного небольшого VoD-сервиса) важен лишь для визуальной манипуляции в рекомендациях. Для реальных рекомендаций большее значение имеет глобальный рейтинг уровня КиноПоиск, IMDb и пр.
• Флаг "новинка" в совокупности с подачей информации имеет большую ценность при выборе потребителем, чем рейтинг.

И когда вы в Okko добавите поддержку автофреймрейта (preferredDisplayModeId) в версии для Android TV? (в последний раз, когда смотрел вашу программу, поддержки не было)