zubzer0

при использовании 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 в домашней сети. роутер сделал два маршрута . ситуация та-же.

только "prompt": "(config)" show ipv6 addresses fe80:: на всех кроме Wireguard0 curl http://[2a01:4f8:172:3202::acab:f001]/json (http://myip.wtf/json) работает, и пишет мой ipv6 от wireguard, без указаний интерфейса. т.е. роутер умеет и пользуется ipv6, но не для сегмента домашней сети.

Прошивка 5.0. Имеется туннель wireguard на ipv4 сервер, от которого идёт получение ipv6 /48 ipv6 пинги и curl в консоли роутера работают. Вопрос, как сделать раздачу ipv6 в домашнюю сеть по DHCP ? В сегменте домашней сети инициируются только fe80:: Галочка включить IPv6 и чередование туннеля в Приоритеты подключений. результатов не даёт.

как сделать, для fqdn свой dns? суть: точка выхода может быть совсем в другой гео-позиции. При разрешении ip от cdn серверов, роутер получает ip по геолокации, которая не соответствует точке выхода. как можно решить: если-бы была возможность задать 1.0.0.1 или 8.8.4.4 для fqdn, и в то-же время указать маршрут на 1.0.0.1 через используемый интерфейс. тогда, разрешение ip будет по точке выхода. или такой вариант, доп.флаг в dns-proxy route object-group для указания, что dns сервер для данной группы будет использоваться только через указанный интерфейс. p.s. получать *финские ip ютуба имея точку выхода в *бразилии, ну както очень-не-очень. (* к примеру)

Кто-нибудь собирал пакет dnsproxy для AArch64?

возможно ли через этот апдейт организовать настройку днс для группы доменных имен? 🧐 к примеру добавить и домен и поддомены *.yandex.net *.yandex.ru *.ya.ru в одну группу, а после этой группе назначить определенный днс сервер.