hoaxisr

В смысле совсем не сдох? А чем ему плохо при нагрузке то? Ну стоит себе, пашет. Ну нагрузка у него по попугаеметру из WebUI сколько там попугаев, и?

Я вам привел пример того как работают "сложные" сайты у которых далеко не один домен. Я думаю, что вам проще установить клиенты на каждом устройстве и включать их по мере необходимости. Потому что идея настроить все на роутере будет сложно выполнимой.

Вернитесь. Раз так проще. Если так работает это означает только одно - ваши маршруты не содержат всего необходимого. Где вы их взяли и почему решили, что они полные мне неизвестно. Более того приложение на ТВ и когда вы заходите через браузер на ПК или ещё где-то в интернете используются разные домены и соответственно IP.

Я думаю да. При загрузке что-то похоже выводится в лог.

Это разговор не имеет практического смысла. Что делал автор топика и где он, что "настроил" неизвестно, он просто наугад меняет все подряд настройки всего подряд и надеется получить результат, который ему необходим. Даже элементарный вопрос о том, а уверен ли автор в том, что его "настроенные маршруты" покрывают все домены необходимые для работы трубы имеет совершенно прогнозируемый ответ "нет". Как вам выше подсказали самый простой способ проверить работоспособность вашего туннеля это создать политику подключения, в ней поставить галку только у вашего туннеля, у остальных выключить, а потом перетащить в эту политику телевизор. Если так будет работать, то проблема только в ваших списках маршрутов. Да и в 2025 строить маршрутизацию по маршрутам до сервисов с CDN/большим количеством доменов это утопия. Ну и вообще, поставить клиент на самом ТВ и включайте когда он нужен и не мучайте себя

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

Это скорее как направление для исследования. Вообще 20мб конечно мало, но некоторые полезные пакеты могут установлены. Скорее один за раз.

Crowdsec вырастает! :)) А если серьезно, отличная идея

Лучший способ это по умолчания дать возможность устанавливать в память роутера entware и отказаться от бесполезного dualboot'a в нем смысла ровно 0. Потому что во-первых там не сохраняется старый образ прошивки при обновлении, что просто и совершенно не ясно для чего он может быть полезен, т.к. для хранения start-up config в двух вариантах нужно явно меньше пространства. Вариант, при котором вдруг первый образ будет как-то нарушен ничтожен.

Честно говоря это третья ссылка по ключевым словам "dual boot"

Тут на форуме лежит инструкция как отказаться от дуалбута и использовать это место под хранилище. +50мб чего более чем.

Хм. Скорее всего вы делаете что-то не так. Если 80/443 в разделе переадресация портов у вас настроена на машину с вашим реверс прокси, то на роутере не нужны сертификаты. Они должны быть настроены на прокси куда идёт проброс. И там можно настроить и сертификаты для keendns доменов и ими тоже рулить. и в этом смысле кинетик не отличается от других роутеров, у него в такой настройке только одна задача, просто переадресовать все что пришло на порты 80/443 на настроенный вами узел, где вы это сами уже будете обрабатывать при помощи какого-то реверс прокси. Если вы не хотите так делать, то проще чем cloudflare tunnel нет наверное ничего.

Только обходными путями. Pangolin/cloudflare tunnel/tailscale и подобными. Или Проброс портов 80/443 куда вам нужно и перекинуть сервисы самого кинетика. А из вашего реверс прокси разруливать уже и своим и не "своим" доменом.

Вы на контроле посмотрите, там скорее будет при каждом действии в логах Propagating/topolgy changed и прочая, прочая

Я видимо не понимаю, как вы делите runtime информацию и конфиг, потому первое проистекает из второго, и не может существовать само по себе в моем понимании. Вот например банальная штука как узнать текущее состояние nat на интерфейсе, это runtime? Или конфиг? Простите, что отвлекаю, но просто хотелось бы понять критерий.

Смысл в этом вообще-то есть. Смотреть running-config для всего на свете явно менее удобно, чем командой получить список и делать с ним что необходимо. Подход отсутствия команды show для просмотра текущего состояния многих настроек прослеживается во многих вещах, и это крайне часто просто неудобно. Для примера - я хочу скриптом, а не руками забить несколько сотен доменных имен, перед этим необходимо проверить их наличие/отсутствие в другой группе, явно проще сделать show | grep и по результату уже действовать.

Имеете в виду, где настроить свои правила маршрутизации? WebUI сервиса доступен по адресу http://192.168.1.1:8080 (если вы не меняли IP роутера)

В общем случае да. Настраиваете соответствующий inbound, и подключаетесь клиентом используя этот вход. Если доступ нужен из вне, то нужен белый адрес и настройки firewall/port forwarding.

из репозитория magitrickle: wget -qO- http://bin.magitrickle.dev/packages/add_repo.sh | sh opkg update && opkg install magitrickle /opt/etc/init.d/S99magitrickle start

opkg install порядок команд. ну и если вы скачали уже файл, то может быть стоит его через WinSCP например уже сразу положить в роутер и устанавливать с роутера?

Последняя "стабильная" 4.3.4 - есть большое внутреннее сопротивление ставить эту версию. ( 4.3.2-то пришлось ставить по указанию техподдержки.) Вернусь к тестированию и информированию с появлением 5.х в бете или 4.3.х > 4.3.4 в стабильном канале.

В целом, да. Раз роутеров без wifi у Кинетик не имеется и планов таких решений видимо нет. То неплохо было бы иметь лицензию на контроллер, поскольку ставить головным роутер кинетик не хотелось бы, а точки доступа вполне себе конкурентные.

Абсолютно такое же поведение как у кинетик реализовано на openwrt - часть роутинга, который обеспечивает allowed-ips игнорируется и маршруты не создаются. Причина, я думаю, как в том, что вы описали, дефолт маршрут 0.0.0.0/0 на нескольких wireguard интерфейсах.

Добавлю sock5 в политике по умолчанию стоят в самом низу, вверху самый первым стоит основное PPPoE соединение с провайдером.

Текущая реализация точек доступа (Buddy, Voyager, и роутеров, переведенных в режим ретранслятор) предполагает наличие роутера Keenetic в качестве головного устройства (да, есть в базе знаний статья как использовать такой роутер без DHCP сервера), но железка все равно нужна. Предложение: выделить компоненты системы "Контроллер WiFi системы" как отдельный продукт с возможностью установки на x86/arm операционные системы для управления точками доступа Keenetic. Продавать на это ПО лицензию (тут уж маркетинг компании сам оценит стоимость/планы и так далее). Цель: дать возможность использовать и строить WiFi сети без головной железки Keenetic, на базе программно-аппаратных решений широкого спектра. Расширить позиционирование точек доступа как масштабируемое решение SMB.