Перехват DNS не работает в отдельных случаях

[AltGrF13]

Пока нет решения. Оставлю подумать себе.
По сути варианты стали всплывать от тех, у кого обход работал лишь частично. Поддомены динамически не добавлялись, но т.к. основные домены прогревались при рестарте, то выглядело рабочим. Жили в режиме «работает, если периодически дёргать kvas test».

В обоих случаях правила перехвата висели верно (у одного роутер только был 192.168.2.1)

iptables -A PREROUTING -w -t nat -i br0 -p tcp --dport 53 -j DNAT --to-destination 192.168.1.1:9753
iptables -A PREROUTING -w -t nat -i br0 -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:9753

DNS и браузеры были настроены верно (добавление в ipset руками чинило ситуацию). Dnsmasq на правильном порту, с рабочими выходом и kvas.dnsmasq. У обоих в итоге можно было завести через шаманство настроек (в одном случае случай идентичен моему, когда с правильными не войти в интернет, но после входа их можно изменить, и всё работает). Но это всё не важно, ведь основной вопрос — почему правила перехвата выше не работали. Они бы избавили от необходимости колдовать с настройками.

Вроде как общее правило у одного начинало работать

iptables -A OUTPUT -w -t nat -p tcp --dport 53 -j DNAT --to 192.168.2.1:9753
iptables -A OUTPUT -w -t nat -p udp --dport 53 -j DNAT --to 192.168.2.1:9753

Но это опять даст дыру в безопасности (доступ извне).

Также можно попробовать словить на другом интерфейсе или исходящий.

[AltGrF13]

Случай 1

[AltGrF13]

Случай 2

[AltGrF13]

А. Причина работы после шаманства с настройками

Собственно, надо узнать почему: Ndhcps начинает слушать, что ему указали 192.168.1.1:9753, или что-то перестаёт мешать правилам перехвата? Т.е. надо взять починенные у людей в результате махинаций варианты, сделать там

# случай 2
iptables -D PREROUTING -w -t nat -i br0 -p tcp --dport 53 -j DNAT --to-destination 192.168.1.1:9753
iptables -D PREROUTING -w -t nat -i br0 -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:9753
# случай 1
iptables -D PREROUTING -w -t nat -i br0 -p tcp --dport 53 -j DNAT --to-destination 192.168.2.1:9753
iptables -D PREROUTING -w -t nat -i br0 -p udp --dport 53 -j DNAT --to-destination 192.168.2.1:9753

, получить скриншоты iptables-save | grep -F 53 и проверить работу списка. В "починенном" варианте наличие или отсутствие этих правил на что-то влияет?
Ожидание: не должно
Ожидание оправдалось, правильные настройки заставляли Ndhcps передавать запросы в DNSMasq в независимости от правил перехвата DNS

Б. Просто переписать PREROUTING

Хотя текущие правила почти идеальны, на мой взгляд. Но можно над ними по-разному издеваться, тестируя каждый. Вдруг так проявляется работа хардварного оптимизатора запросов, и что-то он пропустит?

1. в качестве цели указать loopback

iptables -A PREROUTING -w -t nat -i br0 -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:9753
iptables -A PREROUTING -w -t nat -i br0 -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:9753

2. заменить -i на -s с диапазоном сети

# случай 2
iptables -A PREROUTING -w -t nat -s 192.168.1.0/24 -p tcp --dport 53 -j DNAT --to-destination 192.168.1.1:9753
iptables -A PREROUTING -w -t nat -s 192.168.1.0/24 -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:9753
# случай 1
iptables -A PREROUTING -w -t nat -s 192.168.2.0/24 -p tcp --dport 53 -j DNAT --to-destination 192.168.2.1:9753
iptables -A PREROUTING -w -t nat -s 192.168.2.0/24 -p udp --dport 53 -j DNAT --to-destination 192.168.2.1:9753

3. заменить DNAT --to-destination на REDIRECT --to-ports с контролем -d (пропадёт перехват нешифрованного DNS на левые сайты, но эта опция не среди обязательных).

# случай 2
iptables -A PREROUTING -w -t nat -p tcp -d 192.168.1.1 --dport 53 -j REDIRECT --to-ports 9753
iptables -A PREROUTING -w -t nat -p udp -d 192.168.1.1 --dport 53 -j REDIRECT --to-ports 9753
# случай 1
iptables -A PREROUTING -w -t nat -p tcp -d 192.168.2.1 --dport 53 -j REDIRECT --to-ports 9753
iptables -A PREROUTING -w -t nat -p udp -d 192.168.2.1 --dport 53 -j REDIRECT --to-ports 9753

4. Любые сочетания этих замен.

В. Проба перехвата после Ndhcps

Мы сейчас пытаемся перехватывать DNS-трафик до ухода его в Ndhcps. Это оптимизированно; но если хотим ловить, например, и сегменты; то универсальнее после. Попытка этого через настройки приводит к тому, что в каждом случае своё шаманство (собственно, по этой причине и пытаемся пересесть на правила перехвата вместо настроек). Но если уж переписывать имеющиеся правила, то почему бы не замахнуться на победу над двумя проблемами сразу?

Таблица nat, как сейчас (там доступны DNAT). Цепочка или OUTPUT, если перехватывать после Ndhcps; или POSTROUTING, если хотим хватать любой нешифрованный DNS. Если критерием, опять же, ставить порт 53; то людям надо запретить использовать DoT и DoH в админке (при пути через настройки, коий сейчас используется, аналогично). Ещё из минусов, что мы захватываем DNS всех подсетей (путь через настройки, который сейчас, аналогично).

# мне
iptables -A OUTPUT -w -t nat -o eth3 -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:9753
iptables -A OUTPUT -w -t nat -o eth3 -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:9753
# случай 2
iptables -A OUTPUT -w -t nat -o ppp0 -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:9753
iptables -A OUTPUT -w -t nat -o ppp0 -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:9753
# случай 1
iptables -A OUTPUT -w -t nat -o eth2.4 -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:9753
iptables -A OUTPUT -w -t nat -o eth2.4 -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:9753

[qzeleza]

самый гибкий (если он рабочий вариант) , с моей точки зрения это:

iptables -A PREROUTING -w -t nat -s 192.168.1.0/24 -p tcp --dport 53 -j DNAT --to-destination 192.168.1.1:9753
iptables -A PREROUTING -w -t nat -s 192.168.1.0/24 -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:9753

Нет нужды в отлавливании наименования интерфейсов.

[AltGrF13]

Надо просто добраться до хоть одного устройства, у которого воспроизводится проблема. Когда поставленная из коробки бета не перехватывает DNS. Ну и проверить всю пачку вариантов. Возможно, это на какой-то из архитектур так аппаратный сетевой ускоритель отрабатывает, прокидывая мимо софтовой обработки iptables эти запросы. И с какой-то из видов записей будет работать хорошо. У нескольких человек я спросил, на днях попробую.

Пункт В я вечером проверю у себя, но это чисто ради #41. Хотя он может тоже помочь на тех случаях, что у меня не воспроизводятся.

Если не поможет в итоге ничего из этого, то останется лишь вариант возврата на 53 порт (во всех случаях DNS протекал через прокси Кинетика). Но это пока забегание вперёд, сначала нужно проверить.

[AltGrF13]

Сегодня удалось поковырять один из девайсов с нерабочим перехватом DNS. Он из нового поколения с изменённым процом, так что нюансы аппаратного ускорения явно изменились.

Никакой реакции на сочетание PREROUTING -t nat --dport 53 -j DNAT.
Оутпуты дают странный эффект: они начинают ловить примерно 1 пакет из 3ёх. При этом на домашнем, опять же, работают стабильно. Пробовалось что-то типа

ipset create localprivate hash:net -exist
ipset add localprivate 127.0.0.0/8
ipset add localprivate 10.0.0.0/8
ipset add localprivate 100.64.0.0/10
ipset add localprivate 172.16.0.0/12
ipset add localprivate 192.168.0.0/16

iptables -A OUTPUT -w -t nat -p tcp -m set ! --match-set localprivate dst --dport 53 -j DNAT --to-destination 127.0.0.1:9753
iptables -A OUTPUT -w -t nat -p udp -m set ! --match-set localprivate dst --dport 53 -j DNAT --to-destination 127.0.0.1:9753

1. Только позже дошло, что при отлове на выходе можно попробовать переписать на SNATы.
2. Также вместо PREROUTING можно попытаться закосить под системные цепочки _NDM_STATIC_SNAT.
3. Закинуть в системные _NDM_DNAT или _NDM_STATIC_DNAT
4. У некоторых видел домаркировку для Кинетика -m ndmmark --ndmmark 0x4/0x0, возможно это как раз позволит пройти аппаратку. Процентов на 80 уверен, что виновата она; на новом железе вмешивается больше. Но использовать именно это — пальцем в небо (закос под системный SNAT). Как получить заведомо правильную маркировку, чтобы аппаратное ускорение правило не теряло; я не знаю. Можно создать DNAT подсети и подсмотреть маркировку там. Ещё замечено, что их системные DNAT перенаправляют на их технический 78.47.125.180.
5. Переписать всё на свои цепочки.
6. Также можно поиграться с приоритетом PREROUTING -t nat --dport 53 -j DNAT. Вдруг есть сработки раньше, судя по iptables -L -t nat > /opt/tmp/iptables_nat.txt

iptables -I PREROUTING 1 -w -t nat -i br0            -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:9753
iptables -I PREROUTING 1 -w -t nat -i br0            -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:9753
iptables -I PREROUTING 1 -w -t nat -s 192.168.1.0/24 -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:9753
iptables -I PREROUTING 1 -w -t nat -s 192.168.1.0/24 -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:9753

[AltGrF13]

Немного на тему #195 ещё. Вот в этом вопросе я рассказывал, что какие бы настройки не указывал в админке в разделе /internet-filter/dns-configuration, у меня ndnproxy никогда не отправлял запросы в 192.168.1.1:9753. У некоторых же проставление настроек там и немного шаманства — и Keenetic в Dnsmasq запросы начинал передавать даже без iptables перехватов. Поэтому и пошёл в сторону перехватов iptables, потому что путём настроек стабильности добиться не удавалось (здесь с новыми роутерами тоже оказалась засада, но сообщение не об этом).

Сейчас подёргал в API show dns-proxy. Там в большом строковом параметре есть кусок с dns_server. Дык вот, для такого

там

dns_server = 192.168.112.1 .
dns_server = 8.8.8.8 .
dns_server = 8.8.4.4 .
dns_server = 77.88.8.1 .
dns_server = 1.0.0.1 .

Если добавим

становится

dns_server = 192.168.112.1 .
dns_server = 8.8.8.8 .
dns_server = 8.8.4.4 .
dns_server = 192.168.1.1:9753 .
dns_server = 77.88.8.1 .
dns_server = 1.0.0.1 .

У меня нигде в настройках нет этого самого 8.8.4.4. Opkg чистый. Если я сохраняю файл конфигурации роутера, то там тоже 8.8.4.4 нигде не упоминается. Нет ни на одной странице настроек! По find / -name ndnproxy находим /tmp/ndnproxymain.conf, в котором эта истинная очерёдность видна. Как только этим рулить — не понятно. Если зайти с этой стороны, то перехваты на iptables могут оказаться и не нужны. Если научиться подсовывать 192.168.1.1:9753 повыше.

Вызвал no ip name-server 8.8.8.8

			"status": "message",
			"code": "22544585",
			"ident": "Dns::Manager",
			"message": "name server 8.8.8.8, domain (default) deleted."

Аналогично с 8.8.4.4. Записи пропадают. И даже 192.168.112.1, который нельзя. Получаем:

dns_server = 192.168.1.1:9753 .
dns_server = 77.88.8.1 .
dns_server = 1.0.0.1 .

После этого на странице с интернет-провайдером пробую указать ещё раз порядок

И в конфиге опять

dns_server = 192.168.112.1 .
dns_server = 8.8.8.8 .
dns_server = 8.8.4.4 .
dns_server = 192.168.1.1:9753 .
dns_server = 77.88.8.1 .
dns_server = 1.0.0.1 .

Он обратно восстанавливает всё это. Т.е. я могу за счёт no ip name-server загнать 192.168.1.1:9753 в верх списка. Но малейшее изменение настроек или перезагрузка роутера — и он в приоритете опускается на 4 место. Так, собственно, он у меня и не отрабатывает. И люди произвольно настройки натыкивают, у них она начинает работать. А у кого-то никак (если мы говорим о перехвате через настройки, а не через iptables). Как минимум, становится понятно, у кого через настройки будет работать, а у кого — нет. Из этого файла, там истинный приоритет.

[qzeleza]

Полагаю, что это проблема и недочет в самой прошивке.
У меня периодически перестает работать ip:5793, подмечал уже не раз.

Для окончательной проверки надо бы попробовать в старой версии - до 4.1

[qzeleza]

На время, можно в крон поставить обновление dns_server = 192.168.1.1:9753, только вот период надо понять какой поставить.

Но это "костыль", конечно.

[AltGrF13]

Но это "костыль", конечно

Кроме этого, боюсь, какие-то из тоннелей перестанут работать после no ip name-server. Ща походил, повырубал всё на роутере. Если выключить WireGuard, то он перестаёт докидывать Гугловые. 192.168.112.1 после отказа от рабочих L2TP/IPsec.

ndnproxy глубоко зашит в прошивку, обслуживает все из видов туннелей. И, видимо, на лету собирает свой приоритет: сначала для туннелей; потом, что указано в настройках. И в дальнейшей работе, встретив общественный для туннеля, DNS-трафик уходит туда. Забивая на истинные настройки в разделе «Профили DNS», они для него вторичны.

[AltGrF13]

Четвёртый способ с маркировкой одолеть не смог. Шестое из предположений завелось; но, как и с аутпутом, работа была не стабильна у одного человека:

залетает живенько. Но не все. Тот же myip2.ru вообще ни в какую. Но многие открываются сразу.
Опять таже история - тишина, тишина, минут через несколько все залетели и открылись
Но именно все разом и через некоторое время
В общем это работает намного лучше. Да, вроде как есть пропуски. Но в целом со временем все попадают в таблицу.

В любом случае, до этого у человека вообще не работало. Нужно будет собрать очередную версию, и проверить с такими правилами. Завтра пришлю патч.

Ещё понял, что отлов DNS на выходе/аутпутах может иметь проблемы, т.к. ndnproxy имеет свой кэш и навскидку не увидел, как это отключить. А у нас из-за такой прослойки ipset не заполнится. Так что решений вопроса меньше, чем предположил в начале. Только прероутинг.

Рубрика странности Кинетика: вот мы свои правила помещаем под системными. Если посмотреть в системный NAT iptables -L -t nat > /opt/tmp/iptables_nat.txt, то там пусто выше нас (в цепочках _NDM_DNAT и иже с ними). Что на моём роутере, что на проблемном. Но на моём роутере правила отрабатывают, а на новых одна из цепочек заполнена невидимыми нам правилами, которые и не дают до них дойти. Как пишет техподдержка на форуме в схожих темах, а зачем вам это видеть? В общем, iptables очень закостыленный под себя. И сейчас будем залазить выше системного _NDM_DNS_REDIRECT.

[AltGrF13]

Текущая доработка #221 меняет приоритет так. Можем сделать ещё на шаг выше.

[AltGrF13]

Из интересного на будущее ещё по поводу настроек DNS из админки. Вот у человека указаны куча DNS и добавлен один DoT. Согласно доке, тогда нешифрованные DNS игнорируются. И это реально так, остался один dns_server. Но интересно другое: у него обращение к внешнему DNS идёт через редирект на порт 40500 в роутере. Вот как выглядит ndnproxymain.conf

Не удивлюсь, что какой-то такой механизм и докидывает свои скрытые правила редиректа ДНС, поэтому до наших (до повышения приоритета) не доходило.

[AltGrF13]

Статистика среди опрошенных шла примерно как у 8 работало, у 4 новые изменения позволили начать работать динамическим спискам. Поэтому задачу закрыл.

Сейчас всплыли двое с неработой динамического ipset (Hero 4G KN-2310, DSL KN-2010). Пока что плохо, что они не провели список проверки (повышение приоритета, смена порта, смена ДНС). Но т.к. случаи есть, то можно таким людям вернуть старый режим, как в предыдущей версии. Тот механизм завернул в команду kvas ipset refill (#224).
UPD. Возможно поспешил, в сборке был баг в /opt/etc/dnsmasq.d/kvas.dnsmasq символы \. вместо . После правки этих двоих переспрошу. Но это не делает этот PR не нужным, как и clear это прекрасная сервисная команда
UPD2. Подтверждено, у обоих в списке типа ipset=/bard\.google\.com/kvas_ipset после импорта, поэтому не работало.

Альтернативный режим

Можно дописать к kvas ipset refill интерактивную команду типа kvas ipset cron с выбором режимов never, hourly, daily. У всех по умолчанию never, но люди с не рабочим заполнением IPSet могут включить себе иной. Выполнение команды запустит внутри себя kvas ipset refill, удалит (если есть) /opt/etc/cron.hourly/ipset_refill.sh и /opt/etc/cron.daily/ipset_refill.sh, а после этого разместит в /opt/etc/cron.${period}/ipset_refill.sh (с правами на выполнение)

#!/bin/sh
kvas ipset refill &>/dev/null

Ещё надо будет, если реализовывать это:

1. В установку и удаление пакета нужно добавить проверку /opt/etc/cron.hourly/ipset_refill.sh и /opt/etc/cron.daily/ipset_refill.sh и удаление, если есть.
2. При выводе команды kvas ipset добавить строчку Периодический обход. В зависимости от наличия соответствующего файла там будет Отключен, Ежечасно, Ежедневно.