Albram

В принципе, вручную интерфейс создается/удаляется, адрес присваивается, делал вот так: wireguard wg0 ip addr add 10.7.7.1/24 dev wg0 ip link set wg0 up Но как только дело доходит до wg, причем в любых комбинациях wg set, wg setconf, wg addconf, то "Unable to modify interface: Protocol not supported" ~# wg setconf wg0 /opt/etc/wireguard/wg0.conf С вашими файлами, естественно тоже самое: Ждём с нетерпением new ipk files...

Первое сообщение "RTNETLINK answers: Operation not supported" из-за отсутствия type wireguard Второе "Unable to modify interface: Protocol not supported" в ответ, как уже писали выше, на: wg setconf wg0 /opt/etc/wireguard/wg0.conf Остальное, это уже следствие первых ошибок.

При запуске S01wireguard руками: Содержимое S01wireguard и wg-up:

Аналогичная проблема на Keenetic Ultra 2.16.D.1.0-0. Видимо чего-то не хватает. А жаль, вещь интересная и нужная.

Ошибся при написании. Конечно же, не на любом порту слушать, а на любом адресе, т.е.: listen_addresses = ['0.0.0.0:53']

Сегодня нашел причину "дыры" описанной мной в этой теме ранее Напомню: DNS сервер откликался на запросы снаружи на udp/53 на внешний адрес кинетика. Firewall включен, nmap не показывал этот порт открытым. Обходным решением тогда оказалось, как ни странно, указание в настройках dnscrypt-proxy2 слушать на любом порту, вместо 127.0.0.1:53 и 192.168.1.1:53, как было у меня раньше. При этом, при внешних запросах, ответов от dns сервера не было (на внешнем клиенте был таймаут ответа от сервера), но в активных подключениях кинетика всё равно появлялось это соединение. Менялись версии прошивки, от 2.13 в момент обнаружения проблемы, до 2.16 сейчас, обновлялся Entware, но проблема оставалась. В итоге, в моем случае причиной оказалось срабатывание правила: Chain PREROUTING (policy ACCEPT 72 packets, 6120 bytes) num pkts bytes target prot opt in out source destination 3 15 981 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 to:192.168.1.1:53 Которое создавалось скриптом /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh, который описан в шапке этой темы в разделе "Перехват всех DNS запросов на роутере. "Приземление" DNS трафика". Доработал его, указав исключение внешнего интерфейса: Было: [ -z "$(iptables -nvL -t nat | grep "to:192.168.1.1:53")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53 Стало: [ -z "$(iptables -nvL -t nat | grep "to:192.168.1.1:53")" ] && iptables -t nat -I PREROUTING -p udp ! -i ppp0 --dport 53 -j DNAT --to-destination 192.168.1.1:53 После этого, при внешних запросах на udp/53, dns сервер не отвечал и соединение в активных подключениях не появлялось. Возможно, такое решение имеет недостатки (например, в случае, когда запросы прилетят со стороны провайдера по IPoE, минуя PPPoE), и кто-то предложит более "элегантное" решение.

После апгрейда всё стало правильно, Спасибо!

Upgrade делал месяца два назад. Сейчас глянул, действительно доступен новый пакет iptables. Буду апгрейдить. Спасибо. Извиняюсь за беспокойство, сам оказался виноват 😐 ~ # opkg update ~ # opkg list-upgradable ... iptables - 1.4.21-3 - 1.4.21-3a ...

Отвечу сам себе: не подойдет, т.к. версии всё-таки разные и платформы отличаются. Указанный выше: iptables_1.4.21-2_mipsel-3x.ipk, а сейчас установлен: iptables_1.4.21-3_mipsel-3.4_kn.ipk

Спасибо за ответы. Этот пропатченый пакет подойдёт для старой ультры с прошивкой 2.16? Текущая версия iptables такая же - 1.4.21. И не будет ли проблем при использовании маркировки в Entware после установки патча?

Исходные данные: Keenetic Ultra (старый чёрный) с прошивкой 2.16.D.1.0-0 и Entware BusyBox v1.31.0. 1. Недавно в "Сетевые правила -> Переадресация" появился открытый через UPnP порт. Мне понятно, что источником его открытия был недавно начавший использоваться AnyDesk, но непонятно почему он открыт именно на этот интерфейс от VMware, хотя AnyDesk используется не из виртуальных машин, а локально на компе с адресом из локальной подсети 192.168.1.0/24. Правило это не удаляется после прекращения использования AnyDesk. Адрес 192.168.127.1 пингуется, т.к. этот сетевой интерфейс поднят. Собственно вопрос: оно не должно удаляться само, и нужно ли оно вообще? 2. В правилах iptables увидел вот это, это нормально?

Имеется старый (чёрный) Keenetic Ultra с прошивкой 2.16.D.1.0-0. В настройках в Web GUI имеются обе облачные службы, и Keenetic Cloud, и Keenetic Cloud 2 (с пометкой beta). Обе службы включены, оба приложения установлены и работают. Несмотря на предупреждение при запуске приложения Keenetic, о том, что необходим интернет-центр с версией прошивки 3.x, оно работает и на 2.16. В соединениях постоянно есть два входящих UDP соединения на WAN интерфейс по портам 4044 (это, как я понимаю, старая облачная служба) и 5683 (новая). Т.к. такое дублированное управление мне не особо нужно, возник вопрос, какое из служб и приложений оставить? Выбор было бы проще сделать, знай я ответы на вопросы: 1. Старая облачная служба и приложение My.Keenetic долго ещё будут работать и поддерживаться? 2. Т.к. работоспособность нового приложения Keenetic не заявлена с версиями прошивок ниже 3.x, не получится ли так, что через какое-то время оно перестанет работать (и, как обычно такое бывает, в самый неподходящий момент)? Это больше риторический вопрос, т.к. понимаю, что никто никаких гарантий на этот счёт не даст, просто, может у разработчиков есть какие-то планы на этот счёт. 3. Какая из этих служб/приложений более защищена (более безопасна при использовании) ?

Да, потому мне пришлось отказаться от использования ipv6, из-за описанной выше проблемы. Когда читал этот топик, мелькнула мысль: "а вдруг?". Но нет.

Я так понимаю, что это актуально только для прошивок 3.x на ядре ndm 4.x, т.к. на 2.16.D.1.0-0 с ядром 3.4.113 указанных модулей нет в /lib/modules/3.4.113/. Из-за отсутствия nat в ipv6 в 2.16 приходится "извращаться" с перенаправлением пакетов через маркировку. Вместо одного правила получается несколько, и в перехватчике ndm часто бывает так, что какое-то правило не добавляется, и вся цепочка становится на время неработоспособной при частой очистке правил прошивкой. Использование ключа -w в правилах ip6tables улучшает ситуацию, но не устраняет полностью. С правилами iptables такой проблемы нет, только с ip6tables.

Всё правильно, должна эта команда отрабатывать. Во всяком случае описание команды interface совпадает что для старых версий 2.0x, что для новых: Хотя реакция на команду у ТС как будто указано имя несуществующего интерфейса.

Не должно быть такого ответа ""PPPoE0" interface created." это у вас новое соединение создалось, потому и ввод последующих команд не привёл к нужному результату. Для начала удалите это соединение: Затем посмотрите как у вас называются интерфейсы: show interface В списке ищите интерфейс с типом PPPoE и смотрите как он называется. Затем вводите команды (я здесь указал интерфейс PPPoE0, вам нужно использовать ваше имя интерфейса): interface PPPoE0 ipcp no name-servers system configuration save После этого посмотрите в файле конфигурации секцию вашего PPPoE интерфейса, она должна содержать эти две строки: interface PPPoE0 ipcp no name-servers ip dhcp client no name-servers Если строка "ip dhcp client no name-servers" отсутствует или имеет другое значение, то введите, заменив имя интерфейса на ваше значение: interface PPPoE0 no ip dhcp client name-servers system configuration save Это избавит от получения адресов DNS серверов по DHCP.

Да, действительно, эту строку нужно закомментировать, что-то я её пропустил когда описывал процесс. Спасибо что заметили.

В моем случае всё с точностью до наоборот. При listen_address = ['0.0.0.0:53'] и попытке nslookup <host> <IP_keenetik> извне получаем таймаут ответов dns сервера кинетика. Такое же наблюдается и при указании в качестве слушающего ipv6 адреса кинетика. В остальных других любых комбинациях listen_address получаем ответ dns сервера на внешний адрес кинетика. Настроено у меня по инструкции из первого поста этой темы с единственным отличием в том, что использую ещё и ipv6. До этого писал, что остановил dnscrypt-proxy и отключил opkg dns-override и доступ извне к DNS серверу пропал, но оказалось что при этом перестает работать резолв и из локальной сети. Было подозрение на правило в интернет-фильтре 192.168.1.1 для всех dns запросов, которое, начиная с версий 2.15, стало ругаться в лог на петлю: Но его удаление (без перезагрузки роутера) не давало результатов. При сканировании извне портов кинетика nmap-ом по tcp показывает только один открытый порт 21, на который на самом деле есть правило в firewall, но оно отключено. По udp пишет что все 1000 портов open | filtered, результаты не меняются при любых значениях listen_address. Оставил listen_address = ['0.0.0.0:53'] и коннекты извне пропали. По мере возможности буду продолжать искать источник проблемы.

Не ошибкой wget закончилось? Вот здесь есть предостережение: https://forum.keenetic.net/topic/5639-wget-gnu-wget-downloading-files-on-the-protocols-http-https-ftp-and-ftps/?do=findComment&comment=64939

Видимо да. Сейчас остановил dnscrypt-proxy и отключил opkg dns-override, Доступ извне к DNS серверу пропал.

Файерволл включен и на ipv4 и на ipv6.

Вернул, не помогло. Убрал этот адрес ещё в самом начале настроек, что-то было связано с тем, что когда он был в конфиге один, не резолвились хосты с роутера, потом добавил к нему 192.168..... всё стало нормально, попробовал его убрал, ничего не изменилось, так и оставил из-за тяги к минимализму) Т.е. чтобы запретить ndnproxy слушать на внешнем интерфейсе нужно изменить здесь? udp 0 0 0.0.0.0:54321 0.0.0.0:* 524/ndnproxy udp 0 0 :::50272 :::* 524/ndnproxy

Dnscrypt слушает на двух локальных адресах: ~ # grep listen_address /opt/etc/dnscrypt/dnscrypt-proxy.toml listen_addresses = ['192.168.1.1:53', '[fe80::xxxx:xxxx:xxxx:49d8%br0]:53'] ~ # Вывод netstat -apn | grep “:53” во время коннекта позже пришлю, сейчас нет возможности.

На днях случайно заметил на роутере коннекты извне (в основном из Китая) на 53 порт. IP у меня внешний, потому решил проверить, и действительно 53 порт оказался открыт всем желающим. Создал в Web-интерфейсе (версия 2.15.C.3.0-2) правило на PPPoE интерфейсе "запретить UDP с любого IP и порта на "мой IP" порт 53" и поместил его в начало цепочки. Правило создалось в таблице filter в цепочке @PPPoE0. Но оно не работает. Т.е. и с этим правилом коннекты на 53-ий порт извне проходят. Видимо срабатывает какое-то правило раньше этого. Выглядит это так: на компе, подключенном через другого провайдера, делаю nslookup ya.ru <мой IP> и на роутере в разделе Диагностика появляется коннект: В Entware во время коннекта: В конфигурации отключено использование dns и dns6 серверов провайдера на всех публичных интерфейсах (PPPoE, IPoE) и прошивочный dns сервер переведен в режим opkg dns-override, но, судя по выводу из Entware, срабатывает именно он. DNS-crypt настраивался по методике из этой темы. Вопрос: куда поместить правило, чтобы оно корректно работало?

Я в изначальном файле domains-blacklist.conf из шапки раскомментировал RU AdList и добавил ещё один источник: Блокирует неплохо, но частенько пропускает огромный верхний баннер на lenta.ru (использую его как один из проверочных для блокировщиков рекламы) и ещё несколько внутри страницы. Надо будет попробовать добавить ваш источник, спасибо.