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, и дело с концами.