qmxocynjca

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

Согласен с @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? Или есть другой механизм, который может использоваться у провайдеров? Как-то же оно работает у людей, и никто не жалуется...

Присоединяюсь к пожеланию. Честно говоря, когда в "шестерёнке" увидел кнопку для открытия журнала, то так и подумал он сейчас откроется поверх текущей страницы. По факту это так не работает - нажатие на ссылку перекидывает на страницу диагностики, что тоже не удобно, хочется оставить и текущую страницу и открыть диагностику. Что совсем фигово в текущей реализации - эта ссылка какая-то не стандартная, и средний клик по ней не работает, чтобы открыть журнал в новой вкладке. Что хочется в идеале - открытие журнала из шестерёнки должно просто открывать его поверх текущей страницы.

Отправил скрытым сообщением.

Словил в клиенте OpenConnect какое-то перманентное кэширование IP зарезолвленного домена. После перезагрузки роутера-сервера, он прописался у меня в xxx.keenetic.link на серый IP от другого провайдера, а потом в течение часа вернулся обратно на правильный статический публичный IP. Это я сам игрался с порядком провайдеров, так что ситуация рядовая. Клиент же, после разрыва, зарезолвил хост только один раз на серый IP и постоянно стал его использовать (около 20 часов подряд), без попыток зарезолвить его опять, когда домен уже указывал на другой IP. После ручного выкл-вкл OC-интерфейса на клиенте, всё сразу завелось. Я уже начал грешить что с мобильного оператора и это прикрыли. То ли OpenConnect не резолвит домен повторно по истечении TTL домена, то ли DNS-кэширование чудит. Судя по nslookup -debug у домена TTL 5 минут. Сервер 5.0A8, клиент 4.3.4. На клиенте провайдерные DNS активны, плюс используется публичный DNS-резолвер "Yandex.DNS - Базовый". cc @Le ecureuil

Добавить возможность задать вызов любой CLI команды через нажатие кнопки. На каждый вариант нажатия (короткий, длинный, двойной) можно вписать список команд. Юзкейс может быть совершенно любым, это должно легко добавить +100 очков к конфигурабельности девайсов за минимальную стоимость. Пример: system button WLAN on click do CliRun "interface Wireguard0 up" "interface Wireguard1 up" system button WLAN on double-click do CliRun "interface Wireguard0 down" "interface Wireguard1 down" Ну круто же! Выхлоп команд или неудачу парсинга пускать в диагностику для лёгкой отладки. Навеяно вот этим ChatGPT ответом. Современные реалии таковы, что нейронка может придумать функционал, который зачастую является очень логичным и адекватным. Не иметь такую возможность в стандартной прошивке кажется упущением.

Путём экспериментов выяснилось, что гейтвей не устанавливается, если RA был обработан до перехода ipv6 на интерфейсе в состояние "running": Ip6::Dhcp::Client: "GigabitEthernet0/Vlan100": state "bound". Network::Interface::Ip6: "GigabitEthernet0/Vlan100": interface "GigabitEthernet0/Vlan100" is global, priority 65278. Network::Interface::Ip6: "GigabitEthernet0/Vlan100": adding default route via GigabitEthernet0/Vlan100 (fe80::be24:11ff:fe30:96b0). Network::Interface::Base: "GigabitEthernet0/Vlan100": "ip6" changed "ipv6" layer state "pending" to "running". @Le ecureuil есть шанс на фикс?

Ситуация: Есть незамысловатый интерфейс GigabitEthernet0/Vlan100: На другой стороне запущен radvd с radvd.conf: Где ens19: Проблема: при включении интерфейса в Кинетике, он успешно отсылает RS и получает RA (видно по tcpdump), в логах даже видно что дефолтный маршрут получен и выставлен: Network::Interface::Ip6: "GigabitEthernet0/Vlan100": adding default route via GigabitEthernet0/Vlan100 (fe80::be24:11ff:fe41:8d08). но по факту интерфейс конфигурирует только адрес, а шлюз не появляется ни в ip -6 route, ни в разделе Маршрутизация. Периодические перепосылы RA так же не добавляют гейтвей. Однако, если остановить и запустить radvd на другой стороне (именно так, т.к. stop отсылает RA с lifetime 0), то маршрут "::/0 fe80::be24:11ff:fe41:8d08" на Кинетике успешно появляется во всех местах где он должен быть виден (на карточке интерфейса, в разделе Маршрутизация, в ip -6 route). По ощущениям это выглядит как гонка, когда маршрут ещё не может быть добавлен по какой-то причине на старте интерфейса. Префиксы менял, dhcpv6 с делегацией подсовывал, параметры в radvd крутил, всё в итоге свелось к такому минимально-воспроизводимому сетапу. Прошивка 4.3.4, селф-тест следующим сообщением.

Сейчас если на основной политике нет ipv6 на первой позиции, а в другой политике есть, то без костылей с ручной правкой конфига radvd нет возможности получить ipv6 в этой политике. Выглядит как баг, если честно. Уважаемые разработчики, а не прикидывали ли запуск radvd в unicast режиме с ACCEPT-ом RS сообщений по мак-адресам устройств, которые по правилам политик должны уметь в ipv6, и DROP-ом от остальных устройств? А то сейчас либо RA либо включен для всех, либо выключен для всех. Вроде в теории должно работать, но какие там подводные камни - сложно предсказать. Такой сетап позволил фильтровать RS запросы: insmod ip6table_raw.ko ip6tables -t raw -I PREROUTING -p ipv6-icmp -m icmp6 --icmpv6-type router-solicitation -m mac --mac-source <mac> -j DROP interface br0 { AdvSendAdvert on; UnicastOnly on; AdvDefaultLifetime 1800; ... } Вообще, конечно, просто разрешить использовать первый доступный ipv6 в политике кажется логичным и решило бы проблемы большинства в этом треде. Можно сделать это опциональным флагом через CLI, если это прям не хочется включать по-дефолту.

Присоединяюсь. Настроил у себя аналогичную историю и столкнулся с теми же ограничениями веб-интерфейса. Вроде как не критично, но ощущается недоработка в этом направлении. По логике эта тема должна быть в KeeneticOS -> Веб-интерфейс, так как с точки зрения CLI всё работает, а вот в веб есть искусственное ограничение, предполагающее что на одном порту может висеть либо один провайдер, либо несколько локальных сетей. На самом деле там может висеть и несколько провайдеров и несколько локальных сетей одновременно.

Тоже смущало это, но потом увидел что дополнительные несущие вступают в работу, когда пропускной способности активных не хватает. Загрузите канал и проверьте.

Если речь про opkg, то вкину свои 5 копеек: 3proxy умеет прокидывать DNS запросы через заданный интерфейс. Dante правильно работает с ipv6 и udp, но вот DNS пока умеет только через системный резолвер, что никак не обойти. Смотря каким инструментом пользуетесь, такие нюансы и получаете.

Кажется я тоже сталкивался с подобной задачей. Находилось только такое, но там всё через entware крутили. Есть уже какое-то прошивочное решение (пусть и через CLI)?

Да кажется просто надо аплоадить на него уже пожатые gzip-ом файлы и говорить Content-Encoding: gzip. Судя по доке, на отдаче сервер сам разберется - отдавать как есть или расжимать, если клиент совсем тупой. https://cloud.google.com/storage/docs/transcoding

Согласен, не настаиваю. А вот прямую ссылку было бы вполне к месту добавить.

Заметил странное - pdf-ки с инструкциями всегда отдаются не сжатыми с сервера, даже если браузер может и gzip и brotli. Занимают они в районе 7 мегабайт, а пожатые около трёх. Было бы не плохо сжимать их, все современные юзер-агенты как минимум умеют gzip.

Да не, в интернетах то я и сам могу найти плюс-минус подходящую инструкцию. Тут вопрос удобства доступа сразу к правильному документу в один клик.

Прошивки разные, устройства разные. Было бы круто иметь ссылку на актуальную версию инструкции именно для твоей модели и версии прошивки на http://192.168.1.1/a. Ещё в порядке бреда (или не совсем) - добавить опциональный компонент "Справочник команд", чтобы он был доступен в оффлайн-режиме для просмотра прям со встроенного веб-сервера.