qmxocynjca

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

Ситуация: 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, который позволяет переключать политику на конечном устройстве в один клик с самого устройства без авторизации. Пользоваться очень удобно, но вот этот кейс пока что разваливается.

К теме топика - на 5.0.1 пока полет нормальный, но заметил странную особенность. Если устройство в политике и делает днс запрос на хост из списка (через резолвер, который используется во всех политиках!), то ipset не наполняется. Зачем это ограничение? Понимаю что в политике маршрутизация не будет работать, но ipset можно и наполнять. Столкнулся с тем что при смене политики на дефолтную, нужно явно сбрасывать кэш днс на устройстве дабы триггернуть заполнение таблицы на роутере, а это не всегда просто сделать на каких нибудь мобилках.

Исправлено в 5.0.1!

+1 Закрытие любого диалога через ESC сопровождается сворачиванием бокового меню. Не круто.

На сколько флеш в современных aarch64 моделях живуч? В PiKVM есть прикольная фича по включению read-write и read-only режима, чтобы как раз не тратить ресурс памяти когда всё настроено. Не думали добавить сюда такое же? Вот пример из документации PiKVM:

Да не, видно же что что это списки доменов с вручную заданными именами. Ждём новую версию прошивки, говорят там что-то должно быть поправлено.

Получилось починить слегка костылём через прописывание "ip dhcp pool _WEBADMIN domain local", айфон теперь нормально открывает такие хосты. В avahi-daemon есть возможность подсунуть hosts но в моих экспериментах это упёрлось в какую-то известную проблему https://github.com/avahi/avahi/issues/40 Однако там есть решение https://github.com/avahi/avahi/issues/40#issuecomment-531047292, так что если соберёте это всё в рабочий механизм, который бы наполнял /var/avahi/hosts записями "ip host *.local" из CLI, то думаю всё будет работать.

ip host service1.local 192.168.1.1 не работает на Apple девайсах, т.к. они эксклюзивно резолвят .local только через mdns. Можно научить Кинетик прокидывать .local хосты в mdns демон?

Нашел вот эту галочку, она сменила состояние гостевой сети на private и в целом это решило проблему. Однако, выглядит не идеально, т.к. кто-то по незнанию может накрутить no isolate-private и ожидать что гостевая сеть останется гостевой, а по факту она получит полный доступ к другим private сетям из-за такого неочевидного наложения одного на другое. Плюс это даёт доступ ко всем приложениям, а нужно именно выборочно.

Есть сервис, который хочется сделать доступным по 4-му уровню домена всем клиентам, как подключенным к роутеру напрямую так и гостевым. Есть ли какие-то технические ограничения для поддержки режима http-proxy security-level protected? Сейчас можно либо private либо public. После добавления фаервол правила в гостевую сеть, коннект по домену начинает работать, но сервер отдаёт 403.

Ага, это я молодец. Крутил на другом Proxy интерфейсе. Работает! Почему так произошло - Wireguard интерфейсы в вебе идут в том порядке, в котором они прописаны в конфиге, т.е. Wireguard0, Wireguard1, ... А другие соединения, оказывается, сортируются по имени. В общем, мышечная память сыграла злую шутку.

Судя по всему, в какой-то момент произошел переезд с badvpn на hev-socks5-tunnel и "interface Proxy proxy socks5-udp" теперь ничего не делает? В конфиге hev-socks5-tunnel (cat /var/run/proxy-cfg-t2s1) всегда вижу параметр udp: 'tcp'. Ради интереса запустил эту тулзу на opkgtun интерфейсе, указав в конфиге руками udp: 'udp'. К моему удивлению, DNS lookup заработал! Проверял на компе в политике, где нужный opkgtun был единственным интерфейсом: dig +short myip.opendns.com @resolver1.opendns.com В ответе был тот же адрес, что и при открытии через ip.wtf браузером. @Le ecureuil подкрутите, пожалуйста, чтобы "proxy socks5-udp" выставлял udp: 'udp' в конфиге hev-socks5-tunnel (если он сейчас ничего не делает). А если он всё-таки что-то делает, то добавьте возможность рулить этим параметром через CLI. Мы вам скажем спасибо.

Они же не провайдер. Буду удивлен, если DoT от яндекса как-то аффектится ркн-ом, но не исключаю такого в будущем. Сейчас, по ощущениям, работает вполне адекватно.

DoT от Яндекса - это нормальный DNS в этом случае? Не очень понимаю что есть "неподменные". Если речь про "Интернет-фильтры", то ими не пользуюсь, всё руками прописано, никакого adguard и прочего нет в цепочке. Это хорошо, будем посмотреть. Тут вам видней, конечно, но это не первый раз когда я пробовал dns-proxy debug и все разы получалась какая-то жесть, когда было ощущение что девайс придётся ресетить, ибо всё вставало колом.

Про это не знал, спасибо. Да, это понятно, весь список нужных доменов заполнен. Проблема воспроизвелась конкретно с этим хостом, поэтому подробности опустил. @Le ecureuil я бы рад держать dns-proxy debug включенным, чтобы отловить это, но это не реально - резолвер перестаёт отвечать через какое-то время (минута-две) и в логи начинает слать какое-то слишком низкоуровневое месиво. Сделайте чтобы dns-proxy debug был рабочим на постоянной основе?

В роутере (fw 5.0.0) прописан DNS от провайдера (обычный) и от Яндекса (DoT), в списке DNS маршрутизации прописан youtube.com. Проблема: www.youtube.com не смог зароутиться куда надо. После неудачного роутинга несколько раз делал "nslookup www.youtube.com 192.168.1.1", но результата не дало - роутер упорно вёл по провайдеру. Пробовал включить dns-proxy debug, после чего роутер почти завис секунд через 30, смог выключить эту настройку только через telnet. Кажется после этого роутинг таки заработал, но легче от этого не стало. Наблюдения: * провайдерные DNS возвращают 173.194.221.198 от primary и 64.233.162.198 от secondary на nslookup www.youtube.com. * nslookup на www.youtube.com возвращает "Tracing route to wide-youtube.l.google.com", а на youtube.com возвращает "Tracing route to youtube.com". * nslookup www.youtube.com 77.88.8.8 (обычный dns от яндекса) возвращает разные адреса на каждый запрос. Вот как это примерно выглядит: C:\Users\user>tracert -d -w 50 www.youtube.com Tracing route to wide-youtube.l.google.com [173.194.220.198] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 1 ms 1 ms 1 ms <isp_gw> ^C C:\Users\user>nslookup www.youtube.com 192.168.1.1 Server: UnKnown Address: 192.168.1.1 Non-authoritative answer: Name: wide-youtube.l.google.com Addresses: 2a00:1450:4010:c1e::c6 142.251.1.198 Aliases: www.youtube.com youtube-ui.l.google.com C:\Users\user>tracert -d -w 50 www.youtube.com Tracing route to wide-youtube.l.google.com [142.251.1.198] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 1 ms 1 ms <1 ms <isp_gw> ^C C:\Users\user>tracert -d -w 50 youtube.com Tracing route to youtube.com [173.194.221.91] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.88.88 2 91 ms 89 ms * <kvn_gw>