qmxocynjca

Гляньте, пожалуйста, в startup-config, сколько у вас уникальных двухбуквенных значений ft mdid <...> найдётся?

Получилось через CLI задать ft mdid на нужных точках, т.е. диапазоны одной сети объединились, но выглядит так что максимум может быть 3 уникальных значения ft mdid. Если больше - ошибка.

5.0.1. Можете проверить что в основном и доп сегменте у вас действительно в веб показывает что роуминг включен и на 2.4 и на 5ггц? Я могу в одном сегменте включить на оба диапазона, а в других только что-то одно сохраняется - или 2.4 или 5. Некоторые сети явно с отдельными именами, но у меня меш и задача иметь роуминг между точками.

Есть три сети, в каждой по два диапазона. Включить FT на всех сетях между всеми диапазонами нельзя что ли? Какие-то ограничения железа или что это? Отваливается с ошибкой, когда пытаюсь включить FT на более чем 3-х WiFi интерфейсах: mtkiappd too many AP interfaces (3)

В списке ретрансляторов надо нажать галочку на нужном и появится кнопка настроек. Это очень неочевидно, сам обнаружил буквально сегодня.

На контроллере в настройках ретранслятора можно менять привязку порта к сети.

Ситуация: 1. DoT DNS1, указано ходить через ISP1. 2. DoT DNS2, указано ходить через ISP2. 3. Есть отдельная политика только с ISP2. Ожидаю что в этой политике будет использоваться только DNS2, а по факту используются оба. Так задумано или что-то не работает?

5.0.1. Включаю SNTP, жму сохранить, обновляю страницу, получаю: По ощущениям сервер работает, порт 123 открыт, запросы к нему обрабатываются.

Чтобы браузеры не шарили хранилище между a.keenetic.link и b.keenetic.link, есть специальный лист, в который можно добавить верхний домен. Браузер будет использовать это для разделения сайтов и их хранилищ по субдоменам. Пожалуйста, озаботьтесь этим и добавьте все верхние домены, которые используются в Keen/NetcrazeDNS в этот лист. Это должен делать владелец доменов. Сейчас ситуация достаточно неприятная, когда сервисы с одного субдомена внезапно могут пошарить свои данные на другом субдомене, т.к. браузеру никто не сказал что это по сути динамический DNS, который нужно разграничивать. https://publicsuffix.org/ https://publicsuffix.org/submit/

@Le ecureuil К первоначальной проблеме: воспроизвелось, но теперь уже на 5.0.1. Трейс по интересующему домену опять не ведёт куда нужно. Делаю запрос с устройства в дефолтной политике: nslookup www.youtube.com Server: ... Address: 192.168.1.1 Non-authoritative answer: Name: wide-youtube.l.google.com Addresses: 2a00:1450:4010:c03::c6 209.85.233.198 Aliases: www.youtube.com youtube-ui.l.google.com Адрес не появляется в show object-group fqdn для интересующего домена: "fqdn": "www.youtube.com", "type": "runtime", "deadline4": 12779, "deadline6": 1531545, "fail-counter4": 0, "fail-counter6": 0, "last-external": 88586, "last-list-changed": 88586, "parent": "youtube.com", "ipv4": [ { "address": "74.125.131.198", "ttl": 249, "last-updated": 79343 }, { "address": "74.125.205.198", "ttl": 162, "last-updated": 89695 }, { "address": "108.177.14.198", "ttl": 271, "last-updated": 91759 }, { "address": "142.250.150.198", "ttl": 278, "last-updated": 94667 }, { "address": "142.251.1.198", "ttl": 260, "last-updated": 87750 }, { "address": "173.194.221.198", "ttl": 218, "last-updated": 88125 } ], "ipv6": [ { "address": "2a00:1450:4010:c02::c6", "ttl": 147, "last-updated": 46964 }, { "address": "2a00:1450:4010:c0a::c6", "ttl": 285, "last-updated": 88109 }, { "address": "2a00:1450:4010:c0e::c6", "ttl": 135, "last-updated": 82176 }, { "address": "2a00:1450:4010:c0f::c6", "ttl": 151, "last-updated": 91653 }, { "address": "2a00:1450:4010:c1c::c6", "ttl": 250, "last-updated": 94667 }, { "address": "2a00:1450:4010:c1e::c6", "ttl": 206, "last-updated": 87773 } ] dot прокси на роутере отвечает нормально: В конфиге ndnproxy: dns_server = 127.0.0.1:40500 . # 77.88.8.8:853@common.dot.dns.yandex.net $ nslookup www.youtube.com 127.0.0.1:40500 Server: 127.0.0.1 Address 1: 127.0.0.1 localhost Name: www.youtube.com Address 1: 209.85.233.198 lr-in-f198.1e100.net Address 2: 2a00:1450:4010:c03::c6 lr-in-f198.1e100.net Другие адреса добавились, а этот не хочет. Что примечательно, ipv6 адрес тоже отсутствует в списке.

Добавляем любой домен в include, идем на субдомен, видим что он добавился в "show object-group fqdn", добавляем его в exclude, видим что он появился в "excluded-fqdns", но при этом он так же висит в массиве "entry" и маршрутизация всё так же идёт по правилам dns. "show rc object-group fqdn" также показывает все верно - видны оба списка include и exclude с нужными доменами. "group": [ { "group-name": "domain-list5", "enabled": true, "ipv4-addresses-count": 8, "ipv6-addresses-count": 8, "fqdn-count": 2, "entry": [ { "fqdn": "www.example.com", "type": "runtime", "deadline4": 22, "deadline6": 20, "fail-counter4": 0, "fail-counter6": 0, "last-external": 42, "last-list-changed": 42, "parent": "example.com", "ipv4": [ { "address": "88.221.132.115", "ttl": 35, "last-updated": 42 }, { "address": "88.221.132.120", "ttl": 35, "last-updated": 42 } ], "ipv6": [ { "address": "2a02:26f0:4600::210:6738", "ttl": 45, "last-updated": 42 }, { "address": "2a02:26f0:4600::213:cc32", "ttl": 45, "last-updated": 42 } ] }, { "fqdn": "example.com", "type": "config", "deadline4": 143, "deadline6": 240, "fail-counter4": 0, "fail-counter6": 0, "last-external": 41, "last-list-changed": 41, "ipv4": [ { "address": "23.192.228.80", "ttl": 176, "last-updated": 41 }, { "address": "23.192.228.84", "ttl": 176, "last-updated": 41 }, { "address": "23.215.0.136", "ttl": 176, "last-updated": 41 }, { "address": "23.215.0.138", "ttl": 176, "last-updated": 41 }, { "address": "23.220.75.232", "ttl": 176, "last-updated": 41 }, { "address": "23.220.75.245", "ttl": 176, "last-updated": 41 } ], "ipv6": [ { "address": "2600:1406:5e00:6::17ce:bc12", "ttl": 259, "last-updated": 41 }, { "address": "2600:1406:5e00:6::17ce:bc1b", "ttl": 259, "last-updated": 41 }, { "address": "2600:1406:bc00:53::b81e:94c8", "ttl": 259, "last-updated": 41 }, { "address": "2600:1406:bc00:53::b81e:94ce", "ttl": 259, "last-updated": 41 }, { "address": "2600:1408:ec00:36::1736:7f24", "ttl": 259, "last-updated": 41 }, { "address": "2600:1408:ec00:36::1736:7f31", "ttl": 259, "last-updated": 41 } ] } ], "excluded-ipv4": [], "excluded-ipv6": [], "excluded-fqdns": [ { "address": "www.example.com" } ], "fqdn-count-runtime": 1 } ]

Настроил вчера на 5.0.1 mesh (nc-1812 + kn-3910). BE на 1812 выключил, чтобы устройства не держались за более новый стандарт. На самом деле не уверен нужно ли это, но пока так. В веб морде иногда девайсы тоже будто через провод коннектятся, но если подождать, то со временем картина меняется и все становится корректно. Перед настройкой сразу был включен mws encapsulation.

Спасибо, но как раз не хочу. Я лишь хочу чтобы dns запросы из политик наполняли ipset, который используется в маршрутизации dns в основной политике.

Мне на самом деле нравится текущая реализация, когда в политике эта система не управляет маршрутами. Таким образом можно четко убирать её из уравнения и использовать только конкретных провайдеров, но вот ненаполнение ipset для дефолтной политики при запросах из других политик всё-таки смущает. Тут вопрос - как работает кэширование dns в принципе у Кинетика? Шарится ли кэш между политиками в ситуации с одним dns апстримом? Если шарится, то логично и ipset-ы наполнять по этой же логике.

На сколько понимаю, в конечном счете всё попадает в тот же самый системный резолвер, значит технически запросы из политик могут наполнять ipset. Сейчас если устройство было в политике и походило по доменам из списка, то при смене политики на дефолтную возникает wtf, хотя устройство использует DNS от роутера с единственным апстримом. Почему этот кейс меня так интересует - есть самописный webui, который позволяет переключать политику на конечном устройстве в один клик с самого устройства без авторизации. Пользоваться очень удобно, но вот этот кейс пока что разваливается.