keenet07

Последняя уже Версия 3.3 Beta 5 (официальная бета) А вообще наверное скоро и релиз. Честно говоря не знаю как это поможет со SkyDNS. В общем, можете рискнуть залить через Рекавери новую прошивку. Если всё сростется, то будет работать. Если нет, придётся или назад откатываться, на ту что была. Желательно, чтоб у вас была слитая когда-то с настроенного роутера текущая прошивка. (именно с вашим набором компонентов) Или всё-равно, так или иначе, производить сброс настроек и полную настройку роутера.

А в чем вообще цель обновления?

Не просто нажать во время работы. А именно зажать в выключенном состоянии роутера. 3. Нажмите на интернет-центре кнопку "Сброс" и, удерживая ее, включите питание интернет-центра.4. Отпустите кнопку "Сброс", когда на интернет-центре начнет мигать индикатор "Статус". Это перевод устройства в режим Recovery. Впрочем, если опасаетесь, лучше не делать. Там много чего может пойти не так. Мы ведь не знаем вашу конфигурацию и набор компонентов.

Когда я так обновлял свой старый роутер все настройки сохранились. И старый пароль и правила Межсетевого экрана. А вот сброс точно всё сотрет.

Можно. Через Recovery. https://help.keenetic.com/hc/ru/articles/214470865 Но установится базовый набор компонентов для той прошивки которую будете заливать.

Для этого я и задал автору вопросы.

Провайдер выдал вам по одному кабелю два белых адреса? И присваиваются они по MAC адресам устройств? Один для Keenetic, второй для вашей железки. Или выдаются посредством разных PPPoE соединений? Или через разные VLAN? Вы хотите железку поместить в локалку и сохранить ей её белый IP? А как оно у вас было подключено до того как вы железку в локалку потащили? Через тот самый свитч?

Нужно вот такое правило. Но только для исходящего соединения. Пока-что вы его создать не сможете. Сейчас у вас нет такой вкладки в Межсетевом экране. Там все для входящих.

Зачем у вас в адресе источника стоят эти адреса? Это адреса DNS серверов? Их тут быть вообще не должно. Мы сейчас блокируем обращение к DHCP серверу.

DHCP это чисто UDP 67, причем блокировать нужно исходящий запрос на интерфейсе PPPoE. Что обычным правилом в веб-интерфейсе вы не сделаете. Нужно из CLI блокировать исходящее. Или если интересно могу подсказать как сделать вкладку для Межсетевого экрана с Исходящими на нужном интерфейсе. И уже в ней создать правило блокировки UDP 67. А где вы блокируете я так и не понял. Вместо интерфейса пишите мне о протоколе.

Покажите правило блокировки DNS. Имейте в виду что создавая правила вы блокируете входящие соединения. Запрос DNS это исходящее на 53, но ответ приходит с другого порта. Покажите на каком интерфейсе вы пытаетесь их заблокировать. И вообще. Если ваш PPPoE соединение сможет работать с выставленными вручную настройками вместо того, что идёт по DHCP, то просто заблокируйте сам запрос или ответ DHCP сервера. Это UDP 67. Соответственно не получите эти DNS адреса. И не нужно будет потом каждый блокировать. Они просто там не должны появиться, если всё правильно сделаете. Я же вам писал уже.

Вы про туннель ipv6 6to4? Вот тут посмотрите https://help.keenetic.com/hc/ru/sections/203192789-IPv6

Скорее всего 6 выйдет сегодня-завтра и в неё исправление не попало. Будет в 7.

Вот это разве не оно? <crl-verify>-----BEGIN X509 CRL-----... <--сюда вставить тело ключа из файла crl.rsa.2048.pem-----END X509 CRL-----</crl-verify> Опция crl-verify включает чёрный список отозванных сертификатов и указывает файл, из которого этот список нужно читать. crl.pem Список отзыва сертификатов CRL

А зачем его класть куда-то? Может быть его можно внутрь общего текстового конфига в виде какой-то секции запихать. Нужно изучать.

Ещё можно заблокировать сами IP адреса DNS серверов провайдера, если они не находятся вместе с какими-то другими необходимыми.

Если DHCP провайдера всё-равно умудряется где-то заслать вам пакет с DNS провайдера, я бы попробовал полностью заблокировать эти пакеты на интерфейсе с помощью Межсетевого экрана.

Понятно. Основная проблема у вас DNS провайдера от которых вы хотите избавиться. Настройте для проводного соединения вместо автоматического режима работы DHCP получение адресов вручную. И пропишите там адрес, маску подсети и шлюз которые вы получаете от провайдера, но поля DNS не заполняйте. Или впишите туда те которые вам нужны. Точно так же настройте и DHCP PPPoE соединения. Настройка IP: ручная. Всё. Больше им просто неоткуда будет взяться.

Вы так много написали, но сложно понять в чем вопрос. ) Обращение к DNS серверам идёт по наименьшему пингу (отклику DNS сервера). Если есть DNS провайдера, то он практически всегда из всего списка добавленных DNS серверов будет первым в этой цепочке, т.к. тупо находится ближе всего. По крайней мере всё это справедливо при настройке DoT/DoH серверов. Но по моему и для обычных так же. Если вопрос в чем-то другом. Напишите покороче что вы хотите. )

Увеличили же до 32. Вам хватит? ) 20 ТВ каналов. радио вам наверное не понадобится на телике. 12 в запасе. Не знаю с чем связано ограничение. Наверное чтоб не перегрузить устройство. Или не забить всю полосу пропускания.

По разному можно. Можно заходить с устройства для другого сегмента, не привязанного к VPN. Можно временно менять MAC на своем ПК и привязвывать новый к чистому инету. Можно попробовать настроить переадресацию порта. Может быть будет так работать. Стучитесь на роутер например на 4433 порт, а перенправляете трафик на нужный ИП с портом 443.

@vadimbn Если вместо ip адреса WAN-интерфейса указать адрес полученный VPN соединением на роутере, тоже будет работать?

Да ничего страшного не произойдет. Ну пропадет часть функционала и всего-то. Ничего страшного с чем бы не справилась техподдержка по "алгоритму на бумажке" даже в телефонном режиме. А вот если в CLI наковырять... Придётся долго изучать. Или сбрасывать всё к заводским настройкам, если ОС всё ещё загружается.

Но вот будет ли это потом работать так как задумал автор? Чтоб через второй неактивный интерфейс ходить через прокси? Или придётся режим балансировки включать и настраивать. Но будет ли такой режим отрабатывать в случае отваливания инета на основном? Больше вопросов чем ответов.

Насчёт первой половины вопроса. Нет никаких проблем. А вот на счет прокси не всё так просто. Если только что-то придумать с пакетами через OPKG.