Albram

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

В моем случае всё с точностью до наоборот. При 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 настраивался по методике из этой темы. Вопрос: куда поместить правило, чтобы оно корректно работало?

Есть ли смысл обновляться на чёрной (первой) ультре с 2.15.C.3.0-0 до 2.15.C.3.0-2 ? Из описания изменений увидел для себя смысл в обновлении только в последнем пункте. И то, вряд ли у актуальных и архивных моделей аппаратный ускоритель одинаковый. Улучшения: Wi-Fi: улучшена работа роуминга; Wi-Fi: исправлена совместимость с клиентами, высылающими Null data фреймы между Auth и Assoc; Wi-Fi: драйвер обновлен до версии 5.0.3.2 (для Keenetic Giga, Ultra, Viva); VPN-сервер: исправлено подключение клиентов Mikrotik; Исправлена проблема пропуска PPPoE (PPPoE Passthrough) через аппаратный ускоритель. UPD: Обновился, версия Fast VPN стала выше, похоже смысл всё-таки есть и вопрос потерял актуальность: Было: Стало:

Спасибо! Помогло.

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

Обнаружилась проблема с открытием кинозала при включенных правилах для IPv6. Открывается раз в десять-пятнадцать раз и без графики (только текст). В остальных случаях открывается пустое окно. Сначала думал проблема в браузере с кэшированием. Но в трёх браузерах (Chrom, Edge, Firefox) картина одинаковая. tcpdump при открытии пустого экрана показывает: При успешном открытии без графики:

В скрипте для перехватчика ndm заменил действие I на A, иначе не работало, и добавил проверку на существующие правила и ключ -w по совету @Александр Рыжов От "ругани" в логе об уже существующей цепочке избавился заменив в скрипте перехватчика ip6tables -t mangle -N DIVERT на ip6tables -t mangle -C DIVERT -w -j ACCEPT 2>/dev/null || ip6tables -t mangle -N DIVERT -w Костыль, конечно, но красивее пока не получилось. Теперь в логе появляются такие строки, но реже чем были про уже существующую цепочку: Ещё осталось https ipv6 завернуть в тор. Кстати, в основном скрипте в секции modification нет правила iptables для https ни для start, ни для stop. Добавил у себя:

Разгадка у меня оказалась простая - этот хост был в blacklist-domains.txt в dnscrypt )

Руками нормально: ~ # dig AAAA +short +time=8 +tries=2 st.kinozal.tv 2606:4700:30::681b:8d44 2606:4700:30::681b:8c44 Проблема начинается после "| sort -u …" UPD: ошибку вызывала строка static2.rutracker.org в файле zapret-host-user.txt