mirror of
https://github.com/bol-van/zapret.git
synced 2025-02-21 20:42:22 +03:00
readme: fix typos
This commit is contained in:
antixrist
parent
f62b289cb5
commit
789d013aae
142
docs/readme.md
142
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](#множественные-стратегии).
|
||||
* 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.
|
||||
```
|
||||
@<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 часа (метод кувалды).
|
||||
|
||||
@ -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_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 лучше все-же обходить на роутере.
|
||||
@ -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)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user