zubzer0

- если ответы приходят быстро, то кэширование работает. - вы делали "Маршрутизация - Маршруты DNS - Правила маршрутизации" ? (основа проблемы) - вы делали какой либо кэш-перехват, как из моего примера с unbound ?

я не рискну использовать альфу. особенно после количества и характера отзывов которое было сделано в ветке dev-тестирования на 5.1 эти "ощущения" - измеримы. я приводил примеры как это делать

кстати, тех.поддержка ответили: " мы передали информацию разработчикам, но прямо сейчас (в версиях 5.0.Х) никаких изменений не ожидается. " 😐

эта тема была создана для демонстрации плохой работы при общении со службой тех.поддержки. для решения проблемы прошивки. а решая проблемы прошивки подобным стилем, можно в конечном итоге уйти на другие роутеры на базе openwrt. это не запрос на доп.функционал или что-то, что используется у одного из тысячи. Это DNS, основа, то, что должно/обязано работать идеально быстро в любом роутере, вне зависимости от настроек, притом настроек в GUI если подобная оптимизация невозможна, то в GUI прошивки должно быть указано, что использование "Маршрутов DNS" - приведет к значительному увеличению времени отклика. Если такой плашки нет - то значит, это проблема, которую нужно решать.

в отсутствии банального кэширования по TTL в Keenetic DNS при включенной маршрутизации FQDN.

изначальный вопрос был: если вы не добавляете ip и маски разрешенных ipv4, то роутер не будет использовать его для ipv4, хотя имеет локальный 172.16.0.66/32 прямо в данный момент, у меня работает WG тунель от которого идет приём только ipv6 . и никаких проблем с маршрутизацией ipv4. А вот как с этого тунеля раздавать ipv6 на клиенты - это уже надо думать в другую плоскость ... У роутера, внутри, ipv6 будет работать, можете проверь через консольку. или в http://192.168.1.1/diagnostics/general пингом на 2001:4860:4860::8888

удалось снизить влияние оверхед задержки FQDN 150-200мс только таким способом: клиенты - unbound - KeneeticDNS(FQDN) - adguardhome-go - интернет 1. Настройка AGH-go - указываем bind_hosts 192.168.1.1 и port 253 - Быстрый IP - off (т.к. AGH находится после FQDN) - кэш и оптимистический - строго off - размер кэша - 0 - TTL min / max = 900 / 86400 - TTL заблокированного = 900 2. Настройка KeneeticDNS: - прописываем днс сервер - 192.168.1.1:253 (AGH) - делаем правило перенаправления (перехвата) 53->153 (для unbound) https://images4.imagebam.com/6f/ba/ab/ME1AT36A_o.png (плюсом: данным правилом клиенты не смогут обратится к любым другим DNS на 53 порту, заставляя клиентов использовать только 192.168.1.1, и пресекая утечки мимо FQDN, [исключение: doh/dot] ) 3. Настройка unbound (для ARM64 2ядра): - включен обычный кэш - включен prefetch кэш, который фоново обновляет записи за 10% перед истечением TTL - включен "оптимистический кэш" на 3ч, который отдает ответы с TTL 10сек, в это время фоново обновляя просроченные записи. - в случае если у AGH будет включено кэширование, то фоновые записи из 10%-prefetch будут обновляться из старого кэша AGH (это плохо) - opkg install unbound-daemon unbound-checkconf - /opt/etc/unbound/unbound.conf На клиенте, был сделан фоновый скрипт с dnsproxy, который логирует скорость ответа от сервера 192.168.1.1 и в течении 3 дней сбора статистики, на прямом KeeneticDNS, было установлено, что средняя задержка ответов около 180мс !! Тогда-как на вышестоящем AGH, который отдавал ответы встроенному KeeneticDNS, "среднее время обработки запроса" была всего 20мс. После применения этого "днс-бутерброда", удалось снизить среднюю задержку, на клиенте, на минус 150мс. Сделав её равной около ~30мс.

укажите ipv4 = 172.16.0.66/32 но, не заполняя поле разрешенных ipv4 поля ipv6 адреса и префикса нужно заполнить, как и поле разрешённых ipv6 ::/0 или 2000::/3 --- если вам нужно чтобы endpoint был ipv6, сначала укажите в GUI его как 127.0.0.1:[port] потом opkg install wireguard-tools wg set nwg0 peer {PublicKey} endpoint [ipv6]:port и в /opt/etc/ndm/iflayerchanged.d/endpoint.sh сделайте что-то вроде такого #!/bin/sh NameWG="SuperPuperWireGuard" # Название туннеля в GUI PeerPublicKey="bmXOC+F1Fxu51h2wPfgyo=" # PublicKey для пира PeerEndpoint="[abcd:abcd::abcd]:1234" # Желаемый IPv6 endpoint [ "$1" = "hook" ] || exit 0 [ "$level" = "disabled" ] && exit 0 [ "${system_name#nwg}" = "$system_name" ] && exit 0 /bin/ndmc -c "show interface ${system_name/nwg/Wireguard}" | grep -Eq "description: +$NameWG$" || exit 0 wg set "$system_name" peer "$PeerPublicKey" endpoint "$PeerEndpoint" logger -t "WireGuard-Hook" "$NameWG ($system_name): Endpoint:$PeerEndpoint layer:$layer level:$level"

А конфиг WireGuard точно рабочий? Делали проверку конфига на ПК, перед тем как его в роутер импортировать? Может быть проблема не в маршрутах на роутере, сейчас времена такие...

двумя ИИ-шками, можно написать вполне сносно, в 1ой пишем, во 2ой проверяем/дописываем, потом проверяем первой. главное, точно указать версию прошивки, и просить меньше логировать и не делать проверок/защит "от дурака" в простенькие скриптики вполне могут, но и базовые знания тоже нужно иметь, чтобы "читать код". и помнить, что ии, это инструмент (или альтернативный взгляд), а не средство от проблем решающие задачи по размытому запросу "хочу чтобы было красиво".

это говорилось про entware, opkg пакет adguardhome-go если вы ничего такого не делали, то это не тот случай, описанный мною.

Соглашусь, это не просто сводит с толку, а буквально бросает в ужас! Это надо фиксить! и/или назвать как-то не столь таинственно-многозначительно : "Другие клиенты"

upd. по поводу 1. После анализа, пришел к выводу, что "другие клиенты", это возможно AmneziaWG трафик от одного из клиентов. но тогда 2. остается вопросом, почему этот трафик отображен только в графике 1го дня и нигде более. и 3. зачем его отображать как "другие клиенты", если он и так идет в зачет статистики клиента, возникает фобия 😵

Странное поведение монитора трафика. При выборе промежутка 1 День - появляется "Другие клиенты" При выборе других временных промежутков - "Другие клиенты" - отсутствует. При выборе "Другие клиенты" из промежутка 1 день, показывает весьма ощутимое потребление трафика. В списках клиентов присутствуют только "Зарегистрированные клиенты". Cписки незарегистрированных и заблокированных - пусты. 1. Что это за "другие клиенты" 2. Почему они отображаются только в графике 1 дня ? со столь малым потреблением трафика, когда как на других промежутках трафик ощутимо больше.

столкнулся с подобным после установки AdGuardHome в одной из последних версий . Там нужно убрать галочки у PTR - Использовать приватные обратные DNS-резолверы - Включить запрашивание доменных имён для IP-адресов клиентов

погонял я методику быстрого кэша dnsmasq спереди и длинного кэша у AdGuardHome позади (оптимистик офф) с параметрами из пред.поста. увы, но именно youtube всеравно периодически слетает/не прописывается у "DNS-based routes" какие-то там видимо "особенные" днс-записи которые keenetic игнорирует.

сделал коннект к Ipv6 серверу Wireguard через socat: Всё как и с обычным ipv4, только в поле Endpoint = 127.0.0.1:2408 MTU сначала делайте 1280, потом пробуйте больше.

по поводу второго пункта: почему нужно сохранять старые записи DNS на маршрутизации, пример. - в роутере прописаны 2 и более сервера днс. 8.8.8.8 и 1.1.1.1 - к роутеру подключены 2 и более клиента. 1. первый клиент делает днс-запрос для ютуба 1.1 роутер получает IP от 8.8.8.8 1.2 первый клиент получает ip и маршрутизацию, время ttl допустим 10минут. 2. спустя минуту второй клиент делает запрос на тот-же ютуб 2.1 роутер получает уже другие IP от 1.1.1.1 2.2 второй клиент получает другие IP и обновленную маршрутизацию 3.1 первый клиент теряет правильную маршрутизацию. 3.2 первый клиент не видя коннекта, делает запрос к роутеру. 3.3 роутер снова получает IP от 8.8.8.8 и обновляет маршрутизацию 4.1 второй клиент теряет маршрутизацию. 4.2 ... и так по кругу... ситуацию изменило бы 1. кэширование: второй клиент получил бы те-же IP, что и первый 2. сохранение записи: если возникает расхождение, первый клиент остается на своей "старой" маршрутизации. p.s. я крайне надеюсь, что разработчики "FQDN / DNS-based routes" прочитают это. в этом и кроется проблема с периодическим хождением трафика не в ту дверь интерфейс. (особенно часто, это случается с ютубом и пр. крупными cdn-порталами)

Очень важный момент по поводу доменной-маршрутизации: Если вы используете "Списки доменных имен" (не важно в какой именно её реализации), то, идеально, чтобы какое либо кэширование ДО механизма распределения маршрутов - должно отсутствовать в принципе. Иначе возможен момент с потерей актуальности маршрутов. Когда вы используете IP из кэша, который отсутствует в актуальном списке на маршрутизацию, и вы не получаете ту самую маршрутизацию, хотя имеете IP и коннект, но в "маршруте по умолчанию". 1. Кэширование должно быть встроенным в сам "DNS-based routes" . Важный момент, клиенты должны получать max-ttl <=10 минут, но кэш держатся значительно дольше (60мин), и фоново актуализировался при новых запросах. Как вариант вместо 10-60, применить 3-10. 2. Также необходимо реализовать сохранение предыдущего состояния ip-маршрутов в течении времени как минимум равное max-ttl, чтобы клиенты с устаревшими записями DNS - не стучались по "маршруту по умолчанию" А вот кэширование, реализованное что-до и что-после механизма "DNS-based routes" = это два костыля, один левый и другой правый 😁

@dchusovitin сначала тут был пост-сообщение, где я посоветовал использовать AdGuardHome до KeenDNS. но спустя некоторое время до меня дошла мысль: что актуальность записи в FQDN может быть утрачена, и при этом AdGuardHome будет отсылать сразу к IP, т.е. с утраченной актуальностью маршрутизации. Увы, но кэширование ДО KeenDNS должно быть совсем небольшим (по типу L1 кэша процессора ) Возможно даже 300 записей будет много, хватит и 100 (сообщение поправил). Если вы используете AdGuardHome с бОльшим кэшированием, то он должен быть исключительно после KeenDNS. Перед KeenDNS - dnsmasq с маленьким кэшем. И даже в этом случаее может возникнуть момент с потерей актуальности. ПК <-> miniCache/dnsmasq <-> KeenDNS/FQDN <-> bigCache/AdGuardHome <-> Интернет ВАЖНО: Кэширование(miniCache) должно быть встроено в логику FQDN, а так-же проведено улучшение скорости работы.

Ответ ТП: Да, это нормально, так и было задумано при реализации, что будет работать с некоторой задержкой. "некоторой" - в районе доп. +100-200мс, где даже http-сервер(KeeneticOS) быстрее : |

придумал такой костыль-решение: 1. запускаем dnsmasq на 153 порту, который слушает локалку (br0) и loopback (lo) dns сервер указываем 127.0.0.1 на 53 порту включаем кэширование на 100 адресов. (не ставьте много, это может привести к потере актуальности записей маршрутизации в FQDN) отключаем подгрузки каких либо других настроек, кроме этого конфига вписываем выдуманный домен - для проверки /opt/etc/dnsmasq.conf port=153 user=root group=root interface=br0 interface=lo server=127.0.0.1#53 cache-size=100 no-resolv address=/keen.etic/1.2.3.4 /opt/etc/init.d/S56dnsmasq restart 2. проверяем что dnsmasq работает, напр. через тулзу https://github.com/ameshkov/dnslookup > dnslookup keen.etic 192.168.1.1:153 вы должны получить 1.2.3.4 3. создаем правило переадресации портов как на картинке: тем самым переадресуем все входящие 192.168.1.х на 53 порту, в 153 порт внутри роутера, который в свою очередь обращается к 53 порту своего 127.0.0.1 Зачем? Это даст возможность кешировать днс записи, чтобы второе и последующие обращения происходили без этого 100-200мс тормоза. При этом мы оставляем рабочим и родной DNS и логику FQDN. Просто слегка бустим/исправляем кэш-перехватом. костыль, кэширование должно быть непосредственно в KeenDNS, желательно с доп. настройкой времени хранения (1-1440 мин.)

после небольших экспериментов(с перезагрузками), как оказалось в падении производительности - количество не влияет. хоть 10 доменов, хоть 800 доменов по типу example.com и так и так будет дополнительные 100+мс оверхеда, вне зависимости состоит ли запрашиваемый домен в списке или нет p.s. а я такой думаю, а чего это даже "белые" сайты стали подтупливать на загрузках...

Да! именно так. Удалил правила, но списки оставил, презагрузился. и только тогда встроенный dns стал работать адекватно! После добавления правил к спискам - проблема роста задержки вновь вернулась. Последующая перезагрузка роутера - не помогает. Проблема именно там - в наличии правил маршрутизации DNS. у меня 7 списков/правил по 30-50 доменов в каждом. дублей нет. всего 233, все домены второго уровня - example.com объединение всех доменов в один бОльшой список и одно правило - проблему не решает. FQDN требует оптимизаций производительности !

сделал на роутере dnsmasq на 192.168.1.1:153 в dnsmasq прописал address=/zer0.zub/8.8.8.8 в настройках прошивки KeeneticOS указал сервер 192.168.1.1:153 т.е. ссылающийся на dnsmasq внутри себя! в итоге +100-120мс если обращаться через :53 который обращается к :153 нежели если обращаться к :153 напрямую к dnsmasq в Wireshark результат тот-же. утилита работает правильно. Роутер стабильно тормозит DNS на 100+ мс проверил и в самом роутере днс стабильно тормозит хоть то 192.168.1.1 хоть 127.0.0.1 170мс ! минимальный трафик, ЦП нагружен 1-3%