ValdikSS

Похоже, я столкнулся с этой проблемой во время отладки Wi-Fi-чипа на своём устройстве. Отлаживал 2 суток, был уверен, что проблема в прошивке чипа, но перезагрузка роутера решила проблему и она ушла бесследно (пока что). До перезагрузки аптайм роутера был около 30 дней. Подробности здесь: https://github.com/orangepi-xunlong/linux-orangepi/issues/98#issuecomment-5376727263 (это сообщение и ниже) Коротко: пока клиент в активном режиме, весь трафик ходит без проблем. Но как только клиент уходит в сон, отправляя Null data frame с флагом PWR MGT = 1 в сторону точки, multicast-трафик «перестаёт приходить» клиенту, любой, включая ARP-запросы. У меня нет записи трафика, чтобы понять, не приходили ли пакеты или приходили неправильные, но так как здесь выше выложили скриншоты с ошибками MIC, я подозреваю, что проблема как-то связана с пересогласованием GTK и/или с буферизацией multicast-трафика во время сна клиента (во время тестирования я отключал PMF, использовался WPA2-PSK). Во время тестирования клиент, конечно же, бесчисленное количество раз перезагружался, переаутентифицировался на точке, и ничего не помогало. Клиент был отключён часами, и проблема не уходила. Поэтому подозреваю, что где-то как-то неправильно кешируется состояние определённого MAC-адреса в драйвере (MAC клиента сменить не додумался). После перезагрузки роутера тестировал смену GTK в разных режимах (ставил время смены ключа в 5 минут, по умолчанию оно выполняется каждые 24 часа), проблему воспроизвести не удалось (уже неделя прошла).

@grishairk у вас установлен автовыбор канала 5 ГГц? Зафиксируйте на каком-то обычном, 44, например. Если поможет, то в Samsung используется другой/устаревший crda.

В IPv6 адрес источника и адрес назначения имеет значительный вес и в выборе адреса, с которого подключаться (их легко может быть 10 на интерфейсе), и в приоритете адреса, к которому подключаться. ULA source address имеет приоритет ниже, чем IPv4 source. Если вы открываете обычный сайт, у которого A (IPv4) и AAAA (IPv6) записи на домене (IPv6 глобальный, разумеется), подключение будет устанавливаться через IPv4. IPv6 будет использоваться только для IPv6-only сайтов (даже у ULA-ULA приоритет ниже, чем IPv4-IPv4). Потому что с точки зрения спецификации ULA-адреса считаются предназначенными для локальной сети, и нет резона их использовать при подключении к GUA-адресам. Приоритеты заложены во все операционные системы и меняются только на стороне клиента, а не роутера/сервера. https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/ https://www.infoblox.com/blog/ipv6-coe/ula-is-broken-in-dual-stack-networks/

На Viva (KN-1910) используется Beacon Interval = 100, DTIM Interval = 1 (клиентам просыпаться каждый beacon). Я бы хотел выставить DTIM Interval = 3, чтобы телефоны и другие батарейные устройства слушали броадкаст/мультикаст каждые 300 мс, а не 100, а нельзя! Правда, моё устройство сообщает Listen Inteval = 3, что и так фактически устанавливает его в 3 для этого устройства.

В прошивке 5.1.1 перестали работать старые параметры, которые ранее работали. После обновления существующие asc просто пропали, и заново вернуть их не получается: (config)> interface Wireguard0 wireguard asc 16 60 360 0 0 0 0 0 0 Wireguard::Interface error[75507312]: "Wireguard0": invalid ASC parameters. С внедрением нового синтаксиса старые настройки не применяются. Откатился на версию 5.0.12 — проблема ушла, снова могу устанавливать параметры и подключаться. Написал в поддержку об этой проблеме.

В моём случае, при наличии поддержки роуминга + включённого band steering, у uwe5622 едет крыша и он перестаёт ассоциироваться с любыми сетями. Проще всего разделить сети 2.4 ГГц и 5 ГГц (дать им разные названия), это решит проблему.

У меня есть устройства с Wi-Fi-адаптером Allwinner AW859A / Cdtech 20U5622, с чипом uwe5622, у которых также проблемы при включённом 802.11r на Keenetic. Пытаюсь понять, связанные ли это проблемы, потому что сейчас отлаживаю драйвер uwe5622 на стенде с двумя Keenetic, объединёнными в mesh.

Только 2.4.

Вы можете разобрать что-либо из этого и посмотреть, какой Wi-Fi-чип установлен?

Если бы было именно так, то и проблемы бы не было. А проблема в том, что запросы на любой_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, и дело с концами.