cheburashkaDDNS

... "excluded-ipv4": [], "excluded-ipv6": [], "excluded-fqdns": [ { "address": "yandex.com" } ], "fqdn": "yandex.com.", "fqdn-ace": "yandex.com", "type": "runtime", "deadline4": 150, "deadline6": 994, "fail-counter4": 0, "fail-counter6": 0, "last-external": 37, "last-list-changed": 37, "parent": "x.com.", "ipv4": [ { "address": "5.255.255.77", "ttl": 213, "last-updated": 65 }, { "address": "77.88.44.55", "ttl": 213, "last-updated": 65 } exclude перестал работать. в ключе fqdn теперь прописывается абсолютный адрес с корневой зоной, а fqdn-ace используется для Punycode. наблюдается деградация маршрутизации, хосты кто в лес, кто в пляс. выросло общее время ожидания. "message": "\"domain-list0\": invalid FQDN or IP address \"yandex.com.\"." ожидаемая ошибка синтаксиса

"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 ну да, на доли секунд появляется и пропадает