mirror of
https://github.com/bol-van/zapret.git
synced 2024-11-26 12:10:53 +03:00
docs: Quote additional content in linux quickstart
This commit is contained in:
maximilionus
parent
7ee5306d06
commit
e1d417578d
@ -74,161 +74,164 @@
|
||||
проблемы, обход будет работать только для тех программ или ОС, которые сами
|
||||
реализуют механизмы SecureDNS. Для других программ обход работать не будет.
|
||||
|
||||
Решение проблемы DNS выходит за рамки проекта. Обычно она решается либо
|
||||
заменой DNS серверов от провайдера на публичные (`1.1.1.1`, `8.8.8.8`), либо
|
||||
в случае перехвата провайдером обращений к сторонним серверам - через
|
||||
специальные средства шифрования DNS запросов, такие как `dnscrypt`, `DoT`,
|
||||
`DoH`.
|
||||
> Решение проблемы DNS выходит за рамки проекта. Обычно она решается либо
|
||||
> заменой DNS серверов от провайдера на публичные (`1.1.1.1`, `8.8.8.8`),
|
||||
> либо в случае перехвата провайдером обращений к сторонним серверам - через
|
||||
> специальные средства шифрования DNS запросов, такие как `dnscrypt`, `DoT`,
|
||||
> `DoH`.
|
||||
>
|
||||
> Еще один эффективный вариант - использовать ресолвер от yandex
|
||||
> (`77.88.8.88`) на нестандартном порту `1253`. Многие провайдеры не
|
||||
> анализируют обращения к DNS на нестандартных портах.
|
||||
>
|
||||
> Проверить работает ли этот вариант можно так:
|
||||
> ```sh
|
||||
> $ dig -p 53 @77.88.8.88 rutracker.org dig -p 1253 @77.88.8.88 rutracker.org
|
||||
> ```
|
||||
>
|
||||
> Если DNS действительно подменяется, и ответ на эти 2 команды разный,
|
||||
> значит метод вероятно работает.
|
||||
>
|
||||
> В openwrt DNS на нестандартном порту можно прописать в `/etc/config/dhcp`
|
||||
> таким способом :
|
||||
>
|
||||
> ```
|
||||
> config dnsmasq
|
||||
> <...>
|
||||
> list server '77.88.8.88#1253'
|
||||
> ```
|
||||
>
|
||||
> Если настройки IP и DNS получаются автоматически от провайдера, в
|
||||
> `/etc/config/network` найдите секцию интерфейса `wan` и сделайте так:
|
||||
>
|
||||
> ```
|
||||
> config interface 'wan'
|
||||
> <...>
|
||||
> option peerdns '0'
|
||||
> ```
|
||||
>
|
||||
> ```sh
|
||||
> $ /etc/init.d/network restart
|
||||
> $ /etc/init.d/dnsmasq restart
|
||||
> ```
|
||||
>
|
||||
> Если это не подходит, можно перенаправлять обращения на UDP и TCP порты
|
||||
> `53` вашего DNS сервера на `77.88.8.88:1253` средствами
|
||||
> `iptables`/`nftables`. В `/etc/resolv.conf` нельзя прописать DNS на
|
||||
> нестандартном порту.
|
||||
|
||||
Еще один эффективный вариант - использовать ресолвер от yandex
|
||||
(`77.88.8.88`) на нестандартном порту `1253`. Многие провайдеры не
|
||||
анализируют обращения к DNS на нестандартных портах.
|
||||
|
||||
Проверить работает ли этот вариант можно так:
|
||||
```sh
|
||||
$ dig -p 53 @77.88.8.88 rutracker.org dig -p 1253 @77.88.8.88 rutracker.org
|
||||
```
|
||||
|
||||
Если DNS действительно подменяется, и ответ на эти 2 команды разный, значит
|
||||
метод вероятно работает.
|
||||
|
||||
В openwrt DNS на нестандартном порту можно прописать в `/etc/config/dhcp`
|
||||
таким способом :
|
||||
|
||||
```
|
||||
config dnsmasq
|
||||
<...>
|
||||
list server '77.88.8.88#1253'
|
||||
```
|
||||
|
||||
Если настройки IP и DNS получаются автоматически от провайдера, в
|
||||
`/etc/config/network` найдите секцию интерфейса `wan` и сделайте так:
|
||||
|
||||
```
|
||||
config interface 'wan'
|
||||
<...>
|
||||
option peerdns '0'
|
||||
```
|
||||
|
||||
```sh
|
||||
$ /etc/init.d/network restart
|
||||
$ /etc/init.d/dnsmasq restart
|
||||
```
|
||||
|
||||
Если это не подходит, можно перенаправлять обращения на UDP и TCP порты `53`
|
||||
вашего DNS сервера на `77.88.8.88:1253` средствами `iptables`/`nftables`. В
|
||||
`/etc/resolv.conf` нельзя прописать DNS на нестандартном порту.
|
||||
|
||||
6. `blockcheck.sh` позволяет выявить рабочую стратегию обхода блокировок По
|
||||
6. `blockcheck.sh` позволяет выявить рабочую стратегию обхода блокировок. По
|
||||
результатам скрипта нужно понять какой вариант будете использовать : `nfqws`
|
||||
или `tpws` И запомнить найденные стратегии.
|
||||
или `tpws` и запомнить найденные стратегии для дальнейшего применения.
|
||||
|
||||
Следует понимать, что скрипт проверяет доступность только конкретного
|
||||
домена, который вы вводите в начале. Вероятно, все остальные домены
|
||||
блокированы подобным образом, **но не факт**. В большинстве случаев можно
|
||||
объединить несколько стратегий в одну универсальную, и это крайне
|
||||
желательно. Необходимо понимать как работают стратегии. zapret не может
|
||||
пробить блокировку по IP адресу. Для проверки нескольких доменов вводите их
|
||||
через пробел.
|
||||
объединить несколько стратегий в одну универсальную, и это **крайне
|
||||
желательно**. Необходимо понимать как работают стратегии. zapret **не может
|
||||
пробить блокировку по IP адресу**. Для проверки нескольких доменов вводите
|
||||
их через пробел.
|
||||
|
||||
Сейчас блокираторы ставят на магистральных каналах. В сложных случаях у вас
|
||||
может быть несколько маршрутов с различной длиной по ХОПам, с DPI на разных
|
||||
хопах. Приходится преодолевать целый зоопарк DPI, которые еще и включаются в
|
||||
работу хаотичным образом или образом, зависящим от направления (IP сервера).
|
||||
скрипт не всегда может выдать вам в итогах оптимальную стратегию, которую
|
||||
надо просто переписать в настройки. В некоторых случаях надо реально думать
|
||||
что происходит, анализируя результат на разных стратегиях. Если вы
|
||||
применяете большой **TTL**, чтобы достать до магистрала, то не лишним будет
|
||||
добавить дополнительный ограничитель `--dpi-desync-fooling`, чтобы не
|
||||
сломать сайты на более коротких дистанциях. `md5sig` наиболее совместим, но
|
||||
работает **только** на linux серверах. `badseq` может работать только на
|
||||
**https** и не работать на **http**. Чтобы выяснить какие дополнительные
|
||||
ограничители работают, смотрите результат теста аналогичных стратегий без
|
||||
**TTL** с каждым из этих ограничителей.
|
||||
|
||||
При использовании `autottl` следует протестировать как можно больше разных
|
||||
доменов. Эта техника может на одних провайдерах работать стабильно, на
|
||||
других потребуется выяснить при каких параметрах она стабильна, на третьих
|
||||
полный хаос, и проще отказаться.
|
||||
|
||||
Далее, имея понимание что работает на **http**, **https**, **quic**, нужно
|
||||
сконструировать параметры запуска `tpws` и/или `nfqws` с использованием
|
||||
мультистратегии. Как работают мультистратегии описано в readme.txt.
|
||||
|
||||
Если кратко, то обычно параметры конструируются так:
|
||||
```sh
|
||||
"--filter-udp=443 'параметры для quic' <HOSTLIST_NOAUTO> --new
|
||||
--filter-tcp=80,443 'обьединенные параметры для http и https' <HOSTLIST>"
|
||||
```
|
||||
|
||||
Или так:
|
||||
```sh
|
||||
"--filter-udp=443 'параметры для quic' <HOSTLIST_NOAUTO> --new
|
||||
--filter-tcp=80 'параметры для http' <HOSTLIST> --new
|
||||
--filter-tcp=443 'параметры для https' <HOSTLIST>"
|
||||
```
|
||||
|
||||
`<HOSTLIST>` и `<HOSTLIST_NOAUTO>` так и пишутся. Их не надо на что-то
|
||||
заменять. Это сделают скрипты запуска, если вы выбрали режим фильтрации по
|
||||
хостлистам, и уберут в противном случае. Если для какого-то протокола надо
|
||||
дурить все без стандартного хостлиста - просто уберите оттуда `<HOSTLIST>` и
|
||||
`<HOSTLIST_NOAUTO>`. Можно писать свои параметры `--hostlist` и
|
||||
`--hostlist-exclude` для дополнительных хостлистов или в профилях
|
||||
специализаций под конкретный ресурс. В последнем случае стандартный хостлист
|
||||
там не нужен. Следует избегать указания собственных параметров `--hostlist`
|
||||
на листы из директории ipset. Эта логика включена в `<HOSTLIST>` и
|
||||
`<HOSTLIST_NOAUTO>`. Отличие `<HOSTLIST_NOAUTO>` в том, что стандартный
|
||||
автолист по этому профилю используется как обычный, то есть без
|
||||
автоматического добавления доменов. Однако, добавления в других профилях
|
||||
автоматически отражаются во всех остальных.
|
||||
|
||||
Если стратегии отличаются по версии ip протокола, и вы не можете их
|
||||
обьединить, фильтр пишется так:
|
||||
```sh
|
||||
"--filter-l3=ipv4 --filter-udp=443 lпараметры для quic ipv4' <HOSTLIST_NOAUTO> --new
|
||||
--filter-l3=ipv4 --filter-tcp=80 'параметры для http ipv4' <HOSTLIST> --new
|
||||
--filter-l3=ipv4 --filter-tcp=443 'параметры для https ipv4' <HOSTLIST> --new
|
||||
--filter-l3=ipv6 --filter-udp=443 "параметры для quic ipv6" <HOSTLIST_NOAUTO> --new
|
||||
--filter-l3=ipv6 --filter-tcp=80 'параметры для http ipv6' <HOSTLIST> --new
|
||||
--filter-l3=ipv6 --filter-tcp=443 'параметры для https ipv6' <HOSTLIST>"
|
||||
```
|
||||
|
||||
Но здесь совсем "копи-пастный" вариант. Чем больше вы объедините стратегий и
|
||||
сократите их общее количество, тем будет лучше.
|
||||
|
||||
Если вам не нужно дурение отдельных протоколов, лучше всего будет их убрать
|
||||
из системы перехвата трафика через параметры `TPWS_PORTS`,
|
||||
`NFQWS_PORTS_TCP`, `NFQWS_PORTS_UDP` и убрать соответствующие им профили
|
||||
мультистратегии.
|
||||
|
||||
| Протокол | Порт | Примечание |
|
||||
|---|---|---|
|
||||
| `tcp` | `80` | `http` соединение |
|
||||
| `tcp` | `443` | `https` соединение |
|
||||
| `udp` | `443` | `quic` соединение |
|
||||
|
||||
Если используются методы нулевой фазы десинхронизации (`--mss`, `--wssize`,
|
||||
`--dpi-desync=syndata`) и режим фильтрации `hostlist`, то все параметры,
|
||||
относящиеся к этим методам, следует помещать в отдельные профили
|
||||
мульистратегии, которые получат управление до определения имени хоста.
|
||||
Необходимо понимать алгоритм работы мультистратегий. Самым надежным
|
||||
вариантом будет дублирование этих параметров на 2 профиля. Какой-нибудь
|
||||
сработает в зависимости от параметра `MODE_FILTER`.
|
||||
|
||||
```sh
|
||||
"--filter-tcp=80 'параметры для http' <HOSTLIST> --new
|
||||
--filter-tcp=443 'параметры для https' --wssize 1:6 <HOSTLIST> --new
|
||||
--filter-tcp=443 --wssize 1:6"
|
||||
```
|
||||
|
||||
В этом примере `wssize` будет применяться всегда к порту **tcp** `443` вне
|
||||
зависимости от параметра `MODE_FILTER`. Хостлист будет игнорироваться, если
|
||||
таковой имеется. К **http** применять **wssize** вредно и бессмысленно.
|
||||
|
||||
Никто не мешает использовать `tpws` для **http**, `nfqws` для **https**,
|
||||
либо комбинировать действие `nfqws` и `tpws` для одного протокола. В текущем
|
||||
варианте скриптов запуска это делается максимально гибко и независимо друг
|
||||
от друга.
|
||||
> Сейчас блокираторы ставят на магистральных каналах. В сложных случаях у
|
||||
> вас может быть несколько маршрутов с различной длиной по ХОПам, с DPI на
|
||||
> разных хопах. Приходится преодолевать целый зоопарк DPI, которые еще и
|
||||
> включаются в работу хаотичным образом или образом, зависящим от
|
||||
> направления (IP сервера). скрипт не всегда может выдать вам в итогах
|
||||
> оптимальную стратегию, которую надо просто переписать в настройки. В
|
||||
> некоторых случаях надо реально думать что происходит, анализируя результат
|
||||
> на разных стратегиях. Если вы применяете большой **TTL**, чтобы достать до
|
||||
> магистрала, то не лишним будет добавить дополнительный ограничитель
|
||||
> `--dpi-desync-fooling`, чтобы не сломать сайты на более коротких
|
||||
> дистанциях. `md5sig` наиболее совместим, но работает **только** на linux
|
||||
> серверах. `badseq` может работать только на **https** и не работать на
|
||||
> **http**. Чтобы выяснить какие дополнительные ограничители работают,
|
||||
> смотрите результат теста аналогичных стратегий без **TTL** с каждым из
|
||||
> этих ограничителей.
|
||||
>
|
||||
> При использовании `autottl` следует протестировать как можно больше разных
|
||||
> доменов. Эта техника может на одних провайдерах работать стабильно, на
|
||||
> других потребуется выяснить при каких параметрах она стабильна, на третьих
|
||||
> полный хаос, и проще отказаться.
|
||||
>
|
||||
> Далее, имея понимание что работает на **http**, **https**, **quic**, нужно
|
||||
> сконструировать параметры запуска `tpws` и/или `nfqws` с использованием
|
||||
> мультистратегии. Как работают мультистратегии описано в readme.txt.
|
||||
>
|
||||
> Если кратко, то обычно параметры конструируются так:
|
||||
> ```sh
|
||||
> "--filter-udp=443 'параметры для quic' <HOSTLIST_NOAUTO> --new
|
||||
> --filter-tcp=80,443 'обьединенные параметры для http и https' <HOSTLIST>"
|
||||
> ```
|
||||
>
|
||||
> Или так:
|
||||
> ```sh
|
||||
> "--filter-udp=443 'параметры для quic' <HOSTLIST_NOAUTO> --new
|
||||
> --filter-tcp=80 'параметры для http' <HOSTLIST> --new
|
||||
> --filter-tcp=443 'параметры для https' <HOSTLIST>"
|
||||
> ```
|
||||
>
|
||||
> `<HOSTLIST>` и `<HOSTLIST_NOAUTO>` так и пишутся. Их не надо на что-то
|
||||
> заменять. Это сделают скрипты запуска, если вы выбрали режим фильтрации по
|
||||
> хостлистам, и уберут в противном случае. Если для какого-то протокола надо
|
||||
> дурить все без стандартного хостлиста - просто уберите оттуда `<HOSTLIST>`
|
||||
> и `<HOSTLIST_NOAUTO>`. Можно писать свои параметры `--hostlist` и
|
||||
> `--hostlist-exclude` для дополнительных хостлистов или в профилях
|
||||
> специализаций под конкретный ресурс. В последнем случае стандартный
|
||||
> хостлист там не нужен. Следует избегать указания собственных параметров
|
||||
> `--hostlist` на листы из директории ipset. Эта логика включена в
|
||||
> `<HOSTLIST>` и `<HOSTLIST_NOAUTO>`. Отличие `<HOSTLIST_NOAUTO>` в том, что
|
||||
> стандартный автолист по этому профилю используется как обычный, то есть
|
||||
> без автоматического добавления доменов. Однако, добавления в других
|
||||
> профилях автоматически отражаются во всех остальных.
|
||||
>
|
||||
> Если стратегии отличаются по версии ip протокола, и вы не можете их
|
||||
> обьединить, фильтр пишется так:
|
||||
> ```sh
|
||||
> "--filter-l3=ipv4 --filter-udp=443 lпараметры для quic ipv4' <HOSTLIST_NOAUTO> --new
|
||||
> --filter-l3=ipv4 --filter-tcp=80 'параметры для http ipv4' <HOSTLIST> --new
|
||||
> --filter-l3=ipv4 --filter-tcp=443 'параметры для https ipv4' <HOSTLIST> --new
|
||||
> --filter-l3=ipv6 --filter-udp=443 "параметры для quic ipv6" <HOSTLIST_NOAUTO> --new
|
||||
> --filter-l3=ipv6 --filter-tcp=80 'параметры для http ipv6' <HOSTLIST> --new
|
||||
> --filter-l3=ipv6 --filter-tcp=443 'параметры для https ipv6' <HOSTLIST>"
|
||||
> ```
|
||||
>
|
||||
> Но здесь совсем "копи-пастный" вариант. Чем больше вы объедините стратегий и
|
||||
> сократите их общее количество, тем будет лучше.
|
||||
>
|
||||
> Если вам не нужно дурение отдельных протоколов, лучше всего будет их
|
||||
> убрать из системы перехвата трафика через параметры `TPWS_PORTS`,
|
||||
> `NFQWS_PORTS_TCP`, `NFQWS_PORTS_UDP` и убрать соответствующие им профили
|
||||
> мультистратегии.
|
||||
>
|
||||
> | Протокол | Порт | Примечание |
|
||||
> |---|---|---|
|
||||
> | `tcp` | `80` | `http` соединение |
|
||||
> | `tcp` | `443` | `https` соединение |
|
||||
> | `udp` | `443` | `quic` соединение |
|
||||
>
|
||||
> Если используются методы нулевой фазы десинхронизации (`--mss`,
|
||||
> `--wssize`, `--dpi-desync=syndata`) и режим фильтрации `hostlist`, то все
|
||||
> параметры, относящиеся к этим методам, следует помещать в отдельные
|
||||
> профили мульистратегии, которые получат управление до определения имени
|
||||
> хоста. Необходимо понимать алгоритм работы мультистратегий. Самым надежным
|
||||
> вариантом будет дублирование этих параметров на 2 профиля. Какой-нибудь
|
||||
> сработает в зависимости от параметра `MODE_FILTER`.
|
||||
>
|
||||
> ```sh
|
||||
> "--filter-tcp=80 'параметры для http' <HOSTLIST> --new
|
||||
> --filter-tcp=443 'параметры для https' --wssize 1:6 <HOSTLIST> --new
|
||||
> --filter-tcp=443 --wssize 1:6"
|
||||
> ```
|
||||
>
|
||||
> В этом примере `wssize` будет применяться всегда к порту **tcp** `443` вне
|
||||
> зависимости от параметра `MODE_FILTER`. Хостлист будет игнорироваться,
|
||||
> если таковой имеется. К **http** применять **wssize** вредно и
|
||||
> бессмысленно.
|
||||
>
|
||||
> Никто не мешает использовать `tpws` для **http**, `nfqws` для **https**,
|
||||
> либо комбинировать действие `nfqws` и `tpws` для одного протокола. В
|
||||
> текущем варианте скриптов запуска это делается максимально гибко и
|
||||
> независимо друг от друга.
|
||||
|
||||
7. Запустите скрипт облегченной установки - `install_easy.sh` Выберите `nfqws`
|
||||
и/или `tpws`, затем согласитесь на редактирование параметров. Откроется
|
||||
|
||||
Loading…
Reference in New Issue
Block a user