Да, в инструкции --dpi-desync-ttl=0 (0 = TTL оригинального пакета). Я намерено это оставляю, так как если выберу какой-то конкретный ТТЛ - 1, 2, 3 и т.д., то у тех кто ставит может обход не заработать или работать частично из-за низкого ТТЛ, и фейки не будут пробиваться наружу.
Я как-то менял в статье TTL на 1, и мне потом начали писать, что не работает обход, при том, что у кого-то замена на 2 помогла, у кого-то на большее. Этот параметр очень зависимый от провайдера, и поэтому я в статье оставляю TTL=0, но указал, что в случае необходимости, подбираем под себя. А так достигшие серверов фейки отбрасываются по параметрам заданным в --dpi-desync-fooling.
А вообще, чтобы определить какая стратегия ломает сайты: фейки (fake) или сегментирование (multidisorder) - нужно убирать из конфига одну из стратегий и смотреть когда сайт починится. Если вина стратегии fake - то крутить параметры--dpi-desync-fooling и --dpi-desync-ttl, а если multidisorder, то там только--dpi-desync-split-pos или менять саму стратегию.
У меня multidisorder и сломал озон банк, но когда и из-за чего это произошло не знаю, так так проблем с оплатой покупок на озоне я и раньше не замечал, хотя может через мобильный интернет платил, точно уже не узнаешь.
В статье в конфиге обновил стратегии, заменил синтаксис --dpi-desync, а также самое главное - это изменения стратегии в --dpi-desync-split-pos, так теперь не ломаются некоторые и так рабочие сайты в режиме none (у меня наблюдались проблемы с доступом к озон банку). Так теперь ломающихся сайтов не замечено больше. Но также я еще в стратегиях использую --dpi-desync-ttl=1 (подбирается индивидуально) для большей гарантии недохождения фейков до серверов.
Теоретически никаких проблем со стороны роутера не должно быть. Но тут скорее всего возникнет проблема, что основной роутер не будет через себя пропускать фейковые пакеты, а будет отбрасывать их как некорректные. Для пропуска таких пакетов на нем нужно также менять параметр ядра nf_conntrack_checksum, как и на киненике или отказываться в стратегии от --dpi-desync-fooling и использовать только --dpi-desync-ttl с минимальным рабочим значением.
Вам нужно просто настроить TTL, и этот сайт вероятней всего не будет падать. От 1 начинайте увеличивать и смотрите, когда начнёт пробивать заблокированое, значит на это и останавливаетесь.
Да, пока все хорошо. Вообще по поводу падения процесса - на гите автора, как раз обсуждали эту проблему, что и привело к этому фиксу сегодняшнему. Один пользователь там заявляет, что на более 30 кинетиках тестирует, видно на поток поставил. Ну говорит, что проблема решена.
У меня сейчас недавно после обновления на версию 69.6 наглухо завис роутер, пришлось аварийно перезагрузить его. Может совпадения, но он у меня так никогда не зависал. Пока все работает, но нужно повнимательней с новой версией, а то может заместо аварийного падения процесса появилось аварийное падение всего роутера.
Просто, вставлять нужно через редактор vi или nano, иначе если через винду, то можно на вставлять не видимые спец. символы из-за которых потом скрипт и вываливается. Ну или по крайней мере контролировать после вставки - открывать в редакторе vi и смотреть, чтоб все было точно, как и должно, не одной лишней закорючки.
Только должно быть все наоборот! С большим TTL он доходит до серверов, а с маленьким нет. Странно как-то все работает. В использовании метода задания TTL есть только один минус - его возможно придется по себя подстраивать, необходимо найти минимальное значение, при котором обход еще работает, а TTL=0 - это неравно минимальный, а равно оригинальный, а он всегда большой будет, иначе ничего бы не работало.
Это понятно, но я прилагал, что просто замените в конфиге везде --dpi-desync-ttl=0 на --dpi-desync-ttl=2, и тогда у Вас с очень большой вероятностью все будет работать в режиме none. Я писал почему так, с --dpi-desync-ttl=0 у фейковых пакетов TTL оригинального пакета остается, а при --dpi-desync-ttl=2 TTL меняется меняется на 2, т.е. уничтожится после прохождения 2 узлов и до сервера точно не дойдет, а при оригинальном он доходит, но отбрасывается из-за установки --dpi-desync-fooling, но также некоторые серверы могут не отбрасывать и тогда соединение ломается. По этому изменение TTL более надежный способ, чтобы фейки не дошли, но главное, чтобы они миновали ограничители.
Они заявляли, что у них падает сам процесс nfqws, а не правила в таблице iptables. Предположительно, у @inkda1 из-за большого hostlist, потому, что прошивка и роутер у нас одинаковые, отличается только режим фильтрации, а проверять в режиме none - он не хочет.
В том то и дело, что скрипты делают просто фактически одно и тоже! Отличия заключается только в том, что мой скрипт вызывает функцию zapret_apply_firewall через /opt/zapret/init.d/sysv/zapret restart-fw, а в том хуке через /zapret/init.d/sysv/functions. И почему у Вас происходит ошибка не понятно, притом что вначале он работает нормально, она получается через какое-то время вылезает в модулеndm. А еще интересней, что мой старый скрипт не вызывает эту ошибку, хотя отличия в них только в том, что стал помимо таблицы mangle проверять изменения таблицы nat, что собственно делает и тот хук, один в один - [ "$table" != "mangle" ] && [ "$table" != "nat" ] && exit 0. Просто если не проверять это, как раз возможно появление проблемы с отвалом UDP протокола, так как для кинетика нужно делать маскарад на внешний интерфейс и следить, чтобы ОС его не затерла.
Да, ошибка в ndm вылезает, до неё не было ничего ещё? Какой роутер и версия прошивки?
Это нужно к разработчикам keeneticOS скидывать на форум, чтобы они смотрели, может исправят. Если не затруднит Вас, то скиньте туда. Просто только у Вас такая ошибка вылезает. И к zapret она не относится и процесс так же судя по всему не падает, а просто правила в таблице не восстанавливаются.
Ещё можете скинуть куда-нибудь сам файл скрипта, который вызывает эту ошибку, и скинуть мне.
Поставьте режим фильтрации none. Этот скрипт не выполняется zapret, а вызывается автоматически, когда таблица iptables обновляется роутером. Переодичность будет зависить конфигурации роутера. Какое содержимое скрипта 000-zapret.sh сейчас?
Странно, два одинаковых устройства, на одном работает, а другом нет. Какой конфиг используется? Когда настраивали? Я тут сейчас только обновил его немного.
Вот они сейчас одновременно выполняются, делая одно и тоже. Как сможете просто обновите 000-zapret.sh и переместите netfilter.hook.sh куда-нибудь. После этого посмотрим, что будет в журнале и будет ли отваливаться.
Да, в инструкции
--dpi-desync-ttl=0(0 = TTL оригинального пакета). Я намерено это оставляю, так как если выберу какой-то конкретный ТТЛ - 1, 2, 3 и т.д., то у тех кто ставит может обход не заработать или работать частично из-за низкого ТТЛ, и фейки не будут пробиваться наружу.Я как-то менял в статье TTL на 1, и мне потом начали писать, что не работает обход, при том, что у кого-то замена на 2 помогла, у кого-то на большее. Этот параметр очень зависимый от провайдера, и поэтому я в статье оставляю TTL=0, но указал, что в случае необходимости, подбираем под себя. А так достигшие серверов фейки отбрасываются по параметрам заданным в
--dpi-desync-fooling.А вообще, чтобы определить какая стратегия ломает сайты: фейки (fake) или сегментирование (multidisorder) - нужно убирать из конфига одну из стратегий и смотреть когда сайт починится. Если вина стратегии fake - то крутить параметры
--dpi-desync-foolingи--dpi-desync-ttl, а если multidisorder, то там только--dpi-desync-split-posили менять саму стратегию.У меня multidisorder и сломал озон банк, но когда и из-за чего это произошло не знаю, так так проблем с оплатой покупок на озоне я и раньше не замечал, хотя может через мобильный интернет платил, точно уже не узнаешь.
В статье в конфиге обновил стратегии, заменил синтаксис
--dpi-desync, а также самое главное - это изменения стратегии в--dpi-desync-split-pos, так теперь не ломаются некоторые и так рабочие сайты в режимеnone(у меня наблюдались проблемы с доступом к озон банку). Так теперь ломающихся сайтов не замечено больше. Но также я еще в стратегиях использую--dpi-desync-ttl=1(подбирается индивидуально) для большей гарантии недохождения фейков до серверов.Теоретически никаких проблем со стороны роутера не должно быть. Но тут скорее всего возникнет проблема, что основной роутер не будет через себя пропускать фейковые пакеты, а будет отбрасывать их как некорректные. Для пропуска таких пакетов на нем нужно также менять параметр ядра
nf_conntrack_checksum, как и на киненике или отказываться в стратегии от--dpi-desync-foolingи использовать только--dpi-desync-ttlс минимальным рабочим значением.Нет, это уже режим hostlist нужно использовать.
Вам нужно просто настроить TTL, и этот сайт вероятней всего не будет падать. От 1 начинайте увеличивать и смотрите, когда начнёт пробивать заблокированое, значит на это и останавливаетесь.
Хорошо, по версии 69.6, практически сутки прошли, все хорошо работает, никаких проблем пока не выявлено.
На компьютере нормально грузится? TTL , какой ставили? Пробуйте увеличивать.
Да, пока все хорошо. Вообще по поводу падения процесса - на гите автора, как раз обсуждали эту проблему, что и привело к этому фиксу сегодняшнему. Один пользователь там заявляет, что на более 30 кинетиках тестирует, видно на поток поставил. Ну говорит, что проблема решена.
У меня сейчас недавно после обновления на версию 69.6 наглухо завис роутер, пришлось аварийно перезагрузить его. Может совпадения, но он у меня так никогда не зависал. Пока все работает, но нужно повнимательней с новой версией, а то может заместо аварийного падения процесса появилось аварийное падение всего роутера.
Просто, вставлять нужно через редактор vi или nano, иначе если через винду, то можно на вставлять не видимые спец. символы из-за которых потом скрипт и вываливается. Ну или по крайней мере контролировать после вставки - открывать в редакторе vi и смотреть, чтоб все было точно, как и должно, не одной лишней закорючки.
Да у Вас в скрипте ошибка. Возьмите файл скрипта, который выкладывал Drorby https://drive.google.com/file/d/1s0R2h-eU7Y5j_qQUrUVMCpWIR_N8SkUg/view?usp=drivesdk и просто замените свой по пути
/opt/etc/ndm/netfilter.d/. У него он верный.А автозагрузка идет через создания ссылки:
ln -fs /opt/zapret/init.d/sysv/zapret /opt/etc/init.d/S90-zapretУ вас если посмотреть через
mcесть файл-ссылкаS90-zapretв папке/opt/etc/init.d?Версию zapret v69.6 поставил, все пока работает нормально. В инструкции тоже обновил если что.
Только должно быть все наоборот! С большим TTL он доходит до серверов, а с маленьким нет. Странно как-то все работает. В использовании метода задания TTL есть только один минус - его возможно придется по себя подстраивать, необходимо найти минимальное значение, при котором обход еще работает, а TTL=0 - это неравно минимальный, а равно оригинальный, а он всегда большой будет, иначе ничего бы не работало.
Это понятно, но я прилагал, что просто замените в конфиге везде
--dpi-desync-ttl=0на--dpi-desync-ttl=2, и тогда у Вас с очень большой вероятностью все будет работать в режиме none. Я писал почему так, с--dpi-desync-ttl=0у фейковых пакетов TTL оригинального пакета остается, а при--dpi-desync-ttl=2TTL меняется меняется на 2, т.е. уничтожится после прохождения 2 узлов и до сервера точно не дойдет, а при оригинальном он доходит, но отбрасывается из-за установки --dpi-desync-fooling, но также некоторые серверы могут не отбрасывать и тогда соединение ломается. По этому изменение TTL более надежный способ, чтобы фейки не дошли, но главное, чтобы они миновали ограничители.Нет, а просто если none выбрать и проверить?
Они заявляли, что у них падает сам процесс nfqws, а не правила в таблице iptables. Предположительно, у @inkda1 из-за большого hostlist, потому, что прошивка и роутер у нас одинаковые, отличается только режим фильтрации, а проверять в режиме none - он не хочет.
В том то и дело, что скрипты делают просто фактически одно и тоже! Отличия заключается только в том, что мой скрипт вызывает функцию
zapret_apply_firewallчерез/opt/zapret/init.d/sysv/zapret restart-fw, а в том хуке через/zapret/init.d/sysv/functions. И почему у Вас происходит ошибка не понятно, притом что вначале он работает нормально, она получается через какое-то время вылезает в модулеndm. А еще интересней, что мой старый скрипт не вызывает эту ошибку, хотя отличия в них только в том, что стал помимо таблицыmangleпроверять изменения таблицыnat, что собственно делает и тот хук, один в один -[ "$table" != "mangle" ] && [ "$table" != "nat" ] && exit 0. Просто если не проверять это, как раз возможно появление проблемы с отвалом UDP протокола, так как для кинетика нужно делать маскарад на внешний интерфейс и следить, чтобы ОС его не затерла.Да, ошибка в ndm вылезает, до неё не было ничего ещё? Какой роутер и версия прошивки?
Это нужно к разработчикам keeneticOS скидывать на форум, чтобы они смотрели, может исправят. Если не затруднит Вас, то скиньте туда. Просто только у Вас такая ошибка вылезает. И к zapret она не относится и процесс так же судя по всему не падает, а просто правила в таблице не восстанавливаются.
Ещё можете скинуть куда-нибудь сам файл скрипта, который вызывает эту ошибку, и скинуть мне.
Поставьте режим фильтрации none. Этот скрипт не выполняется zapret, а вызывается автоматически, когда таблица iptables обновляется роутером. Переодичность будет зависить конфигурации роутера. Какое содержимое скрипта 000-zapret.sh сейчас?
Странно, два одинаковых устройства, на одном работает, а другом нет. Какой конфиг используется? Когда настраивали? Я тут сейчас только обновил его немного.
Вот они сейчас одновременно выполняются, делая одно и тоже. Как сможете просто обновите 000-zapret.sh и переместите netfilter.hook.sh куда-нибудь. После этого посмотрим, что будет в журнале и будет ли отваливаться.