zubzer0

аналогичная ситуация с 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 и чередование туннеля в Приоритеты подключений. результатов не даёт.

заприметил интересную особенность. при использовании DoH с awg1.5/2 против "сами знаете чего", наблюдается меньшая стабильность быстрых коннектов, нежели если использовать только DoT, возможно изза 443 порта как триггер(🤨 наблюдения на уровне шизы)

как сделать, для 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 ютуба имея точку выхода в *бразилии, ну както очень-не-очень. (* к примеру)

tree/feature/awg2 https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/tree/feature/awg2

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

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

IPv4 MTU на провайдере 1500. туннель к серверу исправно поднимается с MTU=1480 Клиенты исправно получают IPv6, но с локальными клиентами роутер общается по IPv6 MTU=1500. Что приводит к бессмысленной фрагментации 20 байт в дополнительные 1280, т.к. минимальный размер ipv6 пакета 1280. Вопрос: возможно ли сделать чтобы при включенном 6in4 соединении на роутере, все ipv6 интерфейсы роутера (и новые) снижали планку v6-MTU до 1480 [прямая зависимость от MTU туннеля]? Или только ручками на самих клиентах?

Вот такая штука должна быть, если-бы клиент-прокси умел в отправку DNS-запросов через SOCKS прокси: На роутере 6in4 туннель штатными средствами ОС + 3proxy из opkg, с простым конфигом: daemon nserver [2001:4860:4860::8888] auth iponly allow * 127.0.0.1/8,192.168.1.1/24 socks -64 расширение браузера для показа ip и доменов: IPvFoo А далее через штатные "Приоритеты подключений" можно творить чудеса ... можно было-бы, еслибы клиент-прокси на кинетике умел в отправку DNS через прокси, эхх ... p.s. в идеале еще бы и PAC файлы... но я губу раскатал.

Скрин, 6in4 и 6to4 в NAT'e и оба работают - благодаря ALG для ESP 6to4, это производная 6in4 и настраивается так-же: где 2002:abcd:abcd::1 - адрес созданный на основе внешнего IPv4 http://wb0.ru/ipconv.php - маршрутизация IPv6 в IPv4, в конце дописываем ::1 p.s. я крайне надеюсь, что гугл, это проиндексирует, ибо инфы по этой теме в рунете нет совсем. Кста, 6to4 почему-то игнорируется гуглом, ютубом и многими другими сайтами в коннекте, увы :( даже если полностью отключать ipv4. Но в тоже время Cloudflare, торрент-трекеры (и не только) работают ...

При настройке прокси клиента keenetic - DNS запросы работают будто вне прокси. т.е. к примеру, если на прокси-сервере есть ipv6 only выход в интернет, то прокси-клиент keenetic настаивает работать по ipv4 формируя крайне странные запросы вида ::fff:[ipv4]:[port] и ожидая от них какого-то ответа. К примеру, если у Firefox убрать пункт "отправлять DNS-запросы через прокси" то будет та-же самая проблема 1в1. Из чего делается вывод, что прокси-клиент keenetic не умеет отправлять DNS запросы через прокси. Прошу добавить настройку в прокси-клиент keenetic "отправлять DNS-запросы через прокси", подобно Firefox, как и у большинства нормальных прокси-клиентов, где днс работают через прокси.