zubzer0

Ответ ТП: Да, это нормально, так и было задумано при реализации, что будет работать с некоторой задержкой. "некоторой" - в районе доп. +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%

при использовании DoT на роутере 77.88.8.8:853 задержка от днс-роутера скачет 200-300мс тогда как задержка напрямую к tls://77.88.8.8:853 минуя днс-роутера, около 80-90мс т.е. в случае использования DoT оверхед тайминг примерно тотже upd. как и при использовании DOH https://77.88.8.8/dns-query роутер стабильно тормозит доп. 100-150мс сверху, вне зависимости от типа обычный/dot/doh

при тестах использовался чистый 8.8.8.8 (в 1 посте) и чистый 77.88.8.8 в повседневе использую dot.

у меня и Wireshark показывает + 100-150мс nslookup vk.com 77.88.8.8 nslookup vk.com 192.168.1.1

Понять можно. Сделав OpkgTun и OpkgTap они предложили альтернативу быстрому внедрению новых фич. Выделив больше времени на решение проблем, а не задач.

Да возможно, но потом. Думаю дождаться ответа по типу, "проблема принята и будет решаться как можно быстрее". Если не дождусь, то откачусь на 4 + dnsmasq ipset iptables

результаты пинга полным пакетом и tcp-пинг / http-ping используемая утилита https://github.com/pouriyajamshidi/tcping роутер откликается быстро, но не по части работы встроенного DNS даже страничка http://192.168.1.1/opkg - загружается через curl быстрее чем прилетают ответы от DNS Что такого невообразимого пытается делать встроенный dns сервер, что он оказывается медленнее (доп. 100-150мс оверхед) чем встроенный http-сервер с 10-15мс О_о

аналогичная ситуация с vk.com и dns-yandex 77.88.8.8 (на роутере так-же прописан он, и только он) роутер стабильно тормозит в DNS'ах никаких фильтров по вычищению рекламы. только "Списки доменных имен" для маршрутизации на wg, но (повторюсь) их отключение не меняет ситуацию. Использование tcp вместо udp, так-же не меняет ситуацию с задержкой. 150-200мс ожидания DNS-ответа это ужас! вспоминаются времена спутникового интернета из 00'ых

Маршрутизация к 8.8.8.8 без тунеля. напрямую с пк - ответ в районе 40мс, через промежуточный DNS роутера на тотже 8.8.8.8 +100мс задержки. когда-как должны быть ну максимум +5мс,а не +100мс и то в лучших моментах. к чему это приводит? если у сайта 10+ доменых имен на коннекте, это может приводить к более +1сек задержки перед началом загрузки страницы. к примеру vkvideo.ru подгружает аж 38(!) доменных имен userapi.com и okcdn.ru

Прошивка 5.0.4. Имеется wg туннель и "Списки доменных имен" для маршрутизации на wg. днс сервер встроенный, прописан 8.8.8.8, без провайдерского. при запросах напрямую к 8.8.8.8 ответ в районе 40-50мс. при запросах через роутер, к времени ответов стабильно прибавляется 100+мс так-же отсутствует какое-либо кэширование, последующие dnslookup-запросы были отправлены мгновенно после предыдущего. указанный домен encode.su - вне списка доменых имен для маршрутизации. (аналогичная ситуация и с доменами из списка) отключение списка доменных имен - не приводит к улучшению. используемая утилита - https://github.com/ameshkov/dnslookup

еще такой микровопрос возник. встроенный wg-клиент не умеет в ipv6 endpoint, даже если пробовать вписать его через interface Wireguard0 wireguard peer <PublicKey> endpoint [1234:1234::1234]:1234 а что если указать фейковый ipv4 1.2.3.4:1234 и сделать проксирование в ipv6 это возможно через нативную прошивку(5.0)? так называемый NAT46. или всеже нужно смотреть в сторону opkg socat ?

ну уже может быть попробую, но позже. как думаете, если взять opkg awg клиент на OpkgTun0, с ним будут теже танцы ip6tables? по поводу ip6tables и т.п.: уж больно не люблю много костыльных настроек в консольке, потом спустя месяцы когда что-то гдето надо подправить, уже и не помнишь, что и делал

нуепрст, сказали-бы сразу ...

1. прилетает и только в политики по умолчанию. если создать новую политику и закинуть туда клиента, где WG будет выше основного - ничего не прилетает, даже если в ней будет только WG вкл. 2. увы, по прилетающему ipv6 (в политики по умолчанию) - пинги до 2606:4700:4700::1111 не проходят. вообще ничего и никуда не проходит. не 4 не 6, кроме 192.168. 3. еще такой момент, тот wg-конфиг выше, кинетик не совсем полностью хочет воспринимать. пришлось дописывать 172.16.0.3/32 в поле ipv4 адреса - что дефолтному wg клиенту не требуется.

тогда прилетает. но перестает работать ipv4 на клиентах 😄

сделал interface Wireguard0 ipv6 prefix 2a0e:****:****::/64 ipv6 address 2a0e:****:****::1/64 system configuration save show ipv6 prefixes появилась запись. ipv6 по DHCP не прилетает.

да. префикс изначально вбит в конфиг wg руками. пробовал и 48 и 64 смена приоритетов wg на 1 место обрубает ipv4 инет. и при этом всеравно нет раздачи ipv6 в домашний сегмент сейчас wg находится под основным - так есть ipv4 и ipv6 в самом роутере show ipv6 addresses show ipv6 prefixes "prompt": "(config)" пример конфига wg используемого для получения ipv6

не надо флуда. есть wg туннель. тунель рабочий (curl апрувед). название wg тунеля 6in4. проблема в том, что роутер не инициирует раздачу хоть то /48 хоть то /64

что значит надо? сервис предоставляет услугу 6in4 и/или wg. название туннеля от поставщика.

сделал ситуация та-же. interface Wireguard0 ipv6 prefix auto system configuration save show ipv6 prefixes это название wg туннеля так. от 6in4.ru

сделал /64 на wireguard . сделал 64-0 под DHCP галкой ipv6 в домашней сети. роутер сделал два маршрута . ситуация та-же.