|
|
|
@ -74,161 +74,164 @@ |
|
|
|
проблемы, обход будет работать только для тех программ или ОС, которые сами |
|
|
|
реализуют механизмы SecureDNS. Для других программ обход работать не будет. |
|
|
|
|
|
|
|
Решение проблемы 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 на нестандартном порту. |
|
|
|
|
|
|
|
6. `blockcheck.sh` позволяет выявить рабочую стратегию обхода блокировок По |
|
|
|
> Решение проблемы 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 на |
|
|
|
> нестандартном порту. |
|
|
|
|
|
|
|
6. `blockcheck.sh` позволяет выявить рабочую стратегию обхода блокировок. По |
|
|
|
результатам скрипта нужно понять какой вариант будете использовать : `nfqws` |
|
|
|
или `tpws` И запомнить найденные стратегии. |
|
|
|
или `tpws` и запомнить найденные стратегии для дальнейшего применения. |
|
|
|
|
|
|
|
Следует понимать, что скрипт проверяет доступность только конкретного |
|
|
|
домена, который вы вводите в начале. Вероятно, все остальные домены |
|
|
|
блокированы подобным образом, **но не факт**. В большинстве случаев можно |
|
|
|
объединить несколько стратегий в одну универсальную, и это крайне |
|
|
|
желательно. Необходимо понимать как работают стратегии. 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` для одного протокола. В текущем |
|
|
|
варианте скриптов запуска это делается максимально гибко и независимо друг |
|
|
|
от друга. |
|
|
|
объединить несколько стратегий в одну универсальную, и это **крайне |
|
|
|
желательно**. Необходимо понимать как работают стратегии. 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` для одного протокола. В |
|
|
|
> текущем варианте скриптов запуска это делается максимально гибко и |
|
|
|
> независимо друг от друга. |
|
|
|
|
|
|
|
7. Запустите скрипт облегченной установки - `install_easy.sh` Выберите `nfqws` |
|
|
|
и/или `tpws`, затем согласитесь на редактирование параметров. Откроется |
|
|
|
|
maximilionus
5 months ago