Pull to refresh

Comments 31

Заворачивать весь трафик в VPN? Зачем!

Чтобы не утруждать себя поиском и реализацией иных путей, вроде игр с dns, которые всё равно не дают 100% результата. И чтобы получить белый ip заодно, некоторые провайдеры их больше не выдают, даже за деньги.
Так я не понял, а в чем проблема использовать DoH от Cloudflare или Google? Разве это не то же самое?

Нет, это существенно другая конструкция. Примерно вся разница описана в этом параграфе:


выкидывать из DNS ответов заблокированные IP адреса а, если адресов не осталось, заменять их на подходящие адреса с того же CDN

Это нарушение стандартов работы DNS и выкатывать такое "по-умолчанию" большой сервис позволить не может.


Собственно, пару недель тому назад на https://cloudflare.com нельзя было зайти — оба IP адреса из ответа были заблокированы по предварительному обеспечению по "пиратке".

Я был бы рад такую конструкцию увидеть у Яндекс.DNS в «Безопасном» режиме, но всё же не думаю, что Яндекс готов реализовать такую в меру «серую» фичу.

Есть эти ребята которые держат публичный сервер, ответы фильтруются.
Для заблокированных доменов отдают Non-existent, а для остальных удаляют из выдачи заблокированные ip
Эти ребята

Отличные ребята! Спасибо! Я посмотрю немного подробнее, что именно они делают. Жаль, исходников конфигурации не выкладывают.

Я глубоко не уверен, что это даже близко похоже. По описанию, это скорее для блокировки

Да так, мелкий самодельный утиль.


В публичном виде это выглядит как @u2ckbot от schors.

В настройках андроида вбил ровно как на скриншоте — пишет «Ошибка подключения». К dns.google.com, вбитому в это же поле, подключается без проблем.

Кажется, мы нашли какой-то баг в Unbound или его конфигурации. С DNS-over-TLS у меня сейчас тоже наблюдаются проблемы, а DNS-over-HTTPS работает нормально. При том диагностики примерно нуль: сервер просто ИНОГДА не отвечает на Client Hello, а в мониторинге всё хорошо (отсох почему-то только IPv4, а мониторинг предпочитает IPv6 при dual-stack).


Буду разбираться. На smoke-тесте всё работало.

Попробуй временно поставить чуть не nginx перед

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


Но в целом там accept() завис, даже соединения из очереди не забираются:


State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process 
LISTEN  157     256           0.0.0.0:853        0.0.0.0:*     users:(("unbound",pid=4167,fd=8)) 
LISTEN  197     256           0.0.0.0:443        0.0.0.0:*     users:(("unbound",pid=4167,fd=4)) 
LISTEN  0       256              [::]:853           [::]:*     users:(("unbound",pid=4167,fd=10)) 
LISTEN  0       256              [::]:443           [::]:*     users:(("unbound",pid=4167,fd=6)) 

У меня пара частных Unbound в режиме DoT и с Андроидов 9+ работают вроде бы без проблем у родственников. Версия последняя? OpenSSL? Ну и вообще TLS стек должен быть стабилен как танк, там дальше уже возможны вопросы...

Версия из debian:testing с пересобранным пакетом, т.к. DoH по-умолчанию не собирается. Там не в TLS дело, там в какой-то момент на серверном сокете происходит "нечто", после чего он перестаёт accept()-ить новые соединения, это отлично видно в strace. Я пока уверен, что это баг в Unbound и я попробую с ним разобраться.

Сейчас должно работать. Но когда оно опять сломается — я предсказать не берусь пока, но по крайней мере своевременно теперь узнаю. Будем разбираться и починять. Собственно, в том числе для теста технологии я эту конструкцию и собрал :-)

Как вариант — использовать Pi-hole (https://pi-hole.net) или AdGuard Home (https://adguard.com/ru/blog/in-depth-review-adguard-home.html, github.com/AdguardTeam/AdguardHome#comparison-pi-hole).
Оба умеют dot, doh, dnssec + резалка рекламы. Оба можно развернуть у себя.

Зы. AdGuard Home можно развернуть прямо на pfsense (у кого он есть).

Pi-Hole использую, но у него атакой фичи нет.
Идея, кстати, очень хорошая и надо предложить авторам её добавить (возможность lookup запроса к внешнему приложению для валидации/корректировки ответа).


Можно вообще совместить и сделать интересный хак — если нет ни одного разрешённого IP, то сервису выделяется приватный IP, отдаётся короткое время жизни DNS записи, по этому IP делается NAT в реальный IP с обходом блокировок.


Тогда и таблицы роутинга пухнуть на роутерах не будут (если пускать в обход блокировок все заблокированные адреса) и работать всё будет прозрачно.

Автор предлагает побыть объектом атаки DNS spoofing c последующей MITM? :)
У меня последний FireFox просто не открывает через указанный автором DNS ни один https сайт, с сообщением — Издатель не может быть проверен.
То, есть блок сразу за MitM.

Для меня это звучит неожиданно. Если вам интересна причина такого поведения вашей сети — давайте вместе в ней попробуем разобраться.

Да нет особого смысла в этом. Завернуть запросы на ВПН, или на crypt днс, все-таки надежнее.

С технической точки зрения — в точности так!

Ростов-на-Дону, Ростелеком.
Коннекты на публичные DoH частенько отбивает по TCP RST по нескольку недель. Зависимости не выявил.

Нужно больше приватных серверов!

Ну, например, mozilla.cloudflare-dns.com has address 104.16.248.249, а 104.16.248.249 заблокирован со ссылкой на Октябрьский районный суд г. Ставрополя 2-946/13 2013-06-10.


У 8.8.8.8 и 1.1.1.1 (не путать с dns.google и one.one.one.one) причина тоже понятна — в запросах к ним нет SNI и такое некоторые DPI не любят.

Заворачивать весь трафик в VPN? Зачем! Интернет в России ещё не настолько поломан, чтоб добавлять 50-100ms ко всем своим Zoom-созвонам во времена повсеместной самоизоляции.

В Новосибирске — да, 50-100 мс добавится. В Москве при выходе VPN в Финляндии или Швеции — 10-15 мс — уже не так страшно. В Питере вообще пренебречь можно. У меня для некоторых ресурсов на роутере трафик пущен не через VPN (домены яндекса в основном для mirrors.yandex.ru, всякие mos.ru, домены и IP работодателя и еще штук 5). Остальное — через VPN, и, конечно, никаких DNS провайдера.
После того, как перешёл на VPN, забыл напрочь весь геморрой с "национальными особенностями", поэтому считаю, что оно стоит того.

Cloudflare WARP сейчас работает реально шустро, практически не заметно задержек. И это несмотря на его бесплатность.
Блин, эт круто все! Но открывая думал в статье увидеть технопорно про препарирование Unbound, пенетрацию XML-выгрузок Роскомнадзора и вспомогательных скриптов, быть может хитрые трюки какие-нить…

Может бы донастроил BGP для залоченных адресов у себя…

Ну это скорее в исходниках. Там не сложно, но ничего особо интересного :-)

Only those users with full accounts are able to leave comments. Log in, please.