drygdryg/zapret
1
0
Fork 0
mirror of https://github.com/bol-van/zapret.git synced 2025-04-30 10:53:02 +03:00
Code Issues Packages Projects Releases Wiki Activity

Upda.txt

Browse Source
This commit is contained in:
gloriamonk 2024-08-26 15:34:56 +02:00 committed by GitHub
parent e69fdac9ab
commit 5c6516ef14
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 4 additions and 117 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

121
docs/readme.txt
View File

@ -1,123 +1,10 @@
zapret v.61 адресах. Слушать на всех - не есть
с точки
English Фильтр по owner необходим для исключения рекурсивного перенаправления соединений от сам.
-------
For english version refer to docs/readme.eng.txt
Для чего это надо
-----------------
Автономное, без задействования сторонних серверов, средство противодействия DPI.
Может помочь обойти блокировки или замедление сайтов http(s), сигнатурный анализ tcp и udp протоколов,
например с целью блокировки VPN.
Проект нацелен прежде всего на маломощные embedded устройства - роутеры, работающие под openwrt.
Поддерживаются традиционные Linux системы, FreeBSD, OpenBSD, частично MacOS.
В некоторых случаях возможна самостоятельная прикрутка решения к различным прошивкам.
Большая часть функционала работает на windows.
Как побыстрее начать
--------------------
Читайте docs/quick_start.txt для linux и openwrt, docs/quick_start_windows.txt для windows.
Как это работает
----------------
В самом простейшем случае вы имеете дело с пассивным DPI. Пассивный DPI может читать трафик
из потока, может инжектить свои пакеты, но не может блокировать проходящие пакеты.
Если запрос "плохой", пассивный DPI инжектит пакет RST, опционально дополняя его пакетом http redirect.
Если фейк пакет инжектится только для клиента, в этом случае можно обойтись командами iptables
для дропа RST и/или редиректа на заглушку по определенным условиям, которые нужно подбирать
для каждого провайдера индивидуально. Так мы обходим последствия срабатывания триггера запрета.
Если пассивный DPI направляет пакет RST в том числе и серверу, то вы ничего с этим не сможете сделать.
Ваша задача - не допустить срабатывания триггера запрета. Одними iptables уже не обойдетесь.
Этот проект нацелен именно на предотвращение срабатывания запрета, а не ликвидацию его последствий.
Активный DPI ставится в разрез провода и может дропать пакеты по любым критериям,
в том числе распознавать TCP потоки и блокировать любые пакеты, принадлежащие потоку.
Как не допустить срабатывания триггера запрета ? Послать то, на что DPI не расчитывает
и что ломает ему алгоритм распознавания запросов и их блокировки.
Некоторые DPI не могут распознать http запрос, если он разделен на TCP сегменты.
Например, запрос вида "GET / HTTP/1.1\r\nHost: kinozal.tv......"
мы посылаем 2 частями : сначала идет "GET ", затем "/ HTTP/1.1\r\nHost: kinozal.tv.....".
Другие DPI спотыкаются, когда заголовок "Host:" пишется в другом регистре : например, "host:".
Кое-где работает добавление дополнительного пробела после метода : "GET /" => "GET /"
или добавление точки в конце имени хоста : "Host: kinozal.tv."
Существует и более продвинутая магия, направленная на преодоление DPI на пакетном уровне.
Подробнее про DPI :
https://habr.com/ru/post/335436
https://geneva.cs.umd.edu/papers/geneva_ccs19.pdf
Что сейчас происходит в России
------------------------------
Раньше, до внедрения повсеместных систем ТСПУ, использовался зоопарк различных DPI
у провайдеров. Какие-то были активными, какие-то пассивными.
Сейчас время простых iptables окончательно ушло. Везде активный DPI ТСПУ, но кое-где
могут оставаться невыключенными дополнительные старые DPI из зоопарка.
В этом случае приходится обходить сразу несколько DPI.
Все больше становится внереестровых блокировок, о которых вы узнаете только по факту
недоступности чего-либо, в списках этого нет.
Применяются блокировки некоторых диапазонов ip адресов (автономный обход невозможен)
и протоколов (VPN).
На некоторых диапазонах IP используется более строгий фильтр, распознающий попытки
обмана через сегментацию. Должно быть это связано с некоторыми сервисами, которые
пытаются таким образом обмануть DPI.
Как это реализовать на практике в системе linux
-----------------------------------------------
Если кратко, то варианты можно классифицировать по следующей схеме :
1) Пассивный DPI, не отправляющий RST серверу. Помогут индивидуально настраиваемые под провайдера команды iptables.
На rutracker в разделе "обход блокировок - другие способы" по этому вопросу существует отдельная тема.
В данном проекте не рассматривается. Если вы не допустите срабатывание триггера запрета, то и не придется
бороться с его последствиями.
2) Модификация TCP соединения на уровне потока. Реализуется через proxy или transparent proxy.
3) Модификация TCP соединения на уровне пакетов. Реализуется через обработчик очереди NFQUEUE и raw сокеты.
Для вариантов 2 и 3 реализованы программы tpws и nfqws соответственно.
Чтобы они работали, необходимо их запустить с нужными параметрами и перенаправить на них определенный трафик
средствами iptables или nftables.
Для перенаправления tcp соединения на transparent proxy используются команды следующего вида :
проходящий трафик :
iptables -t nat -I PREROUTING -i <внутренний_интерфейс> -p tcp --dport 80 -j DNAT --to 127.0.0.127:988
исходящий трафик :
iptables -t nat -I OUTPUT -o <внешний_интерфейс> -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to 127.0.0.127:988
DNAT на localhost работает в цепочке OUTPUT, но не работает в цепочке PREROUTING без включения параметра route_localnet :
sysctl -w net.ipv4.conf.<внутренний_интерфейс>.route_localnet=1
Можно использовать "-j REDIRECT --to-port 988" вместо DNAT, однако в этом случае процесс transparent proxy
должен слушать на ip адресе входящего интерфейса или на всех адресах. Слушать на всех - не есть хорошо
с точки зрения безопасности. Слушать на одном (локальном) можно, но в случае автоматизированного
скрипта придется его узнавать, потом динамически вписывать в команду. В любом случае требуются дополнительные усилия.
Использование 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, и разрешить входящие не с lo только на этот IP.
iptables -A INPUT ! -i lo -d 127.0.0.127 -j ACCEPT
iptables -A INPUT ! -i lo -d 127.0.0.0/8 -j DROP
Фильтр по owner необходим для исключения рекурсивного перенаправления соединений от самого tpws.
tpws запускается под пользователем "tpws", для него задается исключающее правило. tpws запускается под пользователем "tpws", для него задается исключающее правило.
tpws может использоваться в режиме socks proxy. В этом случае iptables не нужны, а нужно прописать socks tpws может использоваться в режиме socks proxy. В этом случае iptables не нужны, а нужно прописа socks
в настройки программы (например, броузера), с которой будем обходить блокировки. в настройки программы (например, броузера), с которой будем обходить блокировки.
transparent proxy отличается от socks именно тем, что в варианте transparent настраивать клиентские программы не нужно. transparent proxy отличается от socks именно тем, что в варианте transparent настраивать клиентские программы не нужно.