zubzer0

В виду большего заголовка. Для коммутации с ipv4 endpoint требуется 20байт на ip адрес, для коммутации с ipv6 endpoint - 40байт на адрес. -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 игнорирует.

-del-

да, с одной стороны решение правильное, у нас нет проксирующей прослойки. с другой привязывать скрипт к nwg1 ... а если он потом станет nwg2 или nwg0 - то конфиг будет привязываться не туда. значит нужен четкий якорь, например endpoint = 127.0.0.1 который нужно парсить, чтобы узнать какой именно nwgX нужно менять. притом менять не весь conf, а простой строкой: wg set nwg<Х> peer <PublicKey> endpoint "[1234:1234::1234]:1234" чтобы не ломать туннель если он будет изменен в GUI, включая порт. попробую подумать как, одно-файловым скриптиком.

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

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

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