zubzer0

я не рискну использовать альфу. особенно после количества и характера отзывов которое было сделано в ветке 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 дня ? со столь малым потреблением трафика, когда как на других промежутках трафик ощутимо больше.

В виду большего заголовка. Для коммутации с ipv4 требуется 20байт на ip запись, для коммутации с ipv6 - 40байт на ip. -20-8-32 - если endpoint ipv4 -40-8-32 - если endpoint ipv6 (где 20/40 - ip адрес, 8 - UDP заголовок, 32 - wg данные) но, это будет впритирку, wireguard такое не любит, хотя коннект будет, но скорость просядет, поэтому для "буфера" вычитают еще 20 байт (можно попробовать -10 или -30, но это требует iperf тестов по месту) поэтому, правильно будет: -20-8-32-20 ; -80 если endpoint ipv4 -40-8-32-20 ; -100 если endpoint ipv6

1. у меня получилось через OpkgTun1 но тут скорее по правилу "или" : - если хотим подключится к ipv4-endpoint и получить ipv6, то нигде кроме endpoint никаких ipv4 и масок - тоже самое, если хотим от ipv6-endpoint получить ipv4, то нигде кроме endpoint никаких ipv6 и масок. это касается как conf, так и самого OpkgTun интерфейса. * в conf для awg(opkgtun) вроде строки address быть не должно вообще ** а вот для встроенного wg, ipv4 нужно прописывать всегда, какой-нибудь из свободных 172.16.0.Х/32 2. для уменьшения страданий трафика и проца, можно отказаться от всех amnezia параметров кроме: i1, i2, i3 - но тут, или улучшит или не заработает, нужно тестить по месту. --- а вообще, у меня получилось сделать тунель-в-тунеле: амнезию конектил к v4-endpoint для получения v6., опосля, подключался к v6-endpoint через родной WG для получения v4. Увы, но какое либо DHCPv6 или просто v6-шлюз, не заводится. ipv6 от awg (и от WG) - остается только внутри роутера. но, может быть через fe80 ? получится подобие NATа со статикой., а то адресами светят, пинги бегают... На заметку, 1. для MTU туннеля подключаемого к ipv4-endpoint надо вычитать 80, а у подключаемого к ipv6-endpoint надо вычитать 100. Не забывайте про MTU, если делаете тунель-в-тунеле, и не опускайте его ниже 1280 для того тунеля где вы получаете ipv6 адрес, а для тунелей где вы получаете ipv4 - mtu вполне может быть и меньше 1280. (из личной практики: я вполне удачно поднимал рабочий WG туннель с mtu=1180 через Teredo[mtu=1280] подключаясь к ipv6-endpoint) 1.а) если вы делаете "туннель в туннеле", где основной туннель amnezia с включенными параметрами Jc Jmin Jmax, то лучше исходить от меньшего (1280) прибавляя 100 на туннель amnezia, дабы у алгоритма был размах действий. т.е. первый туннель(amnezia) mtu=1380, а для туннеля внутри mtu=1280. В случае если у вас только i1, i2, i3 - то исходим/считаем от большего. 2. если кто будет копаться в пробросах и маршрутах, и столкнется с прошивочными ограничениями роутера, то знайте - 2000::/3 вполне годится чтобы быть всею ipv6 😉

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

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

чтобы снова не попасть в неловкую ситуацию спрошу чтобы это работало постоянно в случаях падений и перезагрузки - нужно делать скрипт, верно?

в консоли BusyBox команды wg - не существует. конечно, можно поставить сторонний wireguard, к примеру amnezia через opkgtun, в котором есть поддержка ipv6-endpoint. но это не будет иметь "hw offload" как у встроенного клиента.

в консоли BusyBox команды wg - не существует. метод (config)> interface Wireguard1 (config-if)> wireguard peer <PublicKey> endpoint [1234:1234::1234]:1234 даёт ошибку - Command::Base error[7405602]: argument parse error.

насчет Cloudflare (WARP) если у вас есть ipv6, можно попробовать подключится к его ipv6 адресу. nslookup -type=aaaa engage.cloudflareclient.com но, встроенный wg-клиент (всееще) не умеет подключатся к ipv6. это можно обойти через перенаправление ipv4 -> ipv6 посредством socat https://forum.keenetic.ru/topic/27233-wireguard-ipv6/#findComment-232301 p.s. можно заморочиться через iptables ip6tables с маркировками ... но какпомне, для просто-юзер, простым и элегантным решением будет - socat

сделал коннект к 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, а так-же проведено улучшение скорости работы.