From 789d013aaef8149c23200aa0993cf73f263c86ff Mon Sep 17 00:00:00 2001 From: antixrist Date: Wed, 19 Feb 2025 16:39:53 +0400 Subject: [PATCH] readme: fix typos --- docs/readme.md | 142 ++++++++++++++++++++++++------------------------- 1 file changed, 71 insertions(+), 71 deletions(-) diff --git a/docs/readme.md b/docs/readme.md index 61f0f52..6f7d0f8 100644 --- a/docs/readme.md +++ b/docs/readme.md @@ -93,7 +93,7 @@ VPN. опционально дополняя его пакетом HTTP redirect. Если фейк пакет инжектится только для клиента, в этом случае можно обойтись командами iptables для дропа RST и/или редиректа на заглушку по определённым условиям, которые нужно подбирать для каждого провайдера индивидуально. Так мы обходим последствия срабатывания триггера запрета. Если пассивный DPI -направляет пакет RST в том числе и серверу, то вы ничего с этим не сможете сделать. Ваша задача — не допустить +направляет пакет RST, в том числе и серверу, то вы ничего с этим не сможете сделать. Ваша задача — не допустить срабатывания триггера запрета. Одними iptables уже не обойтись. Этот проект нацелен именно на предотвращение срабатывания запрета, а не ликвидацию его последствий. @@ -128,7 +128,7 @@ DPI. Все больше становится внереестровых бло ## Как это реализовать на практике в системе linux -Если кратко, то варианты можно классифицировать по следующей схеме : +Если кратко, то варианты можно классифицировать по следующей схеме: 1) Пассивный DPI, не отправляющий RST серверу. Помогут индивидуально настраиваемые под провайдера команды iptables. На rutracker в разделе "обход блокировок - другие способы" по этому вопросу существует отдельная тема. В данном проекте @@ -146,7 +146,7 @@ DPI. Все больше становится внереестровых бло * Если блокировка осуществляется по IP. * Если соединение проходит через фильтр, способный реконструировать TCP соединение, и который следует всем стандартам. Например, нас заворачивают на squid. Соединение идет через полноценный стек tcpip операционной системы. - Проект нацелен на обман DPI, который всилу ограниченности ресурсов и большого трафика вынужден интерпретировать его лишь ограниченно. + Проект нацелен на обман DPI, который, в силу ограниченности ресурсов и большого трафика, вынужден интерпретировать его лишь ограниченно. Обмануть полноценный стек ОС и полноценные серверные приложения не получится. ## nfqws @@ -157,7 +157,7 @@ dvtws, собираемый из тех же исходников (см. [док ``` @|$ ; читать конфигурацию из файла. опция должна быть первой. остальные опции игнорируются. ---debug=0|1 ; 1=выводить отладочные сообщения +--debug=0|1|syslog|@ ; выводить отладочные сообщения в: 1=консоль, syslog или @=файл --dry-run ; проверить опции командной строки и выйти. код 0 - успешная проверка. --version ; вывести версию и выйти --comment ; любой текст (игнорируется) @@ -262,14 +262,14 @@ dvtws, собираемый из тех же исходников (см. [док * `md5sig` добавляет TCP опцию **MD5 signature**. Работает не на всех серверах. Пакеты с md5 обычно отбрасывают только linux. * `badsum` портит контрольную сумму TCP. Не сработает, если ваше устройство за NAT, который не пропускает пакеты с инвалидной суммой. Наиболее распространенная настройка NAT роутера в Linux их не пропускает. На Linux построено большинство домашних роутеров. - Непропускание обеспечивается так : настройка ядра sysctl по умолчанию + Непропускание обеспечивается так: настройка ядра sysctl по умолчанию `net.netfilter.nf_conntrack_checksum=1` заставляет conntrack проверять tcp и udp чексуммы входящих пакетов и выставлять state INVALID для пакетов с инвалидной суммой. Обычно в правилах iptables вставляется правило для дропа пакетов с состоянием INVALID в цепочке FORWARD. Совместное сочетание этих факторов приводит к непрохождению badsum через такой роутер. В OpenWrt из коробки `net.netfilter.nf_conntrack_checksum=0`, в других роутерах часто нет, и не всегда это можно изменить. Чтобы nfqws мог работать через роутер, нужно на нем выставить указанное значение sysctl в 0. nfqws на самом роутере будет работать и без этой настройки, потому что чексумма локально созданных пакетов не - проверяется никогда. Если роутер за другим NAT, например провайдерским, и он не пропускает invalid packets вы ничего + проверяется никогда. Если роутер за другим NAT, например провайдерским, и он не пропускает invalid packets, вы ничего не сможете с этим сделать. Но обычно провайдеры все же пропускают badsum. На некоторых адаптерах/свитчах/драйверах принудительно включен rx-checksum offload, badsum пакеты отсекаются еще до получения в ОС. В этом случае если что-то и можно сделать, то только модифицировать драйвер, что представляется задачей крайне нетривиальной. Установлено, что так @@ -280,7 +280,7 @@ dvtws, собираемый из тех же исходников (см. [док Такие пакеты будут наверняка отброшены принимающим узлом, но так же и DPI, если он ориентируется на sequence numbers. По умолчанию смещение seq выбирается -10000. Практика показала, что некоторые DPI не пропускают seq вне определенного окна. Однако, такое небольшое смещение может вызвать проблемы при существенной потоковой передаче и - потере пакетов. Если вы используете `--dpi-desync-any-protocol`, может понадобится установить badseq increment + потере пакетов. Если вы используете `--dpi-desync-any-protocol`, может понадобиться установить badseq increment 0x80000000. Это обеспечит надежную гарантию, что поддельный пакет не вклинится в tcp window на сервере. Так же было замечено, что badseq ломает логику некоторых DPI при анализе http, вызывая зависание соединения. Причем на тех же DPI TLS с badseq работает нормально. @@ -295,7 +295,7 @@ dvtws, собираемый из тех же исходников (см. [док * `hopbyhop` относится только к ipv6. Добавляется ipv6 extenstion header `hop-by-hop options`. В варианте `hopbyhop2` добавляются 2 хедера, что является нарушением стандарта и гарантированно отбрасывается стеком протоколов во всех ОС. Один хедер hop-by-hop принимается всеми ОС, однако на некоторых каналах/провайдерах такие пакеты могут фильтроваться и - не доходить. Расчет идет на то, что DPI проанализирует пакет с hop-by-hop, но он либо не дойдет до адресата всилу + не доходить. Расчет идет на то, что DPI проанализирует пакет с hop-by-hop, но он либо не дойдет до адресата в силу фильтров провайдера, либо будет отброшен сервером, потому что хедера два. * `datanoack` высылает фейки со снятым tcp флагом ACK. Сервера такое не принимают, а DPI может принять. Эта техника может ломать NAT и не всегда работает с iptables, если используется masquerade, даже с локальной системы (почти всегда @@ -338,7 +338,7 @@ dvtws, собираемый из тех же исходников (см. [док * `multisplit`. нарезаем запрос на указанных в `--dpi-desync-split-pos` позициях. * `multidisorder`. нарезаем запрос на указанных в `--dpi-desync-split-pos` позициях и отправляем в обратном порядке. - * `fakedsplit`. нарезаем запрос на 2 части, обрамляя каждую часть фейками : фейк 1-й части, 1 часть, фейк 1-й части, фейк 2-й части, 2 часть, фейк 2-й части + * `fakedsplit`. нарезаем запрос на 2 части, обрамляя каждую часть фейками: фейк 1-й части, 1 часть, фейк 1-й части, фейк 2-й части, 2 часть, фейк 2-й части * `fakeddisorder`. аналогично `fakedsplit`, только в обратном порядке : фейк 2-й части, 2 часть, фейк 2-й части, фейк 1-й части, 1 часть, фейк 1 части. Содержимое фейков в `fakedsplit`/`fakeddisorder` определяется параметром `--dpi-desync-fakedsplit-pattern` (по умолчанию 0x00). @@ -352,7 +352,7 @@ dvtws, собираемый из тех же исходников (см. [док * **Абсолютный отрицательный маркер** - числовое смещение внутри пакета или группы пакетов от следующего за концом байта. -1 указывает на последний байт. * **Относительный маркер** - положительное или отрицательное смещение относительно логической позиции внутри пакета или группы пакетов. -Относительные позиции : +Относительные позиции: * **method** - начало метода HTTP ('GET', 'POST', 'HEAD', ...). Метод обычно всегда находится на позиции 0, но может сместиться из-за `--methodeol`. Тогда позиция может стать 1 или 2. * **host** - начало имени хоста в известном протоколе (http, TLS) @@ -362,7 +362,7 @@ dvtws, собираемый из тех же исходников (см. [док * **midsld** - середина домена 2 уровня в имени хоста * **sniext** - начало поля данных SNI extension в TLS. Любой extension состоит из 2-байтовых полей type и length, за ними идет поле данных. -Пример списка маркеров : `100,midsld,sniext+1,endhost-2,-10`. +Пример списка маркеров: `100,midsld,sniext+1,endhost-2,-10`. При разбиении пакета первым делом происходит ресолвинг маркеров - нахождение всех указанных относительных позиций и применение смещений. Если относительная позиция отсутствует в текущем протоколе, такие позиции не применяются и отбрасываются. @@ -422,15 +422,15 @@ extension хедерам в поисках транспортного хедер без анализа. Возможно, какие-то DPI на это купятся. Может сочетаться с любыми режимами 2-й фазы, кроме варианта `ipfrag1+ipfrag2`. Например, `hopbyhop,multisplit` означает разбить tcp пакет на несколько сегментов, в каждый из них добавить hop-by-hop. -При `hopbyhop,ipfrag2` последовательность хедеров будет : `ipv6,hop-by-hop`,`fragment`,`tcp/udp`. +При `hopbyhop,ipfrag2` последовательность хедеров будет: `ipv6,hop-by-hop`,`fragment`,`tcp/udp`. Режим `ipfrag1` может срабатывать не всегда без специальной подготовки. См. раздел `IP фрагментация`. ### КОМБИНИРОВАНИЕ МЕТОДОВ ДЕСИНХРОНИЗАЦИИ В параметре dpi-desync можно указать до 3 режимов через запятую. -* 0 фаза - предполагает работу на этапе установления соединения : `synack`, `syndata`, `--wsize`, `--wssize`. На эту фазу не действуют фильтры по [hostlist](#множественные-стратегии). -* 1 фаза - отсылка чего-либо до оригинального пакета данных : `fake`, `rst`, `rstack`. +* 0 фаза - предполагает работу на этапе установления соединения: `synack`, `syndata`, `--wsize`, `--wssize`. На эту фазу не действуют фильтры по [hostlist](#множественные-стратегии). +* 1 фаза - отсылка чего-либо до оригинального пакета данных: `fake`, `rst`, `rstack`. * 2 фаза - отсылка в модифицированном виде оригинального пакета данных (например, `fakedsplit` или `ipfrag2`). Режимы требуют указания в порядке возрастания номеров фаз. @@ -476,7 +476,7 @@ DPI может отстать от потока, если ClientHello его у nfqws оснащен ограниченной реализацией слежения за состоянием tcp соединений (conntrack). Он включается для реализации некоторых методов противодействия DPI. -conntrack способен следить за фазой соединения : SYN,ESTABLISHED,FIN, количеством пакетов в каждую сторону, +conntrack способен следить за фазой соединения: SYN,ESTABLISHED,FIN, количеством пакетов в каждую сторону, sequence numbers. conntrack способен "кормиться" пакетами в обе или только в одну сторону. Соединение попадает в таблицу при обнаружении пакетов с выставленными флагами SYN или SYN,ACK. Поэтому если необходим conntrack, в правилах перенаправления iptables соединение должно идти на nfqws с самого первого @@ -530,8 +530,8 @@ window size итоговый размер окна стал максимальн ### РЕАССЕМБЛИНГ nfqws поддерживает реассемблинг некоторых видов запросов. -На текущий момент это TLS и QUIC ClientHello. Они бывает длинными, если в chrome включить пост-квантовую -криптографию tls-kyber, и занимают как правило 2 или 3 пакета. kyber включен по умолчанию, начиная с chromium 124. +На текущий момент это TLS и QUIC ClientHello. Они бывают длинными, если в chrome включить пост-квантовую +криптографию tls-kyber, и занимают, как правило, 2 или 3 пакета. kyber включен по умолчанию, начиная с chromium 124. chrome рандомизирует фингерпринт TLS. SNI может оказаться как в начале, так и в конце, то есть попасть в любой пакет. stateful DPI обычно реассемблирует запрос целиком, и только потом принимает решение о блокировке. @@ -578,9 +578,9 @@ chrome рандомизирует фингерпринт TLS. SNI может о Существует ряд моментов вокруг работы с фрагментами на Linux, без понимания которых может ничего не получиться. -ipv4 : Linux дает отсылать ipv4 фрагменты, но стандартные настройки iptables в цепочке OUTPUT могут вызывать ошибки отправки. +ipv4: Linux дает отсылать ipv4 фрагменты, но стандартные настройки iptables в цепочке OUTPUT могут вызывать ошибки отправки. -ipv6 : Нет способа для приложения гарантированно отослать фрагменты без дефрагментации в conntrack. +ipv6: Нет способа для приложения гарантированно отослать фрагменты без дефрагментации в conntrack. На разных системах получается по-разному. Где-то нормально уходят, где-то пакеты дефрагментируются. Для ядер <4.16 похоже, что нет иного способа решить эту проблему, кроме как выгрузить модуль `nf_conntrack`, который подтягивает зависимость `nf_defrag_ipv6`. Он то как раз и выполняет дефрагментацию. @@ -589,12 +589,12 @@ ipv6 : Нет способа для приложения гарантирова Иногда требуется подгружать модуль `ip6table_raw` с параметром `raw_before_defrag=1`. В OpenWrt параметры модулей указываются через пробел после их названий в файлах `/etc/modules.d`. -В традиционных системах посмотрите используется ли `iptables-legacy` или `iptables-nft`. Если legacy, то нужно создать файл -`/etc/modprobe.d/ip6table_raw.conf` с содержимым : +В традиционных системах посмотрите - используется ли `iptables-legacy` или `iptables-nft`. Если legacy, то нужно создать файл +`/etc/modprobe.d/ip6table_raw.conf` с содержимым: ``` options ip6table_raw raw_before_defrag=1 ``` -В некоторых традиционных дистрибутивах можно изменить текущий ip6tables через : update-alternatives --config ip6tables +В некоторых традиционных дистрибутивах можно изменить текущий ip6tables через: update-alternatives --config ip6tables Если вы хотите оставаться на iptables-nft, вам придется пересобрать патченную версию. Патч совсем небольшой. В `nft.c` найдите фрагмент: ``` @@ -620,7 +620,7 @@ options ip6table_raw raw_before_defrag=1 При использовании iptables и NAT, похоже, что нет способа прицепить обработчик очереди после NAT. Пакет попадает в nfqws с source адресом внутренней сети, затем фрагментируется и уже не обрабатывается NAT. -Так и уходит во внешюю сеть с src ip 192.168.x.x. Следовательно, метод не срабатывает. +Так и уходит во внешнюю сеть с src ip 192.168.x.x. Следовательно, метод не срабатывает. Видимо единственный рабочий метод - отказаться от iptables и использовать nftables. Хук должен быть с приоритетом 101 или выше. @@ -644,26 +644,26 @@ L7 протокол становится известен обычно посл Если имя хоста удовлетворяет листам, выбирается этот профиль. Иначе идет переход к следующему. Может так случиться, что до получения имени хоста или узнавания L7 протокола соединение идет по одному профилю, а при выяснении этих параметров профиль меняется на лету. Это может произойти даже дважды - при выяснении L7 -и имени хоста. Чаще всего это выяснение совмещается в одно действие, поскольку по одному пакету как правило узнается и L7, и хост. +и имени хоста. Чаще всего это выяснение совмещается в одно действие, поскольку по одному пакету, как правило, узнается и L7, и хост. Поэтому если у вас есть параметры дурения нулевой фазы, тщательно продумывайте что может произойти при переключении стратегии. Смотрите debug log, чтобы лучше понять что делает nfqws. Нумерация профилей идет с 1 до N. Последним в цепочке создается пустой профиль с номером 0. Он используется, когда никакие условия фильтров не совпали. > [!IMPORTANT] -> Множественные стратегии создавались только для случаев, когда невозможно обьединить +> Множественные стратегии создавались только для случаев, когда невозможно объединить > имеющиеся стратегии для разных ресурсов. Копирование стратегий из blockcheck для разных сайтов -> во множество профилей без понимания как они работают приведет к нагромождению параметров, которые все равно +> во множество профилей без понимания как они работают приведёт к нагромождению параметров, которые все равно > не покроют все возможные заблокированные ресурсы. Вы только увязните в этой каше. > [!IMPORTANT] > user-mode реализация ipset создавалась не как удобная замена *nix версии, реализованной в ядре. -> Вариант в ядре работает гораздо эффективнее. Это создавалось для систем без подержки ipset в ядре. +> Вариант в ядре работает гораздо эффективнее. Это создавалось для систем без поддержки ipset в ядре. > Конкретно - Windows и ядра Linux, собранные без nftables и ipset модулей ядра. Например, в android нет ipset. ### IPTABLES ДЛЯ NFQWS -iptables для задействования атаки на первые пакеты данных в tcp соединении : +iptables для задействования атаки на первые пакеты данных в tcp соединении: ``` iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp -m multiport --dports 80,443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:6 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass @@ -678,7 +678,7 @@ iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp ``` mark нужен, чтобы сгенерированный поддельный пакет не попал опять к нам на обработку. nfqws выставляет fwmark при его отсылке. -хотя nfqws способен самостоятельно различать помеченные пакеты, фильтр в iptables по mark нужен при использовании connbytes, +Хотя nfqws способен самостоятельно различать помеченные пакеты, фильтр в iptables по mark нужен при использовании connbytes, чтобы не допустить изменения порядка следования пакетов. Процессинг очереди - процесс отложенный. Если ядро имеет пакеты на отсылку вне очереди - оно их отправляет незамедлительно. Изменение правильного порядка следования пакетов при десинхронизации ломает всю идею. @@ -691,7 +691,7 @@ mark нужен, чтобы сгенерированный поддельный * 3 - стандартная ситуация приема одного пакета запроса * 4-6 - на случай ретрансмиссии или запроса длиной в несколько пакетов (TLSClientHello с kyber, например) -Для режима autottl необходимо перенаправление входящего `SYN,ACK` пакета или первого пакета соединения (что обычно есть тоже самое). +Для режима autottl необходимо перенаправление входящего `SYN,ACK` пакета или первого пакета соединения (что обычно есть то же самое). Для режима autohostlist необходимы входящие RST и http redirect. Можно построить фильтр на tcp flags для выделения `SYN,ACK` и модуле u32 для поиска характерных паттернов http redirect, но проще использовать connbytes для выделения нескольких начальных входящих пакетов. @@ -745,7 +745,7 @@ nft add chain inet ztest predefrag "{type filter hook output priority -401;}" nft add rule inet ztest predefrag "mark & 0x40000000 != 0x00000000 notrack" ``` -Удаление тестовой таблицы : +Удаление тестовой таблицы: ``` nft delete table inet ztest @@ -784,7 +784,7 @@ tpws - это transparent proxy. ``` @|$ ; читать конфигурацию из файла. опция должна быть первой. остальные опции игнорируются. ---debug=0|1|2|syslog|@ ; 0,1,2 = логирование на косоль : 0=тихо, 1(default)=подробно, 2=отладка. +--debug=0|1|2|syslog|@ ; 0,1,2 = логирование на консоль: 0=тихо, 1(default)=подробно, 2=отладка. --debug-level=0|1|2 ; указать уровень логирования для syslog и @ --dry-run ; проверить опции командной строки и выйти. код 0 - успешная проверка. --version ; вывести версию и выйти @@ -892,7 +892,7 @@ tpws, как и nfqws, поддерживает множественную се Однако, если в момент send уже имеется неотосланный буфер, то ОС присоединит данные к нему, никакой отсылки отдельным пакетом не будет. Но в этом случае и так нет никакой гарантии, что какой-то блок сообщения пойдет в начале пакета, на что собственно и заточены DPI. -Разбиение будет производится согласно MSS, который зависит от MTU исходящего интерфейса. +Разбиение будет производиться согласно MSS, который зависит от MTU исходящего интерфейса. Таким образом DPI, смотрящие в начало поля данных TCP пакета, будут поломаны в любом случае. Протокол http относится к запрос-ответным протоколам. Новое сообщение посылается только тогда, когда сервер получил запрос и полностью вернул ответ. Значит запрос фактически был не только отослан, @@ -901,11 +901,11 @@ tpws, как и nfqws, поддерживает множественную се Таким образом tpws обеспечивает сплит только за счет раздельных вызовов send, и это обычно работает надежно, если разбивать не на слишком много частей и не на слишком мелкие подряд следующие части. -В последнем случае Linux все же может обьединить некоторые части, что приведет к несоответствию реальной сегментации -указанным сплит позициям. Другие ОС в этом вопросе ведут себя более предсказуемо. Спонтанного обьединения замечено не было. +В последнем случае Linux все же может объединить некоторые части, что приведет к несоответствию реальной сегментации +указанным сплит позициям. Другие ОС в этом вопросе ведут себя более предсказуемо. Спонтанного объединения замечено не было. Поэтому не стоит злоупотреблять сплитами и в особенности мелкими соседними пакетами. -Как показывается практика, проблемы могут начаться , если количество сплитов более одного. +Как показывается практика, проблемы могут начаться, если количество сплитов более одного. На каких-то системах наблюдался стабильный результат до 8 сплитов, на других проблемы уже начинались после 2 сплитов. Один сплит работает стабильно, если не является частью массивной потоковой передачи. При неудаче сегментации будет выводиться сообщение `WARNING ! segmentation failed`. @@ -913,7 +913,7 @@ tpws, как и nfqws, поддерживает множественную се Если это не вариант, для ядер Linux >=4.6 есть параметр `--fix-seg`. Он позволяет подождать завершение отсылки перед отправкой следующей части. Но этот вариант ломает модель асинхронной обработки событий. Пока идет ожидание, все остальные соединения не обрабатываются и кратковременно подвисают. На практике это может быть совсем небольшое ожидание - менее 10 мс. -Выполняется оно только , если происходит split, и в ожидании есть реальная необходимость. +Выполняется оно только, если происходит split, и в ожидании есть реальная необходимость. В высоконагруженных системах данный вариант не рекомендуется. Но для домашнего использования может подойти, и вы эти задержки даже не заметите. Если вы пытаетесь сплитнуть массивную передачу с `--split-any-protocol`, когда информация поступает быстрее отсылки, @@ -987,7 +987,7 @@ tpws работает на уровне сокетов, поэтому длин То есть работоспособность вашей настройки в одном и том же режиме может зависеть от того, применяет ли клиент удаленный ресолвинг. Это может быть неочевидно. В одной программе работает, в другой - нет. -Если вы используете профиль с хостлистом , и вам нужен mss, укажите mss в профиле с хостлистом, +Если вы используете профиль с хостлистом, и вам нужен mss, укажите mss в профиле с хостлистом, создайте еще один профиль без хостлиста, если его еще нет, и в нем еще раз укажите mss. Тогда при любом раскладе будет выполняться mss. Используйте `curl --socks5` и `curl --socks5-hostname` для проверки вашей стратегии. @@ -1049,7 +1049,7 @@ TCP_USER_TIMEOUT. Под таймаутом подразумевается вр Режим `--socks` не требует повышенных привилегий (кроме бинда на привилегированные порты 1..1023). Поддерживаются версии socks 4 и 5 без авторизации. Версия протокола распознается автоматически. Подключения к IP того же устройства, на котором работает tpws, включая localhost, запрещены. -socks5 позволяет удаленно ресолвить хосты (curl : --socks5-hostname firefox : socks_remote_dns=true). +socks5 позволяет удалённо ресолвить хосты (curl : --socks5-hostname firefox : socks_remote_dns=true). tpws поддерживает эту возможность асинхронно, не блокируя процессинг других соединений, используя многопоточный пул ресолверов. Количество потоков определяется автоматически в зависимости от `--maxconn`, но можно задать и вручную через параметр `--resolver-threads`. @@ -1060,7 +1060,7 @@ tpws поддерживает эту возможность асинхронно ### IPTABLES ДЛЯ TPWS -Для перенаправления tcp соединения на transparent proxy используются команды следующего вида : +Для перенаправления tcp соединения на transparent proxy используются команды следующего вида: ``` iptables -t nat -I OUTPUT -o <внешний_интерфейс> -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to 127.0.0.127:988 @@ -1080,7 +1080,7 @@ route_localnet : динамически вписывать в команду. В любом случае требуются дополнительные усилия. Использование route_localnet тоже имеет потенциальные проблемы с безопасностью. Вы делаете доступным все, что висит на `127.0.0.0/8` для локальной подсети < внутренний_интерфейс>. Службы обычно привязываются к `127.0.0.1`, поэтому можно средствами iptables запретить входящие -на `127.0.0.1` не с интерфейса lo, либо повесить tpws на любой другой IP из из `127.0.0.0/8`, например на `127.0.0.127`, +на `127.0.0.1` не с интерфейса lo, либо повесить tpws на любой другой IP из `127.0.0.0/8`, например на `127.0.0.127`, и разрешить входящие не с lo только на этот IP. ``` @@ -1092,7 +1092,7 @@ iptables -A INPUT ! -i lo -d 127.0.0.0/8 -j DROP пользователем **tpws**, для него задается исключающее правило. ip6tables работают почти точно так же, как и ipv4, но есть ряд важных нюансов. В DNAT следует брать адрес --to в -квадратные скобки. Например : +квадратные скобки. Например: `ip6tables -t nat -I OUTPUT -o <внешний_интерфейс> -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to [::1]:988` @@ -1102,7 +1102,7 @@ NFQUEUE работает без изменений. ### NFTABLES ДЛЯ TPWS -Базовая конфигурация : +Базовая конфигурация: ``` IFACE_WAN=wan @@ -1124,7 +1124,7 @@ nft create chain inet ztest dnat_pre "{type nat hook prerouting priority dstnat; nft add rule inet ztest dnat_pre meta iifname $IFACE_LAN tcp dport { 80, 443 } dnat ip to 127.0.0.127:988 ``` -Удаление таблицы : +Удаление таблицы: ``` nft delete table inet ztest ``` @@ -1211,7 +1211,7 @@ mdig --family=6 --dns-make-query=rutracker.org | curl --data-binary @- -H "Conte 1) Внесите заблокированные домены в `ipset/zapret-hosts-user.txt` и запустите `ipset/get_user.sh` На выходе получите `ipset/zapret-ip-user.txt` с IP адресами. -Cкрипты с названием get_reestr_* оперируют дампом реестра заблокированных сайтов : +Скрипты с названием get_reestr_* оперируют дампом реестра заблокированных сайтов: 2) `ipset/get_reestr_resolve.sh` получает список доменов от rublacklist и дальше их ресолвит в ip адреса в файл ipset/zapret-ip.txt.gz. В этом списке есть готовые IP адреса, но судя во всему они там в точности в том виде, @@ -1226,7 +1226,7 @@ Cкрипты с названием get_reestr_* оперируют дампом 4) `ipset/get_reestr_preresolved_smart.sh`. то же самое, что и 3), с добавлением всего диапазона некоторых автономных систем (прыгающие IP адреса из cloudflare, facebook, ...) и некоторых поддоменов блокируемых сайтов -Cкрипты с названием `get_antifilter_*` оперируют списками адресов и масок подсетей с сайтов antifilter.network и antifilter.download : +Скрипты с названием `get_antifilter_*` оперируют списками адресов и масок подсетей с сайтов antifilter.network и antifilter.download : 5) `ipset/get_antifilter_ip.sh`. получает лист https://antifilter.download/list/ip.lst. @@ -1243,7 +1243,7 @@ Cкрипты с названием `get_antifilter_*` оперируют спи Суммарный список префиксов, созданный из ipsum.lst и subnet.lst. 10) `ipset/get_refilter_ipsum.sh`. - Список берется отсюда : https://github.com/1andrevich/Re-filter-lists + Список берется отсюда: https://github.com/1andrevich/Re-filter-lists Все варианты рассмотренных скриптов автоматически создают и заполняют ipset. Варианты 2-10 дополнительно вызывают вариант 1. @@ -1252,7 +1252,7 @@ Cкрипты с названием `get_antifilter_*` оперируют спи Если переменная не определена, то ресолвятся лишь листы для ipset nozapret/nozapret6. Листы РКН все время изменяются. Возникают новые тенденции. Требования к RAM могут меняться. -Поэтому необходима нечастая, но все же регулярная ревизия что же вообще у вас происходит на роутере. +Поэтому необходима нечастая, но все же регулярная ревизия - что же вообще у вас происходит на роутере. Или вы можете узнать о проблеме лишь когда у вас начнет постоянно пропадать wifi, и вам придется его перезагружать каждые 2 часа (метод кувалды). @@ -1297,7 +1297,7 @@ ipfw таблицы в отличие от ipset могут содержать Параметр конфига LISTS_RELOAD задает произвольную команду для перезагрузки листов. Это особенно полезно на BSD системах с PF. -LISTS_RELOAD=- отключает перезагрузку листов. +LISTS_RELOAD=- отключает перезагрузку листов. ## Фильтрация по именам доменов @@ -1313,7 +1313,7 @@ LISTS_RELOAD=- отключает перезагрузку листов. Есть оба - дурение только include, кроме exclude. В системе запуска это обыграно следующим образом. -Присутствуют 2 include списка : +Присутствуют 2 include списка: `ipset/zapret-hosts-users.txt.gz` или `ipset/zapret-hosts-users.txt`, `ipset/zapret-hosts.txt.gz` или `ipset/zapret-hosts.txt` и 1 exclude список @@ -1322,7 +1322,7 @@ LISTS_RELOAD=- отключает перезагрузку листов. При режимах фильтрации `MODE_FILTER=hostlist` или `MODE_FILTER=autohostlist` система запуска передает **nfqws** или **tpws** все листы, файлы которых присутствуют. Передача происходит через замену маркеров `` и `` на реальные параметры `--hostlist`, `--hostlist-exclude`, `--hostlist-auto`. Если вдруг листы include присутствуют, но все они пустые, то работа аналогична отсутствию include листа. -Файл есть, но не смотря на это дурится все, кроме exclude. +Файл есть, но, несмотря на это, дурится все, кроме exclude. Если вам нужен именно такой режим - не обязательно удалять `zapret-hosts-users.txt`. Достаточно сделать его пустым. Поддомены учитываются автоматически. Например, строчка "ru" вносит в список "*.ru". Строчка "*.ru" в списке не сработает. @@ -1355,11 +1355,11 @@ tpws и nfqws решают нужно ли применять дурение в **tpws**/**nfqws** сами назначают владельцем файла юзера, под которым они работают после сброса привилегий, чтобы иметь возможность обновлять лист. -В случае **nfqws** данный режим требует перенаправления в том числе и входящего трафика. +В случае **nfqws** данный режим требует перенаправления, в том числе и входящего трафика. Крайне рекомендовано использовать ограничитель `connbytes`, чтобы **nfqws** не обрабатывал гигабайты. По этой же причине не рекомендуется использование режима на BSD системах. Там нет фильтра `connbytes`. -На linux системах при использовании nfqws и фильтра connbytes может понадобится : +На linux системах при использовании nfqws и фильтра connbytes может понадобиться: `sysctl net.netfilter.nf_conntrack_tcp_be_liberal=1` Было замечено, что некоторые DPI в России возвращают RST с неверным ACK. Это принимается tcp/ip стеком linux, но через раз приобретает статус INVALID в conntrack. Поэтому правила с `connbytes` срабатывают @@ -1374,9 +1374,9 @@ linux, но через раз приобретает статус INVALID в con свое клиенту. Применяется нечасто, поскольку броузеры на такое ругаются. **nfqws** и **tpws** могут сечь варианты 1-3, 4 они не распознают. -Всилу специфики работы с отдельными пакетами или с TCP каналом tpws и nfqws распознают эти ситуации +В силу специфики работы с отдельными пакетами или с TCP каналом tpws и nfqws распознают эти ситуации по-разному. -Что считается ситуацией, похожей на блокировку : +Что считается ситуацией, похожей на блокировку: 1) **nfqws** Несколько ретрансмиссий первого запроса в TCP сеансе, в котором имеется host. 2) **nfqws,tpws** RST, пришедший в ответ на первый запрос с хостом. 3) **nfqws,tpws** HTTP редирект, пришедший в ответ на первый запрос с хостом, на глобальный адрес @@ -1400,7 +1400,7 @@ linux, но через раз приобретает статус INVALID в con Если сайт не ведет себя как заблокированный, значит обход применен не будет. В противном случае терять все равно нечего. Однако, могут быть временные сбои сервера, приводящие к ситуации, аналогичной блокировке. -Могут происходит ложные срабатывания. Если такое произошло, стратегия может начать ломать +Могут происходить ложные срабатывания. Если такое произошло, стратегия может начать ломать незаблокированный сайт. Эту ситуацию, увы, придется вам контролировать вручную. Заносите такие домены в `ipset/zapret-hosts-user-exclude.txt`, чтобы избежать повторения. Чтобы впоследствии разобраться почему домен был занесен в лист, можно включить `autohostlist debug log`. @@ -1451,7 +1451,7 @@ linux, но через раз приобретает статус INVALID в con `Blockcheck` имеет 3 уровня сканирования. * `quick` - максимально быстро найти хоть что-то работающее. -* `standard` дает возможность провести исследование как и на что реагирует DPI в плане методов обхода. +* `standard` дает возможность провести исследование - как и на что реагирует DPI в плане методов обхода. * `force` дает максимум проверок даже в случаях, когда ресурс работает без обхода или с более простыми стратегиями. Есть ряд других параметров, которые не будут спрашиваться в диалоге, но которые можно переопределить через @@ -1617,7 +1617,7 @@ nfqws начнет получать адреса пакетов из локал Таким образом, все 3 режима вполне могут задействоваться вместе. Так же безусловно и независимо, в добавок к стандартным опциям, применяются все custom скрипты в `init.d/{sysv,openwrt,macos}/custom.d`. -Однако, при комбинировании tpws и nfqws с пересечением по L3/L4 протоколам не все так просто , как может показаться на первый взгляд. +Однако, при комбинировании tpws и nfqws с пересечением по L3/L4 протоколам не все так просто, как может показаться на первый взгляд. Первым всегда работает tpws, за ним - nfqws. На nfqws попадает уже "задуренный" трафик от tpws. Получается, что дурилка дурит дурилку, и дурилка не срабатывает, потому что ее задурили. Вот такой веселый момент. nfqws перестает распознавать протоколы и применять методы. @@ -1747,7 +1747,7 @@ DISABLE_IPV6=1 ``` Количество потоков для многопоточного DNS ресолвера mdig (1..100). -Чем их больше, тем быстрее, но не обидется ли на долбежку ваш DNS сервер?\ +Чем их больше, тем быстрее, но не обидится ли на долбежку ваш DNS сервер?\ `MDIG_THREADS=30` Место для хранения временных файлов. При скачивании огромных реестров в `/tmp` места может не хватить. @@ -1894,14 +1894,14 @@ INIT_FW_POST_DOWN_HOOK="/etc/firewall.zapret.hook.post_down" Эти настройки доступны в config. Может быть полезно, если вам нужно использовать nftables set-ы, например `ipban`/`ipban6`. -nfset-ы принадлежат только одной таблице, следовательно вам придется писать правила для таблицы zapret, +nfset-ы принадлежат только одной таблице, следовательно, вам придется писать правила для таблицы zapret, а значит нужно синхронизироваться с применением/снятием правил со стороны zapret скриптов. ## Вариант custom custom скрипты - это маленькие shell программы, управляющие нестандартными режимами применения zapret или частными случаями, которые не могут быть интегрированы в основную часть без загромождения и замусоривания кода. -Для применеия custom следует помещать файлы в следующие директории в зависимости от вашей системы: +Для применения custom следует помещать файлы в следующие директории в зависимости от вашей системы: ``` /opt/zapret/init.d/sysv/custom.d /opt/zapret/init.d/openwrt/custom.d @@ -1991,11 +1991,11 @@ zapret_custom_firewall_nft поднимает правила nftables. Под OpenWrt все уже сразу готово для использования системы в качестве роутера. Имена интерфейсов WAN и LAN известны из настроек системы. Под другими системами роутер вы настраиваете самостоятельно. Инсталлятор в это не вмешивается. -инсталлятор в зависимости от выбранного режима может спросить LAN и WAN интерфейсы. +Инсталлятор в зависимости от выбранного режима может спросить LAN и WAN интерфейсы. Нужно понимать, что заворот проходящего трафика на **tpws** в прозрачном режиме происходит до выполнения маршрутизации, -следовательно возможна фильтрация по LAN и невозможна по WAN. +следовательно, возможна фильтрация по LAN и невозможна по WAN. Решение о завороте на **tpws** локального исходящего трафика принимается после выполнения маршрутизации, -следовательно ситуация обратная: LAN не имеет смысла, фильтрация по WAN возможна. +следовательно, ситуация обратная: LAN не имеет смысла, фильтрация по WAN возможна. Заворот на **nfqws** происходит всегда после маршрутизации, поэтому к нему применима только фильтрация по WAN. Возможность прохождения трафика в том или ином направлении настраивается вами в процессе конфигурации роутера. @@ -2153,7 +2153,7 @@ Wifi сеть - обычно `wlan0`. Переключать blockcheck между оператором и wifi можно вместе со всем инетом - включив или выключив wifi. Если найдете стратегию для wifi и впишите ее в автостарт, то при подключении к другому wifi -она может не сработать или вовсе что-то поломать, потому подумайте стоит ли. +она может не сработать или вовсе что-то поломать, потому подумайте - стоит ли. Может быть лучше сделать скрипты типа "запустить обход домашнего wifi", "снять обход домашнего wifi", и пользоваться ими по необходимости из терминала. Но домашний wifi лучше все-же обходить на роутере. @@ -2172,7 +2172,7 @@ Wifi сеть - обычно `wlan0`. tpws работает обычным образом. -`nfqueue` поломан, можно собрать фиксящий модуль https://github.com/im-0/unfuck-nfqueue-on-e3372h, +`nfqueue` поломан, можно собрать фиксящий модуль https://github.com/im-0/unfuck-nfqueue-on-e3372h, используя исходники с huawei open source. Исходники содержат тулчейн и полусобирающееся, неактуальное ядро. Конфиг можно взять с рабочего модема из `/proc/config.gz`. С помощью этих исходников умельцы могут собрать модуль `unfuck_nfqueue.ko`. @@ -2202,7 +2202,7 @@ curl: (7) Failed to connect to www.ru port 80: Host is unreachable Поэтому без tcp проксирования в этой ситуации сайты тупят, но загружаются, а с проксированием подключение выполняется, но вскоре сбрасывается без каких-либо данных, и броузеры не пытаются установить его заново. Поэтому качество броузинга с tpws может быть хуже, но дело не в tpws. -Частота сбросов заметно возрастает, если запущен торент клиент, имеется много tcp соединений. +Частота сбросов заметно возрастает, если запущен торрент-клиент, имеется много tcp соединений. Однако, причина не в переполнении таблицы conntrack. Увеличение лимитов и очистка conntrack не помогают. Предположительно эта особенность связана с обработкой пакетов сброса соединения в hardware offload. Точного ответа на вопрос у меня нет. Если вы знаете - поделитесь, пожалуйста. @@ -2225,10 +2225,10 @@ curl: (7) Failed to connect to www.ru port 80: Host is unreachable ## Другие прошивки -Для статических бинариков не имеет значения на чем они запущены: PC, android, приставка, роутер, любой другой девайс. +Для статических бинарников не имеет значения на чем они запущены: PC, android, приставка, роутер, любой другой девайс. Подойдет любая прошивка, дистрибутив linux. Статические бинарники запустятся на всем. Им нужно только ядро с необходимыми опциями сборки или модулями. -Но кроме бинариков в проекте используются еще и скрипты, в которых задействуются некоторые +Но кроме бинарников в проекте используются еще и скрипты, в которых задействуются некоторые стандартные программы. Основные причины почему нельзя просто так взять и установить эту систему на что угодно: @@ -2266,14 +2266,14 @@ entware содержит репозиторий user-mode компонент, к _Подробное описание настроек для других прошивок выходит за рамки данного проекта._ OpenWrt является одной из немногих относительно полноценных linux систем для embedded devices. -Она характеризуется следующими вещами, которые и послужили основой выбора именно этой прошивк: +Она характеризуется следующими вещами, которые и послужили основой выбора именно этой прошивки: * полный root доступ к девайсу через shell. на заводских прошивках чаще всего отсутствует, на многих альтернативных есть * корень r/w. это практически уникальная особенность OpenWrt. заводские и большинство альтернативных прошивок построены на базе squashfs root (r/o), а конфигурация хранится в специально отформатированной области встроенной памяти, называемой nvram. не имеющие r/w корня системы сильно кастрированы. они не имеют возможности доустановки ПО из репозитория без специальных вывертов и заточены в основном на чуть более продвинутого, чем обычно, пользователя и управление имеющимся функционалом через веб интерфейс, - но функционал фиксированно ограничен. альтернативные прошивки как правило могут монтировать r/w раздел + но функционал фиксированно ограничен. альтернативные прошивки, как правило, могут монтировать r/w раздел в какую-то область файловой системы, заводские обычно могут монтировать лишь флэшки, подключенные к USB, и не факт, что есть поддержка unix файловых системы. может быть поддержка только fat и ntfs. * возможность выноса корневой файловой системы на внешний носитель (extroot) или создания на нем оверлея (overlay)