dartraiden

В виде отключённой по умолчанию опции. При включении опции должна меняться логика работы с DNS-серверами: 1) Защищённые DNS (DoH, DoT) больше не получают приоритет перед незащищёнными 2) Отключается мультирезолвинг (одновременная отправка запросов на несколько DNS-серверов). DNS опрашиваются по порядку их следования в списке. Если первый не ответил за определенное время, запрос идёт к следующему и так далее. Таймауты можно подглядеть в коде dnsmasq, там такая опция как раз есть. Какие проблемы это решает: - Есть популярный проект (для кое чего, что тут обсуждать запрещено, поэтому не будем), там необходимо, чтобы при поднятом VPN-туннеле роутер резолвил все домены исключительно через DNS на стороне VPN-сервера. Но если тоннель упал, то нужен какой-то fallback. В текущих прошивках получается неразрешимая ситуация: если в качестве DNS оставить только локальный адрес VPN-сервера, то при падении туннеля мы остаёмся без резолвинга вообще. А если добавить какой-то резервный DNS, то KeeneticOS шлёт запросы сразу на оба DNS. Сейчас это решается костылями в виде создания маршрутов, привязанных к интерфейсу, но хотелось бы более простой способ. - Решает описанную здесь проблему. Пользователь мог бы просто включить "строгий порядок опроса" и поместить DoH/DoT в самый верх, а ниже добавить "обычные" DNS.

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

Это не поможет в обсуждаемом случае. Если пользователь настолько беспечен, что ставит пароль admin или простой пароль, то он не будет и заморачиваться, чтобы менять дефолтный логин. Кроме того, никто не запрещает хоть сейчас создать другого пользователя, а admin-у урезать все права. Но этой возможностью никто из пострадавших, разумеется, не воспользовался. потому что пострадавшим плевать на безопасность. А если бы им было не плевать, у них был бы стойкий пароль, и тогда всё равно, какой там логин, их бы не взломали.

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

Обещание относилось к импорту конфигов, в которых секции Interface и Peer шли в обратном порядке. И это исправили.

По симптомам это блокировка со стороны провайдера/РКН. В KeeneticOS 4.2 добавили поддержку ASC для WG, пробуйте (на сервере параметры должны совпадать с клиентом).

Некоторые ресурсы (не будем показывать пальцем на 4pda) выпиливают даже это (для примера: топик, посвящённый обычному клиенту IPSec IKEv1, без каких-либо предустановленных профилей и настроек), то ли перестраховываясь, то ли уже реально обжегшись.

Адреса подсетей Google извесгны https://support.google.com/a/answer/10026322?hl=ru

Например, создать отдельный профиль DNS, завести DoH туда (а не в системный профиль), затем сегментам сети (Домашняя сеть, Гостевая сеть, etc) назначить этот профиль. Роутер для своих нужд (чтобы резолвить домены, к которым он сам инициирует обращение, типа проверки обновлений) будет использовать то, что в системном профиле, а клиенты будут использовать то, что в созданном для них профиле.

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

По какой-то причине прошивка не может сама найти бинарник, так что указывайте полный путь. /opt/sbin/xkeen -i

Наверное, всё же не ./, т.к. airprint-generate.py лежит в /opt/sbin, а не в текущем каталоге /opt/root

Если доступ на сайт по HTTPS, то считайте, что не реально. В HTTPS полный URL стороннему наблюдателю не виден, виден только домен. С помощью DNS вы можете только доступ к домену целиком заблокировать. Но не к отдельной странице на домене.