ValdikSS
-
Posts
60 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by ValdikSS
-
-
12 минуты назад, Denis P сказал:
Конкретно в моем случае речь про
opkg dns-override
Не работает! Применил opkg dns-override, сохранил конфигурацию, перезагрузился, на всякий случай дважды, убедился, что в выводе show run есть строка opkg dns-override, и всё равно перехватывающие правила есть.
-
21 минуту назад, Denis P сказал:
утверждение было актуально на момент его публикации.
но таки проверил на актуальной 4.1.2 - никакого перехвата нет
Перехват есть, 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
-
2 минуты назад, Petrak сказал:
Спасибо за статью, а если вас не затруднит, вы не могли бы привести наглядный пример как работает перехват провайдером?
Как это относится к обсуждаемой теме?
-
38 минут назад, Petrak сказал:
А как вообще проверить перехват? Какие команды для этого нужны?
Например,
nslookup ya.ru 3.3.3.3Эта команда выполнит лукап ya.ru через резолвер на IP-адресе 3.3.3.3. На этом адресе нет резолвера, при обычной настройке команда должна завершаться с ошибкой. Если же выдаётся IP-адрес домена ya.ru — запрос был перехвачен роутером.
-
Недостаток этой конфигурации в том, что любое изменение WAN через веб-интерфейс убирает надстройки.
Ответ техподдержки:
ЦитатаДобрый день. Если делаете что-то через cli, то через веб уже это править нельзя. Такая пока концепция. Вы можете переехать на Gi0 и там такого поведения не должно быть.
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.
-
1
-
-
В 08.07.2023 в 06:25, ANDYBOND сказал:
В версии 4.0.0 исправлено. Спасибо. Да, изменения вступают в силу только после перезагрузки маршрутизатора, но для меня это некритично. Или интерфейс перезапустить, но этот метод я не практикую: предпочитаю перезагрузку.
Обновился до 4.0.4, у меня ничего не изменилось — как перехватывались запросы, так и продолжают, независимо от галочки «транзит запросов». Устройство перезагружал. Что нужно сделать, чтобы отключить перехват?
-
Цитата
Добрый день. Удалось выяснить, что для политик перехват не отключается. Сделано специально чтобы не утекли запросы не туда, потому нужно запросы в политику перехватить и отправить на свой, особый экземпляр dns-proxy Я создам идею, чтобы этот функционал был хотя бы управляемым через cli. Спасибо
-
19 минут назад, corniger сказал:
Пожалуйста, если вы идите другое поведение, опишите как воспроизвести. Здесь или в обращении в Техническую поддержку.
Я пробовал все возможные настройки и не смог отключить перехват 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-запроса.
-
Только что, ANDYBOND сказал:
Но пользователям Кинетика это поможет, если что.
Нет, не поможет. Отключения туннеля никак не связаны с conntrack.
-
23 минуты назад, ANDYBOND сказал:
Кардинальное решение такое
Не знаю, как это должно помочь. У меня нет NAT, и проблема не сетевая.
-
1 минуту назад, ANDYBOND сказал:
Как вариант на сегодня и сейчас: указать гуглевские DNS первым способом (в DHCP сегмента) в статье: https://help.keenetic.com/hc/ru/articles/360011440720
Это также не работает из-за перехвата трафика. Вернее, эти настройки работают ровно так, как и должны: выдают заданный DNS-сервер по DHCP, только перехват от этого не отключается. Независимо от того, какой адрес там указан (может быть и такой, на котором DNS-резолвера вовсе нет), DNS-запросы будут идти через кеширующий резолвер роутера. Посмотрите на правило iptables выше — оно просто перехватывает все запросы на порт 53 UDP/TCP на внутренний резолвер.
-
7 минут назад, ANDYBOND сказал:
https://help.keenetic.com/hc/ru/articles/6179082606994-Дополнительные-DNS-серверы
Иными словами, все DNS используют любой сетевой интерфейс - и тогда ничего не работает как надо. Попробуйте добавить нужные DNS с указанием конкретного интерфейса, который каждый из них может использовать (подробнее по ссылке). На принадлежность профилю это не влияет.
Указать конкретный интерфейс можно только в системном профиле. Запись DNS VPN'а и так указана с интерфейсом, если её удалить — резолвинг в сегменте перестаёт работать.
Интерфейс у резолверов, добавляемых в отдельный профиль DNS, назначить нельзя. Да и вообще, они, похоже, никак не используются: резолвинг идёт только через адрес, прописанный в настройках VPN-подключения, а не где либо еще. Несмотря на то, что у меня заведён отдельный профиль DNS, который назначен сегменту, адреса из профиля банально не используются.
Для теста я указываю 8.8.8.8 и 8.8.4.4, которые доступны через все интерфейсы. Уже пробовал добавлять маршруты до этих адресов через VPN-интерфейс — не помогает.
Проблема в том, что я не могу отключить перехват запросов. Мне вообще в этом сегменте не нужен кеширующий резолвер роутера (и соответствующие настройки на роутере), я бы просто выдавал сторонний адрес через DHCP, и дело с концами.
-
5 минут назад, ANDYBOND сказал:
А как указан адрес сервера в VPN (буквенный или числовой)? И о каком протоколе речь?
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После удаления этих правил всё работает корректно.
-
1 минуту назад, Denis P сказал:
dns-proxy intercept no enable
Уже установлено.
! 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 ! -
1 минуту назад, ANDYBOND сказал:
В каждом профиле серверы должны быть разные, иначе они (повторяющиеся) будут использоваться для основного (в конкретный момент) подключения.
Как только я удаляю DNS-сервер из стандартного профиля, DNS-резолвинг перестаёт работать в сегменте VPN, независимо от того, что указано в профиле DNS, который я назначаю сегменту VPN.
Я уже и совершенно разные адреса указал, и маршруты через VPN-интерфейс до них прописал — ничего. Единственное изменение только в том, что локальный резолвер теперь мне отвечает REFUSED, вместо просто отсутствия ответа.
Баг я завёл еще вчера, пока никто не ответил, поэтому написал сюда.
-
8 минут назад, ANDYBOND сказал:
Даже после перезагрузки маршрутизатора (на примере системного профиля)? Просто бага в том, что перезагрузка нужна, чтоб изменения вступили в силу.
Установил компонент, включил «Публичные DNS-резолверы и настраиваемые профили» в «Режиме фильтрации». Для всех сегментов указан единственный «Системный» профиль DNS, у которого включён транзит.
Результат: в стандартном «домашнем» сегменте всё работает корректно, в сегменте VPN — перехват запросов и перенаправление на VPN-резолвер (который стоит последним в списке системного профиля DNS) через кеширующий резолвер на роутере.
Создал отдельный профиль DNS со включённым транзитом, указал в нём единственный DNS-резолвер, задал сегменту использовать этот профиль, перезагрузил роутер — запросы в VPN-сегменте всё так же перехватываются.
Устройства в VPN-сегменте все незарегистрированные.
-
7 минут назад, ANDYBOND сказал:
Более приоритетной настройкой в тех же профилях DNS является настройка соотношения сетей или даже конкретных зарегистрированных устройств с определённым профилем DNS
У меня нет профилей DNS. Они были раньше (с ними была та же проблема), за них отвечает компонент «Фильтрация контента и блокировка рекламы при помощи облачных сервисов». Сейчас только один, системный.
8 минут назад, ANDYBOND сказал:В системном профиле транзит разрешён по умолчанию.
Транзит также опция компонента «Фильтрация контента и блокировка рекламы при помощи облачных сервисов». От его включения и выключения ничего не менялось. Сейчас же, после удаления компонента, опции транзита нет, тем не менее, запросы перехватываются.
-
10 минут назад, ANDYBOND сказал:
no ppe hardware
no ppe software
system configuration save
Это через CLI. И, получается, если после этого перезагрузить маршрутизатор, то проблема должна исчезнуть. Но это предположение: при возможности прошу проверить.
Ничего не изменилось.
-
1
-
-
Не могу понять, каким образом можно отключить перехват (перенаправление) 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.
-
1
-
-
15 минут назад, Denis P сказал:
Попробуйте указать принудительно (с учетом вашего порта и интерфейса естественно)
Добавил, заменив только порт на тот, что указан как listening в настройке клиента. Увы, ничего не поменялось: 187 секунд и серый значок, при том, что какой-то трафик в течение 187 секунд в туннеле ходил (ACK'и и FIN-ACK'и от незакрытых соединений), но он не обновляет счётчик latest handshake.
-
1
-
Неотключаемый перехват DNS-запросов в отдельном сегменте
in Обмен опытом
Posted
Если бы было именно так, то и проблемы бы не было.
А проблема в том, что запросы на любой_ip_адрес:53 перенаправляются на 192.168.1.1:53.