readme: fix typos

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, собираемый из тех же исходников (см. [док
 ```
 @<config_file>|$<config_file>                      ; читать конфигурацию из файла. опция должна быть первой. остальные опции игнорируются.
 
---debug=0|1                                        ; 1=выводить отладочные сообщения
+--debug=0|1|syslog|@<filename>                     ; выводить отладочные сообщения в: 1=консоль, syslog или @<filename>=файл
 --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](#множественные-стратегии).
+* 0 фаза - предполагает работу на этапе установления соединения: `synack`, `syndata`, `--wsize`, `--wssize`. На эту фазу не действуют фильтры по [hostlist](#множественные-стратегии).
-* 1 фаза - отсылка чего-либо до оригинального пакета данных : `fake`, `rst`, `rstack`.
+* 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 и QUIC ClientHello. Они бывают длинными, если в chrome включить пост-квантовую
-криптографию tls-kyber, и занимают как правило 2 или 3 пакета. kyber включен по умолчанию, начиная с chromium 124.
+криптографию 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, то нужно создать файл
+В традиционных системах посмотрите - используется ли `iptables-legacy` или `iptables-nft`. Если legacy, то нужно создать файл
-`/etc/modprobe.d/ip6table_raw.conf` с содержимым :
+`/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.
 ```
 @<config_file>|$<config_file>                     ; читать конфигурацию из файла. опция должна быть первой. остальные опции игнорируются.
 
---debug=0|1|2|syslog|@<filename>                  ; 0,1,2 = логирование на косоль : 0=тихо, 1(default)=подробно, 2=отладка.
+--debug=0|1|2|syslog|@<filename>                  ; 0,1,2 = логирование на консоль: 0=тихо, 1(default)=подробно, 2=отладка.
 --debug-level=0|1|2                               ; указать уровень логирования для syslog и @<filename>
 --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 часа (метод кувалды).
 
@@ -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_NOAUTO>` на реальные параметры `--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 лучше все-же обходить на роутере.
@@ -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)