Странно, два одинаковых устройства, на одном работает, а другом нет. Какой конфиг используется? Когда настраивали? Я тут сейчас только обновил его немного.
Вот они сейчас одновременно выполняются, делая одно и тоже. Как сможете просто обновите 000-zapret.sh и переместите netfilter.hook.sh куда-нибудь. После этого посмотрим, что будет в журнале и будет ли отваливаться.
Так вот, как я и писал уже выше: "Тут нужно разбираться и ловить из-за чего там процесс падает, и как у Вас скрипты, которые не имеют никакого отношения к процессу nfqws (один настраивает параметр ядра, а второй таблицу iptables) вызывают его падение, при том, что старые, что новые скрипты делают по сути одно и тоже! ". Пока все, кто писали, что с моими новыми скриптами не работает, а старыми работает, так никакой технической информации и не предоставили, кроме просто констатации факта.
Я перед выкладыванием все тестирую, запрет у меня неделями работает стабильно. Да, так-то конечно, существует множество разных роутеров, версий прошивок, конфигураций пользователя и режимов использования, и я не имею возможности протестировать на всем.
Так он же в инструкции есть 10-keenetic-udp-fix , уже давненько, как добавлен. Странно конечно как-то, делали по инструкции, а ничего не работает, что должно. Ладно, главное, что работает теперь.
У Вас 99% опечатка или спец. символы в скрипте /opt/etc/ndm/netfilter.d/000-zapret.sh, проверяйте с использованием редактора vi. И посмотрите в системном журнале в веб-интерфейсе ошибки по этому скрипту.
Режим, да, none. Сколько оперативной памяти с таким списком используется?
Так нужно лечить проблему, а не симптомы. Если какие-то соединения падают от запрета, это скорее всего от того, что до серверов доходят фейковые пакеты и не отбрасываются ими, как некорректные. Нужно экспериментировать с параметром dpi-desync-ttl и dpi-desync-fooling, я сейчас выбрал dpi-desync-ttl=1 для себя, так как обнаружил, что некоторые сайты падают с оригинальным TTL (dpi-desync-ttl=0). А использование zapret-hosts-user.txt, это уже крайний вариант, тем более с таким огромным списком доменов. Это сколько там накладных расходов ресурсов, чтоб проверять по таким спискам.
У меня все версии Zapret работают стабильно на том же роутере и прошивке, что и у Вас. Я обновляю версию где-то раз в неделю в выходные, как правило, и потом у меня он всю неделю работает, без глюков и перезагрузок.
Тут нужно разбираться и ловить из-за чего там процесс падает, и как у Вас скрипты, которые не имеют никакого отношения к процессу nfqws (один настраивает параметр ядра, а второй таблицу iptables) вызывают его падение, при том, что старые, что новые скрипты делают по сути одно и тоже!
А автор Zapret говорит, что не имеет роутеров keenetic и не хочет связывается с проприетарной KeeneticOS, потому, что не известно, что там сделали разработчики. Просто, вполне может оказаться, что проблема где-то в прошивке, а не в утилите, как это было с утечкой памяти!
Я так и не понял, у Вас запрет падает на совсем или через какое-то время начинает снова работать сам?
Если падает совсем, значит скорее всего процесс nfqws падает, проверяйте утилитой pc.
Если через какое-то время начинает сам заново работать, возможно правила iptables затираются и не сразу восстанавливаются, смотрите наличие правил утилитой iptables-save .
А вот тут устарело - обновите код согласно статьи.
В общем итоговая рекомендация: обновить версию zapret до 69.2 по статье, обновить код в скрипте /opt/etc/ndm/netfilter.d/000-zapret.sh , как в статье. После этого всего посмотреть, чтобы в системном журнале роутера периодически появлялась строчка - Opkg::Manager: /opt/etc/ndm/netfilter.d/000-zapret.sh: Inserting iptables rule for keenetic udp fix : -o eth3 -p udp -m mark --mark 0x40000000/0x40000000., где eth3 - имя вашего WAN-интерфейса.
После этого думаю у Вас все хорошо будет работать.
Так и думал, у Вас из таблицы NAT пропадает MASQUERADE на WAN интерфейс. Покажите текущий код в скрипте /opt/zapret/init.d/sysv/zapret .
А вообще советую обновить на версию zapret 69.2, там появился скрипт 10-keenetic-udp-fix, который как раз отвечает за MASQUERADE на WAN интерфейс для кинетиков. Раньше у меня подобный маскарад был, как раз в скрипте /opt/zapret/init.d/sysv/zapret.
Ставьте версию zapret 69.2 с нуля по инструкции. Текущую папку zapret можно переименовать, если боитесь сломать, только предварительно zapret остановить.
И посмотрите по возможности, что выдаст команда iptables-save -t nat после отвала.
Да, все как в инструкции, ничего не менял, все работает. У меня тест выдает, что отвечают ДНС-сервера: Google в Lappeenranta, Finland и dns.adguard-dns.com и в Frankfurt am Main, Germany.
Странно, два одинаковых устройства, на одном работает, а другом нет. Какой конфиг используется? Когда настраивали? Я тут сейчас только обновил его немного.
Вот они сейчас одновременно выполняются, делая одно и тоже. Как сможете просто обновите 000-zapret.sh и переместите netfilter.hook.sh куда-нибудь. После этого посмотрим, что будет в журнале и будет ли отваливаться.
Скорее всего 000-zapret.sh просто не работает у Вас.
Посмотрите системный журнал, что выдают там сейчас 000-zapret.sh и netfilter.hook.sh .
Точнее сейчас не важно, сначала обновите скрипт 000-zapret.sh до нового, а потом посмотрите.
Это просто фактически одно и тоже делает, что и 000-zapret.sh . Удалите тогда скрипт 000-zapret.sh , он не нужен.
Так вот, как я и писал уже выше: "Тут нужно разбираться и ловить из-за чего там процесс падает, и как у Вас скрипты, которые не имеют никакого отношения к процессу nfqws (один настраивает параметр ядра, а второй таблицу iptables) вызывают его падение, при том, что старые, что новые скрипты делают по сути одно и тоже! ". Пока все, кто писали, что с моими новыми скриптами не работает, а старыми работает, так никакой технической информации и не предоставили, кроме просто констатации факта.
Я перед выкладыванием все тестирую, запрет у меня неделями работает стабильно. Да, так-то конечно, существует множество разных роутеров, версий прошивок, конфигураций пользователя и режимов использования, и я не имею возможности протестировать на всем.
Так он же в инструкции есть
10-keenetic-udp-fix, уже давненько, как добавлен. Странно конечно как-то, делали по инструкции, а ничего не работает, что должно. Ладно, главное, что работает теперь.У Вас 99% опечатка или спец. символы в скрипте
/opt/etc/ndm/netfilter.d/000-zapret.sh, проверяйте с использованием редактора vi. И посмотрите в системном журнале в веб-интерфейсе ошибки по этому скрипту.Режим, да, none. Сколько оперативной памяти с таким списком используется?
Так нужно лечить проблему, а не симптомы. Если какие-то соединения падают от запрета, это скорее всего от того, что до серверов доходят фейковые пакеты и не отбрасываются ими, как некорректные. Нужно экспериментировать с параметром dpi-desync-ttl и dpi-desync-fooling, я сейчас выбрал dpi-desync-ttl=1 для себя, так как обнаружил, что некоторые сайты падают с оригинальным TTL (dpi-desync-ttl=0). А использование zapret-hosts-user.txt, это уже крайний вариант, тем более с таким огромным списком доменов. Это сколько там накладных расходов ресурсов, чтоб проверять по таким спискам.
У меня все версии Zapret работают стабильно на том же роутере и прошивке, что и у Вас. Я обновляю версию где-то раз в неделю в выходные, как правило, и потом у меня он всю неделю работает, без глюков и перезагрузок.
Тут нужно разбираться и ловить из-за чего там процесс падает, и как у Вас скрипты, которые не имеют никакого отношения к процессу nfqws (один настраивает параметр ядра, а второй таблицу iptables) вызывают его падение, при том, что старые, что новые скрипты делают по сути одно и тоже!
А автор Zapret говорит, что не имеет роутеров keenetic и не хочет связывается с проприетарной KeeneticOS, потому, что не известно, что там сделали разработчики. Просто, вполне может оказаться, что проблема где-то в прошивке, а не в утилите, как это было с утечкой памяти!
Я так и не понял, у Вас запрет падает на совсем или через какое-то время начинает снова работать сам?
Если падает совсем, значит скорее всего процесс nfqws падает, проверяйте утилитой
pc.Если через какое-то время начинает сам заново работать, возможно правила
iptablesзатираются и не сразу восстанавливаются, смотрите наличие правил утилитойiptables-save.Удалите скрипты
000-zapret.shиS00fix:1)
rm /opt/etc/ndm/netfilter.d/000-zapret.sh2)
rm /opt/etc/init.d/S00fixПотом перезагрузите роутер.
Первые два при включённом DoT вообще игнорируются. Сервера у меня такие же выдает.
А вот тут устарело - обновите код согласно статьи.
В общем итоговая рекомендация: обновить версию zapret до 69.2 по статье, обновить код в скрипте
/opt/etc/ndm/netfilter.d/000-zapret.sh, как в статье. После этого всего посмотреть, чтобы в системном журнале роутера периодически появлялась строчка -Opkg::Manager: /opt/etc/ndm/netfilter.d/000-zapret.sh: Inserting iptables rule for keenetic udp fix : -o eth3 -p udp -m mark --mark 0x40000000/0x40000000., где eth3 - имя вашего WAN-интерфейса.После этого думаю у Вас все хорошо будет работать.
Все нормально тут. А какой сейчас код в скрипте
/opt/etc/ndm/netfilter.d/000-zapret.sh?Да там главное, чтобы тест не выдавал ДНС-серверов, находящихся на территории РФ.
Так и думал, у Вас из таблицы NAT пропадает MASQUERADE на WAN интерфейс. Покажите текущий код в скрипте
/opt/zapret/init.d/sysv/zapret.А вообще советую обновить на версию zapret 69.2, там появился скрипт 10-keenetic-udp-fix, который как раз отвечает за MASQUERADE на WAN интерфейс для кинетиков. Раньше у меня подобный маскарад был, как раз в скрипте
/opt/zapret/init.d/sysv/zapret.Ставьте версию zapret 69.2 с нуля по инструкции. Текущую папку zapret можно переименовать, если боитесь сломать, только предварительно zapret остановить.
И посмотрите по возможности, что выдаст команда
iptables-save -t natпосле отвала.Да, все как в инструкции, ничего не менял, все работает. У меня тест выдает, что отвечают ДНС-сервера: Google в Lappeenranta, Finland и dns.adguard-dns.com и в Frankfurt am Main, Germany.
Все работает со старым синтаксисом конфигурации.
Обновил инструкцию по установке с учетом добавки 10-keenetic-udp-fix в zapret 69.1.