zubzer0

в логе 5.1 A6 есть улучшения FQDN, нужно тестить.

3 часовой тест ICMP пинга и TCP пинга, малыми пакетами, от роутера к клиенту шкала логарифмическая, чтобы не сливалось в ровную линию. нижние скачки в районе 0.3-1мс, пики на 10-15 мс левая часть - обычный веб серфинг. середина - простой. правая часть - торрент с 50 активными пирами. заметил забавность, что при использовании канала, пинги приобретают слегка сниженный характер (падают до 0.3мс) нежели при простое. (почти ровная 1мс) в тоже время, заметил, взлёт пиков НЕ является следствием загруженности канала от множества коннектов или трафика. Ибо левая часть и правая похожи, хотя слева просто веб, а справа торренты. ( помехи? ) какой-то четко выраженной последовательности повторений лагов - не наблюдаю. не в icmp, не в tcp ICMP: TCP: на графике взлёт пиков выглядит слегка пугающе. по факту: тех, что больше 2мс- около 300 (3%) тех, что больше 5мс - около 50 (0,5%) тех, что больше 10мс - около 5 (0,05%) 0 промахов. но, какие либо выводы делать не стоит, ибо тест всего 1 клиента и в определенной местности. здесь много влияющих факторов, сетевая карта и ос на клиенте, кабель и помехи ... нужно воспринимать, это только, как тест конкретного конфига. а для себя я делаю вывод, что в 0,05% пакетов, у меня почему-то случаются затупы (x10 lag)

надо писать на почту. https://keenetic.ru/ru/company/support прикладывая скрины из https://github.com/ameshkov/dnslookup и/или dig если linux. можно еще и с Wireshark по типу https://forum.keenetic.ru/topic/27262-медленный-dns/#findComment-231915 и вот сюда ткнуть

поскорее бы... хотя-бы для localhost как-то исключение сделать в ближайшем релизном 5.0.х (онже жестко прописан в системе, зачем ему dns-based routing) а остальное, пускай приложится в 5.1 в общем пакете оптимизаций (включая возврат кэширования)

притом поведение крайне странное. роутер буквально ничего не делает. 0 трафика, а задержка гуляет с 2х/3х кратным джиттером, на ровном месте, на localhost'e p.s. тут можно статью на хабре писать, о том как Кинетики локалхост уронили 😆

5.0.7 ситуация без изменений dns роутера продолжает неимоверно тормозить сам-себя и заставляет тормозить "самих-себя" - всех клиентов без статики.

обратите внимание на "Активные соединения" если их настолько много, что роутер буквально зависает от флуда. тогда проблема в PTR, их надо отключить. в конфиге это dns: use_private_ptr_resolvers: false clients: runtime_sources: rdns: false

кстати, еще немного оффтопика. в тестах "медленного DNS" я как-то поймал странный баг у винды. встроенная тулза nslookup игнорировала метрику интерфейса, и получалось, что через неё приходили одни ip с одного интерфейса, а всё остальное в ОС согласно метрики получало другие ip с правильного интерфейса. это странное поведение nslookup разрешилось только после перезагрузки ОС.

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

белые списки сложнее делать. нужно sing-box с фильтром региона . иначе всякий торрент трафик может бегать совсем не там где надо. или p2p игрушки тоже... а оборачивать 10тыс. строчек масок ip адресов ру-провайдеров, никакие роутеры не справиться. но при использовании sing-box вы попрощаетесь с TLS1.3 (SNI)

Helby, увы встроенный DNS сервер в Keenetic слабо годится для резольва отдельных доменов через конкретные сервера. решение, только такое, ставить добавочно сторонний днс (напр. adguardhome-go) куданибудь на 153 порт в котором будут прописаны необходимые правила. а в настройках роутера указать только 192.168.1.1:153 в правила маршрутизации жестко прописать ip через тунель. например 8.8.8.8 оставить штатно, а для 8.8.4.4 направлять в тунель. p.s. помните, что у сайтов, есть и доп.домены. узнать какие поможет расширение для браузера IPvFoo, и лучше использовать домены 2го уровня по типу - example.com

а еще, если у клиентов нет статики на localhost 127.0.0.1 (редко, но бывает) то они так-же получают его с 100-200мс, а то и под 300мс задержкой Я не верю, что пишу такое, добавил в конфиг unbound строчки статики для localhost local-zone: "localhost." static local-data: "localhost. 86400 IN A 127.0.0.1" local-data: "localhost. 86400 IN AAAA ::1" но, это не исправит внутренний localhost у роутера. внутри роутера все обращения к домену localhost , будут идти с 100-300 мс задержкой из-за резольва ip 127.0.0.1 Это даже звучит абсурдно, но это так.

я отправил в тех.поддержку свой и ваш скриншоты по localhost'у будет интересно получить очередной ответ, "так и должно быть" и "никаких изменений не ожидается". разрабы такой эпикфейл выкатили в релиз, и в упор не хотят видеть. (нормально, и так сойдет) p.s. если localhost резольвится больше 2мс, это уже проблемы.

ужз. как можно было пропустить в релиз, и не фиксить вот уже с месяц. и откладывать это на 5.1 версию, которая выйдет (если повезет) через полгода. мужики, тут-какбы localhost под 200мс 😲 чесслово, такого я еще не видывал.

вы же понимаете, что много-много где в конфигах как самого роутера, так и entware, прописан адрес localhost и вот каждое обращение к localhost это 100-200мс задержки ...