DHT (distributed sloppy hash table) - это протокол торрент сети, обмен пирами. Если провайдер начнет блокировать, то произойдет тоже самое, что при блокировке заголовкаtls_clienthello_www_google_com.bin, и с включённым запретом просто перестанут открываться все сайты, в том числе и обычно работающие.
Вчера стратегия модификации fake в старом виде перестала работать, стали блокировать заголовок tls_clienthello_www_google_com.bin, при этом при использовании режима фильтрации none - это привело, к блокировки всех сайтов, в том числе тех которые всегда работают, так как соединение блокируется при обнаружении заголовка tls_clienthello_www_google_com.bin.
В качестве решения, обновил статью с новым рабочим конфигом, и обновлением на версию 70.6. С этим конфигом все работает везде, как и прежде.
Рекомендуется обновится, тем у кого возникла проблема.
Да, в инструкции --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 более надежный способ, чтобы фейки не дошли, но главное, чтобы они миновали ограничители.
Если из стратегии
--dpi-desync (--filter-tcp=443)убратьfake, сайты начинают грузится?Это на режиме фильтрации none?
Да, только стратегия.
Все сайты не грузятся или блокированные?
--dpi-desync-ttlпопробуйте увеличить.Внимание!
Обновил статью с новым своим рабочим конфигом и актуализировал инструкцию для версии 71.1.1. С этим конфигом все работает везде.
Рекомендуется обновится, тем у кого есть проблема с работой.
DHT (distributed sloppy hash table) - это протокол торрент сети, обмен пирами. Если провайдер начнет блокировать, то произойдет тоже самое, что при блокировке заголовка
tls_clienthello_www_google_com.bin, и с включённым запретом просто перестанут открываться все сайты, в том числе и обычно работающие.Внимание!
Вчера стратегия модификации fake в старом виде перестала работать, стали блокировать заголовок
tls_clienthello_www_google_com.bin, при этом при использовании режима фильтрации none - это привело, к блокировки всех сайтов, в том числе тех которые всегда работают, так как соединение блокируется при обнаружении заголовкаtls_clienthello_www_google_com.bin.В качестве решения, обновил статью с новым рабочим конфигом, и обновлением на версию 70.6. С этим конфигом все работает везде, как и прежде.
Рекомендуется обновится, тем у кого возникла проблема.
Да, в инструкции
--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 более надежный способ, чтобы фейки не дошли, но главное, чтобы они миновали ограничители.