Albram

Видимо да. Сейчас остановил 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

После запуска get_user.sh ~ # /opt/zapret/ipset/get_user.sh Adding to ipset zapret6 (hash:ip) : /opt/zapret/ipset/zapret-ip-user6.txt ipset v7.1: Error in line 1: Syntax error: cannot parse This query has been locally blocked: resolving to IPv6 address failed Adding to ipset zapret (hash:ip) : /opt/zapret/ipset/zapret-ip-user.txt ipset v7.1: Error in line 1: Syntax error: cannot parse This query has been locally blocked: resolving to IPv4 address failed Adding to ipset ipban (hash:ip) : /opt/zapret/ipset/zapret-ip-user-ipban.txt

Как оказалось - перезаписывается. Во всяком случае у меня на прошивке 2.15.C.3.0-0 если делать без перехватчика, то новые правила живут от 1 до 5 секунд. Мне не нравится как работают эти правила в перехватчике. Выше я писал, что либо постоянные ошибки в логе об отсутствии цепочки/цели, в эти моменты и пакеты не будут перенаправляться как надо, либо куча копий одних и те же правил с сообщением в лог об уже существующей цепочке. Надо будет добавить проверку на уже существующие правила, это хоть и замедлит обработку, но будет смотреться более эстетично:) Попробую ваш вариант с раздельными ipset, спасибо.

Набросал правил на примерах по вашей ссылке и отсюда, но пока не проверял. Есть сомнения по поводу наличия цели TPROXY и таблицу 100 сначала надо было создать. Update: В итоге работающий черновой вариант для проверки работоспособности метода получился пока такой: вручную добавил: ip -6 route add local default dev lo table 64 ip -6 rule add from all fwmark 1 lookup 64 Затем в /opt/etc/ndm/netfilter.d/ добавил файл: В zapret.ipset добавил ipv6 адреса, tpws запускал удалив из опций --bind-addr так он слушает и на ipv4 и на ipv6 порту. Нужно будет посмотреть на предмет оптимизаций. Ввести проверку на уже существующие правила ip -6 route и ip -6 rule. чтобы не удалять/создавать их по каждому вызову из ndm. Ещё при таком методе весь ipv6 трафик на 80 порт заворачивается в прокси, а это не нужно. В лог роутера очень часто пишутся события срабатывания этих правил (после того, как написал сюда, я добавил строчку внесения в лог по срабатыванию этого файла). Причём, если оставлять в файле строки очистки цепочки DIVERT и её удаления, то в логе ещё периодически присутствую ошибки от ip6tables об отсутствии цепочки/цели. А если эти строки убрать, то в списке правил создаются одинаковые правила, количество их зависит от частоты вызовов файла и составляет от 1 до 22 (максимальное что видел], и конечно в эти моменты имеем запись в логе, что цепочка уже существует. Так что, это просто пример, и к полноценному использованию пока не пригоден.