ValdikSS

Если бы было именно так, то и проблемы бы не было. А проблема в том, что запросы на любой_ip_адрес:53 перенаправляются на 192.168.1.1:53.

Не работает! Применил opkg dns-override, сохранил конфигурацию, перезагрузился, на всякий случай дважды, убедился, что в выводе show run есть строка opkg dns-override, и всё равно перехватывающие правила есть.

Перехват есть, 4.1.2. Вероятно, у вас иная конфигурация, для которой перехват не применяется. См. https://forum.keenetic.com/topic/16431-неотключаемый-перехват-dns-запросов-в-отдельном-сегменте/?do=findComment&comment=167233 # iptables-save | grep _NDM_HOTSPOT_DNSREDIR :_NDM_HOTSPOT_DNSREDIR - [0:0] -A _NDM_DNS_REDIRECT -j _NDM_HOTSPOT_DNSREDIR -A _NDM_HOTSPOT_DNSREDIR -i br0 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br0 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br0 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i br0 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 5351 -j REDIRECT --to-ports 41301 -A _NDM_HOTSPOT_DNSREDIR -i br0 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 5351 -j REDIRECT --to-ports 41301 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i br2 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br2 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br2 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i br2 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 5351 -j REDIRECT --to-ports 41301 -A _NDM_HOTSPOT_DNSREDIR -i br2 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i ovpn_br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i ovpn_br1 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i ovpn_br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i ovpn_br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 5351 -j REDIRECT --to-ports 41301 -A _NDM_HOTSPOT_DNSREDIR -i ovpn_br1 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 1900 -j REDIRECT --to-ports 41300

Как это относится к обсуждаемой теме?

Например, nslookup ya.ru 3.3.3.3 Эта команда выполнит лукап ya.ru через резолвер на IP-адресе 3.3.3.3. На этом адресе нет резолвера, при обычной настройке команда должна завершаться с ошибкой. Если же выдаётся IP-адрес домена ya.ru — запрос был перехвачен роутером.

Недостаток этой конфигурации в том, что любое изменение WAN через веб-интерфейс убирает надстройки. Ответ техподдержки: Gi0 — порты LAN 1-4 (WAN — отдельный интерфейс, а не порт на свитче, по крайней мере, на Keenetic Viva 1910).

Если задача только в предоставлении клиентам локальной сети доступа до указанного диапазона, то она решается добавлением маршрутов на машины клиентов локальной сети. Сделать это можно через DHCP, опции 121 и 249. ip dhcp pool _WEBADMIN option 121 192.168.2.0/24,192.168.1.100 ip dhcp pool _WEBADMIN option 249 192.168.2.0/24,192.168.1.100

Столкнулся с такой же задачей: сделать router-on-a-stick на WAN-порту Viva 1910. LAN (Home) сегмент должен передаваться в VLAN1 WAN-порта (GigabitEthernet1). Решил так: (config)> interface GigabitEthernet1/Vlan1 Network::Interface::Repository: "GigabitEthernet1/Vlan1" interface created. (config-if)> security-level private Network::Interface::L3Base: "GigabitEthernet1/Vlan1": security level set to "private". (config-if)> up Network::Interface::Base: "GigabitEthernet1/Vlan1": interface is up. (config-if)> exit Core::Configurator: Done. (config)> interface Bridge0 Core::Configurator: Done. (config-if)> include GigabitEthernet1/Vlan1 Network::Interface::Bridge: "Bridge0": GigabitEthernet1/Vlan1 included. (config-if)> (config-if)> exit Core::Configurator: Done.

Обновился до 4.0.4, у меня ничего не изменилось — как перехватывались запросы, так и продолжают, независимо от галочки «транзит запросов». Устройство перезагружал. Что нужно сделать, чтобы отключить перехват?

Я пробовал все возможные настройки и не смог отключить перехват DNS. Выключал все возможные фильтры, удалял компонент «Фильтрация контента и блокировка рекламы при помощи облачных сервисов», без которого вообще нет галочки транзита DNS (в надежде, что именно этот компонент перехватывает запросы и сбоит) — без толку. Обращение в техподдержку завёл до этой темы, отправил selftest. Пока без ответов. Шаги воспроизведения: Настроить клиент WireGuard с перенаправлением всего трафика (разрешенные подсети: 0.0.0.0/0), задать в настройках подключения адрес DNS 8.8.8.8 В разделе "приоритеты подключений" создать политику доступа "vpn" Настроить отдельный сетевой сегмент "vpn", с выделенными сетями Wi-Fi для сегмента, включить в сегменте DHCP и NAT, указать политику "vpn" Подключаемся к этой сети с незарегистрированного компьютера. Выполняем на компьютере резолв DNS через адрес, на котором нет DNS-резолвера (например, 6.6.6.6): nslookup ya.ru 6.6.6.6 Результат: DNS-ответ успешно возвращается. Ожидаемый результат: Таймаут DNS-запроса.

Нет, не поможет. Отключения туннеля никак не связаны с conntrack.

Не знаю, как это должно помочь. У меня нет NAT, и проблема не сетевая.

Это также не работает из-за перехвата трафика. Вернее, эти настройки работают ровно так, как и должны: выдают заданный DNS-сервер по DHCP, только перехват от этого не отключается. Независимо от того, какой адрес там указан (может быть и такой, на котором DNS-резолвера вовсе нет), DNS-запросы будут идти через кеширующий резолвер роутера. Посмотрите на правило iptables выше — оно просто перехватывает все запросы на порт 53 UDP/TCP на внутренний резолвер.

Указать конкретный интерфейс можно только в системном профиле. Запись DNS VPN'а и так указана с интерфейсом, если её удалить — резолвинг в сегменте перестаёт работать. Интерфейс у резолверов, добавляемых в отдельный профиль DNS, назначить нельзя. Да и вообще, они, похоже, никак не используются: резолвинг идёт только через адрес, прописанный в настройках VPN-подключения, а не где либо еще. Несмотря на то, что у меня заведён отдельный профиль DNS, который назначен сегменту, адреса из профиля банально не используются. Для теста я указываю 8.8.8.8 и 8.8.4.4, которые доступны через все интерфейсы. Уже пробовал добавлять маршруты до этих адресов через VPN-интерфейс — не помогает. Проблема в том, что я не могу отключить перехват запросов. Мне вообще в этом сегменте не нужен кеширующий резолвер роутера (и соответствующие настройки на роутере), я бы просто выдавал сторонний адрес через DHCP, и дело с концами.

WireGuard, везде указано IP-адресами.

# iptables -t nat -vnL ... Chain _NDM_HOTSPOT_DNSREDIR (1 references) ... 1122 70308 REDIRECT udp -- br2 * 0.0.0.0/0 0.0.0.0/0 mark match 0xffffd00 PKTTYPE = unicast udp dpt:53 redir ports 41100 4 208 REDIRECT tcp -- br2 * 0.0.0.0/0 0.0.0.0/0 mark match 0xffffd00 PKTTYPE = unicast tcp dpt:53 redir ports 41100 После удаления этих правил всё работает корректно.

Уже установлено. ! dns-proxy rebind-protect auto filter profile DnsProfile0 description VPN filter profile DnsProfile0 dns53 upstream 8.8.8.8 filter profile DnsProfile0 dns53 upstream 8.8.4.4 filter profile DnsProfile0 intercept no enable filter assign interface profile Bridge2 DnsProfile0 filter engine public !

Как только я удаляю DNS-сервер из стандартного профиля, DNS-резолвинг перестаёт работать в сегменте VPN, независимо от того, что указано в профиле DNS, который я назначаю сегменту VPN. Я уже и совершенно разные адреса указал, и маршруты через VPN-интерфейс до них прописал — ничего. Единственное изменение только в том, что локальный резолвер теперь мне отвечает REFUSED, вместо просто отсутствия ответа. Баг я завёл еще вчера, пока никто не ответил, поэтому написал сюда.

Установил компонент, включил «Публичные DNS-резолверы и настраиваемые профили» в «Режиме фильтрации». Для всех сегментов указан единственный «Системный» профиль DNS, у которого включён транзит. Результат: в стандартном «домашнем» сегменте всё работает корректно, в сегменте VPN — перехват запросов и перенаправление на VPN-резолвер (который стоит последним в списке системного профиля DNS) через кеширующий резолвер на роутере. Создал отдельный профиль DNS со включённым транзитом, указал в нём единственный DNS-резолвер, задал сегменту использовать этот профиль, перезагрузил роутер — запросы в VPN-сегменте всё так же перехватываются. Устройства в VPN-сегменте все незарегистрированные.

У меня нет профилей DNS. Они были раньше (с ними была та же проблема), за них отвечает компонент «Фильтрация контента и блокировка рекламы при помощи облачных сервисов». Сейчас только один, системный. Транзит также опция компонента «Фильтрация контента и блокировка рекламы при помощи облачных сервисов». От его включения и выключения ничего не менялось. Сейчас же, после удаления компонента, опции транзита нет, тем не менее, запросы перехватываются.

Ничего не изменилось.

Не могу понять, каким образом можно отключить перехват (перенаправление) DNS-запросов на внутренний кеширующий резолвер роутера. У меня настроен отдельный сегмент сети, в который я подключаюсь через отдельную сеть Wi-Fi. В сегменте установлена отдельная политика доступа, в которую помещён только WireGuard VPN с перенаправлением всего трафика в туннель. Проблема заключается в том, что все DNS-запросы от клиентов в этом сегменте на любой IP-адрес и порт 53 перенаправляются на внутренний резолвер роутера, на тот IP-адрес, который указан в секции «Профили DNS» раздела «Интернет-фильтр» для интерфейса WireGuard. Если удалить DNS для интерфейса WireGuard из «Профилей DNS», то DNS на клиентах сегмента перестаёт работать вовсе, независимо от адреса DNS-сервера. Иными словами, указав какой-то конкретный DNS в настройках подключения WireGuard (он автоматически дублируется в «Профили DNS»), на клиентских машинах возможно использование только этого DNS, причём трафик до него идёт через внутренний резолвер роутера. Если не указывать никакого DNS в настройках WireGuard, а настроить DNS на компьютерах в сегменте вручную, то DNS-резолв не работает ни на какие адреса. Изначально у меня был установлен компонент «Фильтрация контента и блокировка рекламы при помощи облачных сервисов», но после его удаления ничего не изменилось. Viva (KN-1910) RU, ОС 3.9.8.

Поотлаживал еще. Баг заключается в том, что туннель, после того, как сессия WireGuard «закрылась» (прошло 180 секунд с последнего handshake), не поднимается, когда клиент сегмента начинает отправлять пакеты в туннель. Если отправить какой-либо пакет с самого роутера (например, ping'ом через CLI), либо же с сервера — туннель сразу же поднимается. Некорректно работает какая-то подсистема, возможно, fastvpn.

Добавил, заменив только порт на тот, что указан как listening в настройке клиента. Увы, ничего не поменялось: 187 секунд и серый значок, при том, что какой-то трафик в течение 187 секунд в туннеле ходил (ACK'и и FIN-ACK'и от незакрытых соединений), но он не обновляет счётчик latest handshake.