cheburashkaDDNS

"excluded-ipv4": [], "excluded-ipv6": [], "excluded-fqdns": [ { "address": "yandex.com" } ], замечательно, я так понимаю что и ко всем техническим доменам, в частности рекламным метрикам и трекерам от яндекса, которые могут быть встроены где угодно и приводить к нежелательной leakage мне теперь тоже нужно прописать вручную, ведь exclude работает только по принципу строгого текстового соответствия 🤷‍♂️

Вы внимательно прочли первое сообщение? Ретранслятор и хост-контроллер всегда будут работать на одном и том же канале 5 ГГц, который является служебным каналом связи между ними (беспроводным Backhaul). В разделе «Общие параметры Wi-Fi» ретранслятора этот канал должен быть обозначен если он вручную выставлялся на контроллере. точка. Для канала 2.4 ГГц эти значения выставляются индивидуально в зависимости от захламлённости эфира в той или иной точке.

всё верно говорите, с единственной поправкой что и в более ранних билдах выбор канала на ретрансляторе был залочен. поэтому случайным образом его сменить пользователь не мог. тут вопрос в том, что в поле должно выводится значение с хост-контроллера, а не значение "Авто" при заданном канале.

1. В ретрансляторе mesh-системы, в разделе «Ретранслятор» → «Сегменты» → «Гости», пункт «Доступ к приложениям вашего устройства Keenetic» забыли сделать неактивным (серым), как и остальные пункты, управляемые контроллером Wi-Fi системы. 2. В ретрансляторе mesh-системы, в разделе «Общие параметры Wi-Fi», номер канала для линка 5 ГГц отображается как «Авто», несмотря на то что в хост-контроллере выбран конкретный канал. 3. Не совсем понятно наличие пункта Multi-Link Operation (MLO) в «Настройках сети» для устройств стандарта Wi-Fi 6

Не знаю, совпадение или нет, но после обновления до 5.1.1 опять всплыла старая болячка: часть доменов полезла в обход заданного интерфейса 🤦‍♂️ Помогает принудительный сброс динамической таблицы адресов путём перезагрузки интерфейса при включённой опции «Добавлять автоматически»: interface Wireguard0 down interface Wireguard0 up

да, именно так и есть только первый домен занесён у меня в список DNS-маршрутизации, остальные просто запарсены как размещённые на том же IP-адресе отрезолвенный IP-адрес 8.6.112.0 добавляется в таблицу маршрутизации поэтому, добавив один домен под Anycast CDN, необязательно прописывать остальные но здесь есть подводные камни: всё-таки прописанный домен является регламентирующим, и если его адрес сменится на 8.6.112.6, то остальные домены, которые шли в туннель, могут поломаться. поэтому во избежание эксцессов лучше закрепить целевые ресурсы вручную.

@VVS потому что все отрезолвенные IP-адреса DNS-рутинга сохраняются в системную таблицу маршрутизации до перезагрузки или истечения времени жизни записей <ttl> / <deadline>. и если в моём случае из-за суффикса x.com yandex.com пошёл в туннель, то туда направился и yandex.ru который проксируется через те же адреса. если человек категорично говорит, что для yandex.ru сопоставлений по спискам нет, то возможно на каком-то из этапов запросы могли пойти к yandex.com для которого они присутствуют

это не имеет значения, оба домена резолвятся через одни IP-адреса если эти адреса уже добавились в таблицу маршрутизации, то все ресурсы проксируемые через них будут идти в туннель. после перезагрузки таблица сбрасывается поэтому у вас и начинает трафик идти напрямую. для определения причины дождитесь пока трафик до yandex не начнёт заворачиваться в туннель, сохраните диагностический файл и выполните в нём поиск по 'yandex.ru' и 'yandex.com' чтобы определить к какому домену они привязались в теге <parent>.

@Racer X выше почитайте. проблема в ошибочном методе сопоставления. Keenetic выполняет сравнение по суффиксу строки (в конкретном случае, оканчивается ли имя на x.com). из-за этого любые сторонние домены, текстовое название которых случайно заканчивается на x.com, распознаются роутером как зависимые. такое же поведение будет применяться к любому домену, например: abcdef.net -> def.net и т.д.

5.1.0 мониторю вторые сутки: одну проблему устранили, но появилась вторая случайным образом заметил, что трафик к Yandex стал заворачиваться через туннель выяснилось, что это происходит при одном из включенных списков доменных имён притом что в нём нет ни одной записи, указывающей на Yandex, и проксируются они в массе своей через Anycast CDN крупных зарубежных провайдеров сделал self-test и меня в нём насторожила одна строка то есть система посчитала yandex.com зависимым ресурсом (поддоменом или связанным хостом) для x.com и действительно, все домены, заканчивающиеся на x.com, такие как linux.com, spacex.com, netflix.com также пошли в туннель нарушена классическая DNS-архитектура и слом логики TLD/SLD

в последнее время наблюдается такая же история. поднят туннель на интерфейсе wg0, настроены DoH (транзит запросов блокируется), OPKG нет. DNS-маршрутизация с пятью списками, четыре по категориям и один общий. обратил внимание, что часть доменов из общего списка (порядка 70 строк) перестаёт ходить в туннель (галочка добавлять автоматически стоит). не помогала ни перезагрузка интерфейса, ни перезагрузка самого интернет-центра. дробление списка на чанки по 30 записей сняло вопрос. но теперь спорадически начала наблюдаться другая проблема. может такое быть что трафик до самого домена из списка идёт в туннель, а до его субдоменов и доменов четвёртого уровня заворачиваться в сеть провайдера, либо изначально для него не работать маршрутизация. через какое-то время отпускает и поведение становится предсказуемым. в системном журнале подозрительных событий не обнаружил. комментарии выше мне кажется верно определяют источник проблем. 5.1 Beta 3

сабж. но при этом к ретранслятору клиент подключается

UPD. 5.1 Beta 0.3 Не исправлено

@keenet07 ну да, на доли секунд появляется и пропадает

Допустим в настройках сети на ретрансляторе не отображаются диапазоны роуминга 802.11r выставленные на контроллере mesh-системы, вероятно из-за того что цвет рамки сливается. Как вариант помечать бокс галочкой? При этом они кликабельны, и даже выскакивает неактивная кнопка "Сохранить". На странице "Мои сети и Wi-Fi" также можно включать и отключать кнопки и даже Сохранить настройки.

При переключении между вкладками "Домашняя сеть" и "Гостевая сеть".

Выставляю "Каждые 12 часов", применяю настройки. Но в интерфейсе по-прежнему значится "При включении". PS: чтобы не создавать отдельную тему. "Ключ мобильного домена" было бы неплохо спрятать флагом hide в настройках как это было раньше.

Вообщем проблема следующая, ещё при переходе на 5.1 Alpha 6 обратил внимание на то что при обновлении версии программного обеспечения для всех устройств Mesh-системы по кнопке "Обновить NDMS на всех узлах" на ретрансляторе выходит ошибка "Сбой обновления". Хост-контроллер обновляется, веб-морда перезагружается и если повторить процедуру то ретранслятор также обновляется до актуальной версии будучи единственным оставшимся устройством в очереди. Используется связка в качестве хост-контроллера Giga (NC-1012) и ретранслятора Racer (KN-4010). Как процесс обновления происходил раньше при наличии обновления для нескольких устройств Mesh-системы: сначала обновлялся ретранслятор, происходил процесс обновления, затем ожидания до момента переподключения устройства и только после обновлялся сам хост-контроллер. Весь процесс происходил без ошибок.

подтверждаю наличие проблемы на 5.0.4. тоже показывает подключение по проводу устройства подключенного к ретранслятору mesh-системы по беспроводному соединению. но с одной оговоркой. одного конкретного устройства. остальные устройства подключенные по беспроводу к ретранслятору отображаются корректно. если рестнуть то помогает до определенного момента.

@dimon27254 ну, как я и написал выше с добавлением ipv6 или dns-over-https такой проблемы нет. при dns-over-tls в полноэкранном режиме тоже все хорошо. возможно здесь просто забыли исправить.

ipv6, doh впорядке. при dot в полноэкранном режиме (F11) браузера тоже.

обратил внимание на частое появляение записей в системном журнале. связаны с работой dns-proxy. используются DoH pure IPs до публичных резолверов. перебирал варианты, интернет-фильтры, на всех DNS происходит логгирование. на саму работу влияния не оказывает. Янв 11 20:23:15 https-dns-proxy 8B7D: curl response code: 500, content length: 12 Янв 11 20:23:17 ndnproxy too short packet, ignore. Янв 11 20:23:17 https-dns-proxy 6EE0: curl response code: 500, content length: 12

подтверждаю наличие проблемы

Спасибо за исправление, проверил в версии 5.0.0 (preview), теперь всё работает верно! Хотелось бы ещё попросить (на Ваше усмотрение) добавить возможность скрыть отображение пароля при выводе окна с QR-кодом в интерфейсе. И по возможности реализовать привязку -> если пароль скрыт то и в бланке при выборе "Распечатать" он отображаться не будет. Это поможет лишний раз не скомпрометировать пароль, тем паче что в локальном хранилище на устройстве он также не выводится.

последняя строка не попадает в видимую область. прокрутить список не даёт.