Комментарии 67
Раз уж how-to.
На пакетах openwrt такое реализуется?
Городить отдельный сервер для меня как-то избыточно, а вот приличный роутер — самое оно, имхо.
Есть важное условие для adblock — требуется от OpenWrt-18.06.0. Личные впечатления — сложнее исключать из блокировки сайты, кое-что нужное отвалилось. У pi-hole интерфейс намного проще.
Вчера DoH запустил на своем роутере. Пока заметил только, что aliexpress автоматически включает французский язык.
Вчера DoH запустил на своем роутере. Пока заметил только, что aliexpress автоматически включает французский язык.
Есть важное условие для adblock — требуется от OpenWrt-18.06.0.Нет, adblock уже был в 17.01, а может и раньше.
Для более старых версий OpenWrt, где пакета в репозиториях ещё не было, есть самописный вариант.
Под популярную прошивку Padavan я костылил себе вот так.
сложнее исключать из блокировки сайтыРекомендую simple-adblock. Он полегче (у adblock чуть больше фич, но они далеко не всем нужны), а исключения добавляются через веб-интерфейс, куда уж проше.
Тут ещё немаловажно железо, на котором крутится OpenWrt.
Можно легко ушатать роутер, если там слабый проц. (относится не только к этим пакетам, а вообще)
А потом думаешь — а чегой-то у меня тариф 100 Мбит/с, а закачки 2.5-3 МБ/с вместо 10-11?
а это бедный роутер не тащит всю петрушку, которую на него понаставили :)
Можно легко ушатать роутер, если там слабый проц. (относится не только к этим пакетам, а вообще)
А потом думаешь — а чегой-то у меня тариф 100 Мбит/с, а закачки 2.5-3 МБ/с вместо 10-11?
а это бедный роутер не тащит всю петрушку, которую на него понаставили :)
А такое можно установить на zyxel keenetic?
Если речь про adblock - то на кинетиках есть AdGuard. https://dartraiden.github.io/AdGuard-Home-Keenetic/ вот тут, например, инструкция.
Всё делается, dnscrypt настраивается за полчаса-час на свежих версиях OpenWRT. DoH proxy, вероятно, тоже.
Ещё из прелестей OpenWRT:
- Прозрачная маршрутизация в сети Tor и i2p для всей локалки
- Маршрутизация IPv6 для всей локалки, в том числе через внешние шлюзы
- Блокировка рекламы (adblock, simple-adblock), если вам это интересно
- У вас только одна железка, от которой это всё зависит, а не две (плюс связность между ними), как в случае с Pi-Hole
openwrt.org/docs/guide-user/services/dns/dot_dnsmasq_stubby
openwrt.org/docs/guide-user/services/dns/doh_dnsmasq_https-dns-proxy
На ваш вкус и цвет, как говорится.
В случае DoT можно вообще не залезать в консоль, см. forum.openwrt.org/t/tutorial-no-cli-configuring-dns-over-tls-with-luci-using-stubby-and-dnsmasq/29143/17
openwrt.org/docs/guide-user/services/dns/doh_dnsmasq_https-dns-proxy
На ваш вкус и цвет, как говорится.
В случае DoT можно вообще не залезать в консоль, см. forum.openwrt.org/t/tutorial-no-cli-configuring-dns-over-tls-with-luci-using-stubby-and-dnsmasq/29143/17
Нет варианта «уже внедрил». Pi-hole — эта та вещь, которую уже пора иметь в любой домашней сети по умолчанию. И периодически смотреть Dashboard, Query Logs и пресекать деятельность слишком умных устройств.
У Zyxel в текущем большом обновлении ОСи для всех поддерживаемых роутеров прилетело и DNSoverTLS и DNSoverHTTPS
Дома на pfSense хватает встроенного DNS over TLS.
Все прекрасно, но если внезапно заканчиваются деньги на интернете, то личный кабинет перестает работать. Обычно решается назначением нужных IP адресов на домены личного кабинета в DNS сервере.
Все прекрасно, но если внезапно заканчиваются деньги на интернете, то личный кабинет перестает работать. Обычно решается назначением нужных IP адресов на домены личного кабинета в DNS сервере.
Ценное замечание, спасибо. Добавлю в статью.
Добавь ещё рекомендацию иметь несколько инстансов pi-hole. Если сервер выключен или обслуживается, то DNS должен продолжать работать.
У меня резерв — сервера у родственников. VPN не требует DNS и поэтому они доступны. Если упал интернет и нет к ним доступа, то DNS уже сильно меньше нужен.
а Pi-hole в сеть может раздавать DoH?
Ну тут не очень понятна формулировка. Что значит «раздавать»? Собственно, предлагаемое решение и позволяет «раздать» в сеть DoH, т.е. предоставить клиентам внутри сети проксирование их DNS-запросов в мир через DoH.
Если имеется в виду «предоставить DoH-сервер для DoH-клиентов внутри сети» — то эта задача решается не очень просто, но решается. Например, буквально две недели назад была статья об этом. Но если у вас DoH-клиенты — то зачем для них ставить сервер внутри, там весь смысл в защите от анализа запросов через внешние каналы связи.
Если имеется в виду «предоставить DoH-сервер для DoH-клиентов внутри сети» — то эта задача решается не очень просто, но решается. Например, буквально две недели назад была статья об этом. Но если у вас DoH-клиенты — то зачем для них ставить сервер внутри, там весь смысл в защите от анализа запросов через внешние каналы связи.
1) На некоторые устройства(вроде тот же OrangePi Zero) можно было поставить только старый пакет cloudflare. Точнее заработает только старый(старый — не значит неработающий).
2) Про статический адрес — Вы написали что он у вас был изначально. Надо сильней на этом сделать акцент. У кого не статический адрес — тому придётся делать его статическим во внутренней сети и лучше настроить его так, чтобы он не конфликтовал потом с другими адресами. Ну например забиндить адрес 192.168.1.5, а раздачу адресов на рутере поставить начиная с 192.168.1.50.
3) Raspberry Pi не тянет много подписок. Вы какие подписки подбирали для России? Там же изначальные подписки вообще не учитывают российских реалий. Пробовали примерное такие списки?
4) Насколько я помню — в PiHole можно немного задавать правила wildcard и regex. Вы тестировали их? Я пару раз попробовала, у меня не сработала фильтрация. Я не сильно вдавалась в детали, так как у меня в принципе всё порезано на уровне браузера. Но было бы полезно знать про опыт других.
5)
Если не ошибаюсь сюда можно подставить другие поддерживающие данную функцию DoH сервера и не надо будет доверять именно Cloudflare
6) Привели бы ссылки на проекты, на инструкции
7) И да, есть подводные камни, которые касаются Raspberry Pi и cloudflare. Например в части создания файлов по рутом. На raspbian от debian 9 надо было сначала проставить пароль на root. С одной стороны это не статья про Raspberry Pi, но с другой стороны Pi-Hole в основном на этой плате и устанавливается. И неплохо было бы для новичков хотя бы пройти простеший путь. Статья то в любом случае для них.
UPD: Добавила пункт 7
2) Про статический адрес — Вы написали что он у вас был изначально. Надо сильней на этом сделать акцент. У кого не статический адрес — тому придётся делать его статическим во внутренней сети и лучше настроить его так, чтобы он не конфликтовал потом с другими адресами. Ну например забиндить адрес 192.168.1.5, а раздачу адресов на рутере поставить начиная с 192.168.1.50.
3) Raspberry Pi не тянет много подписок. Вы какие подписки подбирали для России? Там же изначальные подписки вообще не учитывают российских реалий. Пробовали примерное такие списки?
4) Насколько я помню — в PiHole можно немного задавать правила wildcard и regex. Вы тестировали их? Я пару раз попробовала, у меня не сработала фильтрация. Я не сильно вдавалась в детали, так как у меня в принципе всё порезано на уровне браузера. Но было бы полезно знать про опыт других.
5)
# Commandline args for cloudflared
CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-queryЕсли не ошибаюсь сюда можно подставить другие поддерживающие данную функцию DoH сервера и не надо будет доверять именно Cloudflare
6) Привели бы ссылки на проекты, на инструкции
7) И да, есть подводные камни, которые касаются Raspberry Pi и cloudflare. Например в части создания файлов по рутом. На raspbian от debian 9 надо было сначала проставить пароль на root. С одной стороны это не статья про Raspberry Pi, но с другой стороны Pi-Hole в основном на этой плате и устанавливается. И неплохо было бы для новичков хотя бы пройти простеший путь. Статья то в любом случае для них.
UPD: Добавила пункт 7
По всем пунктам в целом согласен.
1. На младших апельсинах не тестировал, поверил на слово, что работает. На третьей малинке проблем с выкачанным с сайта не было.
2. Если адрес у сервера не статический — Pi-Hole при установке будет настойчиво предлагать поменять его на статический. А разведение диапазонов в целом полезно, но в большинстве случаев избыточно, я давно не встречал устройств, не умеющих проверить занятость адреса.
3. За линк на списки спасибо, внедряющим будет интересно. Жалоб на работу на RPi3 с этими списками не возникало, но нет пределов совершенству.
4. По wildcard записи есть, я тоже в какой-то из старых версий натыкался на проблемы, но в 4.3.2 работают. Сложные регулярки не пробовал за неимением необходимости.
5. Да, безусловно, можно перейти на другие серверы. У меня когда-то были проблемы с совместимостью с гугловым сервисом, что-то там различалось в форматах. Любой желающий может протестировать и использовать с теми серверами, которые ему ближе. Как я и говорил, пост — скорее заготовка.
6. Систематизация ссылок — самая трудная работа в любой документации, всегда лень. Когда-нибудь я достигну совершенства и буду делать статьи идеально :)
1. На младших апельсинах не тестировал, поверил на слово, что работает. На третьей малинке проблем с выкачанным с сайта не было.
2. Если адрес у сервера не статический — Pi-Hole при установке будет настойчиво предлагать поменять его на статический. А разведение диапазонов в целом полезно, но в большинстве случаев избыточно, я давно не встречал устройств, не умеющих проверить занятость адреса.
3. За линк на списки спасибо, внедряющим будет интересно. Жалоб на работу на RPi3 с этими списками не возникало, но нет пределов совершенству.
4. По wildcard записи есть, я тоже в какой-то из старых версий натыкался на проблемы, но в 4.3.2 работают. Сложные регулярки не пробовал за неимением необходимости.
5. Да, безусловно, можно перейти на другие серверы. У меня когда-то были проблемы с совместимостью с гугловым сервисом, что-то там различалось в форматах. Любой желающий может протестировать и использовать с теми серверами, которые ему ближе. Как я и говорил, пост — скорее заготовка.
6. Систематизация ссылок — самая трудная работа в любой документации, всегда лень. Когда-нибудь я достигну совершенства и буду делать статьи идеально :)
но в 4.3.2 работают.Спасибо за информацию. Ещё раз попробую.
Да, безусловно, можно перейти на другие серверы. У меня когда-то были проблемы с совместимостью с гугловым сервисом, что-то там различалось в форматах. Любой желающий может протестировать и использовать с теми серверами, которые ему ближе. Как я и говорил, пост — скорее заготовка.Просто Вы написали в статье что надо доверять Cloudflare. Некоторые могут отказаться от этой идеи из-за этого замечания, даже не дочитав до комментариев. Можно же поставить сноску/примечание в статье, что и этот пункт можно обойти.
Самый главный то вопрос, с какими провайдерами помогает? по-моему все лезут в http, если это http, или блокируют ip, если это https
Как я и говорил, есть провайдеры, которые лезут сначала в DNS-запрос. Это разгружает другие уровни фильтрации. В таких случаях даже если у вас есть VPN, но ваш DNS-запрос проходит через такого провайдера (не обязательно российского, кстати) — вы не сможете воспользоваться VPN, потому что домен отрезолвится или в адрес заглушки, или в локалхост.
Использование DoH исключает манипуляции вашим резолвингом в транзите и раскрытие информации о том, куда именно вы в интернете ходите.
Не у всех востребовано, безусловно.
Использование DoH исключает манипуляции вашим резолвингом в транзите и раскрытие информации о том, куда именно вы в интернете ходите.
Не у всех востребовано, безусловно.
При такой схеме с наличием локального DNS ресольвера DoH вообще не нужен, ни при обращении к внешним серверам, ни, тем более, внутри сети.
Вы можете совершенно спокойно обращаться к нему традиционными (нешифрованными) запросами внутри сети что, заметьте, не требует ни специального софта ни каких-то специфичных настроек, за исключением выдачи IP клиентам DNS сервера по DHCP. Внешние запросы же можно форвардить через DNS-over-TLS к любому из поддерживающим его внешним публичными, или, лучше, вашему личному, DNS серверам.
Ну так, собственно, этот резольвер и занимается форвардингом запросов к публичным серверам. А внутри сети вы традиционными запросами к нему и обращаетесь, и специфичных настроек вам не надо. Вы точно статью читали?
DoT детектируется и, соответственно, блокируется легче, чем DoH, поэтому DoH для меня интереснее. У вас, конечно, может быть другой набор критериев, по которому DoT побеждает.
DoT детектируется и, соответственно, блокируется легче, чем DoH, поэтому DoH для меня интереснее. У вас, конечно, может быть другой набор критериев, по которому DoT побеждает.
DoT детектируется и, соответственно, блокируется легче чем DoH
Это не соответствует действительности. Если вы об использовании порта 853 для DNS-over-TLS, то ничто вам не мешает использовать тот же 443 взамен. Более того, некоторые публичные DoT серверы так и делают. Блокировка по имени хоста или IP вообще ничем не отличается в обоих случаях.
В итоге получается, что DoH за счёт инкапсуляции в HTTP даёт лишь дополнительный оверхед но никак не повышает доступность из-за блокировок.
Используя DoH, вы имеете гораздо больший пул публично доступных на порту 443/tcp серверов, чем используя DoT.
Но я не планирую устраивать тут холивар DoT vs DoH в сверкающих доспехах. Считаете, что DoT лучше — пользуйтесь, конечно же. Рынок устаканится, крупнейшие игроки договорятся и какой-то из этих вариантов выдавит другой без нашего участия.
Но я не планирую устраивать тут холивар DoT vs DoH в сверкающих доспехах. Считаете, что DoT лучше — пользуйтесь, конечно же. Рынок устаканится, крупнейшие игроки договорятся и какой-то из этих вариантов выдавит другой без нашего участия.
Советы в статье полезны и необходимы, но я бы начинал с конкретных устройств. Толку мне от DoH, DoT, VPNs дома, если как только я возьму ноут и пойду в коворкинг, кафе, поеду в отпуск, все сразу отвалится. Поэтому как по мне каждое устройство дома, должно быть самодостаточным (в плане защиты, блокировки реклам, обход блокировок), а не полагаться на роутер, который с собой на улицу не возьмешь.
Для браузера DoH поможет, а вообще для этого случая лучше поднять локальный Unbound с форвадингом через DoT.
Ну, например, домашнему NASу, стационарному компьютеру или телевизору совершенно не обязательно решать вопросы мобильного доступа. У меня квартире сейчас 27 устройств с выделенным IP-адресом, я бы не хотел их все настраивать и особенно переконфигурировать в каком-то случае.
А в целом модели доступа могут быть разнообразны. У меня, например, тот же сервер с Pi-Hole еще и терминирует wireguard-туннели с ноутбука и телефона, поэтому задача обеспечения доступа в таких случаях «сводится к предыдущей» одним кликом в интерфейсе.
Сложно придумать и описать все возможные кейсы использования, обычно имеет смысл дать какую-то канву решения в заданных граничных условиях, а дальше уже помогать с конкретикой отдельным людям.
А в целом модели доступа могут быть разнообразны. У меня, например, тот же сервер с Pi-Hole еще и терминирует wireguard-туннели с ноутбука и телефона, поэтому задача обеспечения доступа в таких случаях «сводится к предыдущей» одним кликом в интерфейсе.
Сложно придумать и описать все возможные кейсы использования, обычно имеет смысл дать какую-то канву решения в заданных граничных условиях, а дальше уже помогать с конкретикой отдельным людям.
У меня квартире сейчас 27 устройств с выделенным IP-адресом, я бы не хотел их все настраивать и особенно переконфигурировать в каком-то случае.eSNI-то всё равно придётся включать на конечном устройстве…
eSNI — это отдельная песня и на самом деле, к сожалению, не поможет. Тут дело в том, что требует от операторов РКН и как это контролирует РЧЦ. С включением eSNI блокировки https просто перейдут в режим «по IP».
НЛО прилетело и опубликовало эту надпись здесь
Для справки (может кто не знает), актуальные маршрутизаторы Keenetic, даже самый простой за 1500 рублей, поддерживают DNS-over-TLS и DNS-over-HTTPS с прошивкой KeeneticOS 3.1. Конструировать паровоз для "домашних" пользователей не нужно.
А нет ли решения для локального bind?
Можно легко переделать это, пропустив первый шаг, а во втором привязать cloudflared к bind вместо pihole через опцию в конфигурационном файле bind:
forwarders {
127.0.0.1 port 5053;
}
Коллеги, пните, пожалуйста, «чайника линукс» в правильном направлении копания:
— Виртуалка 2Gb, чистая установка последней Cent OS 7;
— по шагам все прохожу до пункта «Осталось только подключить сервис к Pi-Hole. Для этого вы заходите в веб-интерфейс Pi-Hole (тут вам пригодится записанный в первом этапе пароль)»
— получаю экран вида
drive.google.com/file/d/1ZsY_tC5fnMs54pIHqmD4QkwIGoE_pnbr/view?usp=sharing
— Виртуалка 2Gb, чистая установка последней Cent OS 7;
— по шагам все прохожу до пункта «Осталось только подключить сервис к Pi-Hole. Для этого вы заходите в веб-интерфейс Pi-Hole (тут вам пригодится записанный в первом этапе пароль)»
— получаю экран вида
drive.google.com/file/d/1ZsY_tC5fnMs54pIHqmD4QkwIGoE_pnbr/view?usp=sharing
Статья интересная. Спасибо. Было бы ещё интересно почитать внятную инструкцию настройки mikrotik+vps +pihole +dnscrypt
На базе mikrotik нельзя поставить pihole и dnscrypt не организуешь — нет функционала.
Столкнулся с определенной неприятностью в реализации DNS-сервера mikrotik. Прописал первым адресом IP виртуалки с DoH и PiHole, вторым — 8.8.8.8 и наивно предполагал, что запросы пойдут через DoH в качестве основного канала, а «восьмерки» будут резервным. С удивлением обнаружил весь трафик DNS на «восьмерках». Полагаю, что mikrotik как-то оценивает сервера DNS по качеству (скорости ответа?) и потом весь трафик гонит в лучший.
В моей ситуации виртуалка с DoH лежит не в домашней сети, а доступна через vpn с офисом, поэтому неудивительно, что прямые запросы на «восьмерки» оказались эффективнее. Выкрутился пока через netwatch — пингую DoH и в зависимости от доступности меняю там DNS-сервера на mikrotik.
Столкнулся с определенной неприятностью в реализации DNS-сервера mikrotik. Прописал первым адресом IP виртуалки с DoH и PiHole, вторым — 8.8.8.8 и наивно предполагал, что запросы пойдут через DoH в качестве основного канала, а «восьмерки» будут резервным. С удивлением обнаружил весь трафик DNS на «восьмерках». Полагаю, что mikrotik как-то оценивает сервера DNS по качеству (скорости ответа?) и потом весь трафик гонит в лучший.
В моей ситуации виртуалка с DoH лежит не в домашней сети, а доступна через vpn с офисом, поэтому неудивительно, что прямые запросы на «восьмерки» оказались эффективнее. Выкрутился пока через netwatch — пингую DoH и в зависимости от доступности меняю там DNS-сервера на mikrotik.
Нет, просто с pi-hole не должно быть обычных DNS. Только один или лучше несколько инстансов pi-hole. Иначе при пустом ответе от pi-hole клиент пробует альтернативный DNS и получает нужный IP.
У меня как раз Mikrotik и виртуальная машина с pi-hole. Резервные ноды у родственников через VPN. Если у меня сервер прилег, то DNS запросы идут к родителям.
У меня как раз Mikrotik и виртуальная машина с pi-hole. Резервные ноды у родственников через VPN. Если у меня сервер прилег, то DNS запросы идут к родителям.
Нет, просто с pi-hole не должно быть обычных DNS
Ага, у меня именно так. А в микротике в качестве DNS изначально было прописано 192.168.142.2, 8.8.8.8 (192.168.142.2 — виртуалка с DoH и PiHole). И в такой ситуации у меня DNS-запросы шли через «восьмерки».
Беда-печаль в том, что выбор, через какой сервер резолвить, никоим образом не стандартизован. Например, XP вообще не умела соскакивать с первого сервера, если он недоступен — то ничего не работает (ну или таймаут измеряется десятками минут, никогда сильно долго не ждал). Именно поэтому смешивать DNS-сервисы, предоставляющие услугу по-разному, не надо.
Да, Вы правы в отношении (отсутствия) стандартизации. Однако хочется неких очевидных вещей по управлению DNS, по крайней мере, от микротика — приоретизация серверов — штука очень ценная.
В микротике есть еще одна «не очень хорошесть» — все исходящие DNS-запросы маскарадятся и повлиять на это никак нельзя. В результате на PiHole-сервер приходят запросы с из другой подсети с одного адреса и это «режет» статистику.
В микротике есть еще одна «не очень хорошесть» — все исходящие DNS-запросы маскарадятся и повлиять на это никак нельзя. В результате на PiHole-сервер приходят запросы с из другой подсети с одного адреса и это «режет» статистику.
Повлиять на это просто, если вам это необходимо. Раздавайте по DHCP не адрес микротика, а адрес PiHole. Имея в голове описанную в статье лишнюю сложность отката в этом случае. Хотя альтернативно можно просто в случае аварии PiHole повесить его адрес на интерфейс микротика.
Не нравится так — в случае аварии PiHole сеть (клиенты) остается без ДНС. То, как сейчас (в DNS микротика прописан адрес PiHole, по netwatch мониторится его доступность и в случае проблем переключается на «восьмерки») — обеспечивает резервирование в случае сбоя. За исключением варианта, когда PiHole-машина пингуется, а резолвы в ней не идут — надеюсь, что такие вещи будут очень редки.
У меня именно такой вариант. Раздается по DHCP. Просто резерв нужен. Еще одна малина/сервер дома/сервер у соседей. Я не зря упомянул про них.
Вы так же можете сделать и в этой схеме, просто при недоступности PiHole нужно не только переключиться на восьмерки, но и поднять интерфейс с адресом PiHole на микротике. И проверять PiHole тоже можно, в общем-то, не пингами, а DNS-запросами.
В целом в домашней сети отказоустойчивость строится не очень легко, в описанной схеме сам микротик у вас единая точка отказа. Если, конечно, у вас не установлен второй такой же на другого провайдера, запитанный от другого ввода электропитания и входящий в vrrp-группу с первым.
В целом в домашней сети отказоустойчивость строится не очень легко, в описанной схеме сам микротик у вас единая точка отказа. Если, конечно, у вас не установлен второй такой же на другого провайдера, запитанный от другого ввода электропитания и входящий в vrrp-группу с первым.
Тут, на мой взгляд, нужно соблюдать принцип разумной достаточности. Все навороты мною сделаны из-за невозможности прописать в микротике резервный (в практическом понимании этого слова) DNS.
Проверять PiHole DNS-запросами — правильней, но ваять специальный скрипт не вижу смысла. Пока. Если столкнусь с отказами в этой конструкции — обязательно сделаю.
А что касается единой точки отказа — у меня есть (на полке) запасной микротик :)
Проверять PiHole DNS-запросами — правильней, но ваять специальный скрипт не вижу смысла. Пока. Если столкнусь с отказами в этой конструкции — обязательно сделаю.
А что касается единой точки отказа — у меня есть (на полке) запасной микротик :)
А нельзя просто в роутере прописать DNS 1.1.1.1 и 1.0.0.1, а не проводить все эти манипуляции?
И, вроде, жёлтый-полосатый провайдер блокирует DNS, которые не принадлежат ему.
И, вроде, жёлтый-полосатый провайдер блокирует DNS, которые не принадлежат ему.
все было бы хорошо если бы работало после перезагрузки. установил, настроил, всё радовало глаз. перезагрузил и всё, более не фильтрует и ничего через неё не идёт. пытался найти ответ, почему так - пока глухо. Переустанавливать всё как то уже не красиво будет. опять таки нет гарантии что тоже до первой перезагрузки всё будет работать как и сейчас... пичалька
Проверьте, работает ли cloudflared (dig @127.0.0.1 -p 5053 google.com), вероятнее всего дело в нем. Если не работает - проверьте systemctl status cloudflared, должен быть active. Если не активный - systemctl enable cloudflared && systemctl start cloudflared
на самом деле это первое что я проверил. и все нормально. Ощущение такое что просто запросы в ягодку не идут от роутера, но в роутере всё настроено как и было...
да и вообще странно выглядит всё, писали что если ягодку выключить - то интернета не станет так DNS исчезнет, а у меня и без неё всё работает. Но роутер я не перенастраивал, может быть он сам решил что ему ягодка не нужна и забил на свои же настройки DNS? У меня "zyxel keenetic omni II"
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Переводим на DoH домашнюю сеть, или еще один щелчок по носу фильтрации