qmxocynjca

Есть более общая идея для кастомизации кнопок:

Думал исправление подъедет в одной из альф, но пока всё по-старому. Возможно не сильно приоритетно, но хочется корректности работы в этом месте. Может более логичный фикс - это добавить в дефолтную таблицу ipv6 маршрутов правила аналогичные 451, 452, 453 как в таблице ipv4? ~ # ip rule 0: from all lookup local 10: from all fwmark 0xffffa00 lookup main 100: from all fwmark 0xffffaaa lookup 10 101: from all fwmark 0xffffaaa blackhole 102: from all fwmark 0xffffaab lookup 11 103: from all fwmark 0xffffaab blackhole 104: from all fwmark 0xffffaac lookup 13 105: from all fwmark 0xffffaac blackhole 106: from all fwmark 0xffffaad lookup 15 107: from all fwmark 0xffffaad blackhole 108: from all fwmark 0xffffaae lookup 17 109: from all fwmark 0xffffaae blackhole 110: from all fwmark 0xffffaaf lookup 19 111: from all fwmark 0xffffaaf blackhole 112: from all fwmark 0xffffab0 lookup 21 113: from all fwmark 0xffffab0 blackhole 451: from <redacted_ip1> lookup 75 452: from <redacted_ip2> lookup 76 453: from <redacted_ip3> lookup 77 500: from all lookup 248 30001: from all lookup 1001 30002: from all lookup 1002 30003: from all lookup 1003 32766: from all lookup main 32767: from all lookup default ~ # ip -6 rule 0: from all lookup local 100: from all fwmark 0xffffaab lookup 10 101: from all fwmark 0xffffaab blackhole 102: from all fwmark 0xffffaac lookup 12 103: from all fwmark 0xffffaac blackhole 104: from all fwmark 0xffffaad lookup 14 105: from all fwmark 0xffffaad blackhole 106: from all fwmark 0xffffaae lookup 16 107: from all fwmark 0xffffaae blackhole 108: from all fwmark 0xffffaaf lookup 18 109: from all fwmark 0xffffaaf blackhole 500: from all lookup 248 32766: from all lookup main

У меня тоже не сразу завелось, так как устройство было в политике, в которой нужное соединение (вкуда роутить дополнительно) было выключено галочкой.

Поигрался с фичёй, получилось настроить всё что хотел, но делал приседания с dns-proxy debug, чтобы понять куда ломятся некоторые приложения. Есть какой-то адекватный способ мониторить DNS запросы от клиентов? Или может историю смотреть недавних запросов в Кинетике? show dns-proxy ничего интересного не показывает. Такой вариант нашёлся: opkg install wireshark tshark -i br0 -f "udp port 53" -Y "dns.flags.response == 0" -T fields -e dns.qry.name

Поделитесь что в нём такого особенного будет, кажется вы знаете больше нашего. Что-то опять для домохозяек?

https://help.keenetic.com/hc/ru/articles/360019699360-Учет-трафика

Задал вручную белый IP сервера через ip host на клиенте, но OC-клиент всё равно ходит на зарезолвленный через публичный DNS адрес. Ребутнул клиента, всё равно значение из ip host игнорируется. self-test следующим сообщением. Возможно это связано с предыдущей проблемой и она уже автоматически пофикшена, но всё же. upd: в 5.0a9 починилось.

Согласен с @Leshiyart, не хочется рубить с плеча, меня это тоже устраивает. Возможно есть и другие, кто пользуются этим не осознанно и тоже получают профит. По хорошему бы уметь и правильный режим и opt-in расщепление. Если сплит в политиках запретить, то девайсы в них будут думать что IPv6 есть, и даже могут иметь GUA адрес, а роутер при этом не будет пускать их по IPv6, что как-то так себе.

В ipv4 всё ок. # ip -6 route del default dev nwg6 metric 2000 pref medium # curl --interface nwg6 -6 ip.wtf curl: (7) Failed to connect to ip.wtf port 80 after 664 ms: Error # curl --interface nwg6 -4 ip.wtf 104.28.xx.xx ~ # curl --interface nwg6 ip.wtf 104.28.xx.xx

При настроенном IPv6 нет возможности дёргать curl на конкретном интерфейсе в ipv6 режиме: # curl --interface nwg6 -6 ip.wtf curl: (7) Failed to connect to ip.wtf port 80 after 4 ms: Error При добавлении дефолтного маршрута даже с самой низкой метрикой, всё начинает работать: # ip -6 route add default dev nwg6 metric 2000 pref medium # curl --interface nwg6 -6 ip.wtf 2a09:bac1:61c0:60::xxx Может Кинетик научится сам добавлять эти маршруты с метрикой, основанной на приоритетах ip global?

Окей, кажется я проникся вашим консенсусом и в целом понимаю вас. Сделал на основном профиле IPv6 соединение приоритетным, чтобы роутер включил всё что нужно, а уже политиками разрулил по сегментам и устройствам. Всё же есть некоторые нестыковки: При наличии приоритетного подключения 6in4 соединения же будут расщепляться, верно? В политиках разрешается расщепляться. Как быть с KeenDNS, если хочется анонсить IP с другого подключения? В принципе текущий подход приемлем, но кажется его можно разрешать и без приоритетного IPv6 подключения, например слегка расширив директиву local-prefix, добавив опциональный флаг "routable". ipv6 local-prefix (default | ‹prefix›) [routable] Пусть наличие этого флага включает анонс гейтвея, разрешает использование IPv6 с первого возможного подключения в дефолтном профиле и работу IPv6 в политиках. Эта opt-in фича удовлетворила бы кучу страдальцев без нативного IPv6, меня в том числе . Тем более в 5-й версии IPv6 зеленый свет, отличный повод сделать его ещё доступней.

Да, если его сделать самым приоритетным, то маршрут остаётся, но это прям wtf moment. Тут возникают дополнительные вопросы - почему IPv6 маршруты WG в такой же ситуации на месте? И почему выкл-вкл radvd восстанавливает маршрут на Vlan100? Точно надо грохать/игнорировать этот маршрут на старте интерфейса? Кинетик же через свой radvd не анонсирует себя как гейтвей, если самое приоритетное соединение без ipv6, поэтому плохо никому не должно быть. Очень прошу - почините это, маршрут в таблице должен оставаться, даже если соединение не приоритетное. На 5-й версии готов тестировать любой фикс, лишь бы это заработало адекватно. Это не так важно в данном случае. Предположим, что я из entware хочу делать запросы по ipv6, и рабочее соединение, пусть и не приоритетное, должно работать при явном вызове curl --interface eth2.100 -6. Сейчас это работает корректно для nwg*, и приоритеты тут не играют роли.

По self-test вижу что до рестарта radvd, в table_254 маршрута через fe80::be24:11ff:fe30:96b0 нет, а после рестарта он появляется. При этом в таблице политики table_14 он присутствует сразу. Кажется где-то здесь что-то не так.

Приложил скрытым сообщением два self-test, первый при запуске интерфейса, второй после рестарта radvd на другой стороне. DHCPv6 включен, префикс уходит, OPKG выключен. После включения интерфейса: После рестарта radvd:

Есть какие-нибудь подвижки или может рекомендации куда копнуть? У меня нет провайдера с IPv6, поэтому толком и глянуть негде как оно должно работать в реальности. Может какие dhcp опции надо выставить? Нужен ли DNS? В ситуации с проводным интернетом гейтвей же всегда должен быть link-local? Или есть другой механизм, который может использоваться у провайдеров? Как-то же оно работает у людей, и никто не жалуется...