diff --git a/docs/readme.txt b/docs/readme.txt index 0d1c40a..a36194a 100644 --- a/docs/readme.txt +++ b/docs/readme.txt @@ -1,123 +1,10 @@ -zapret v.61 + адресах. Слушать на всех - не есть +с точки -English -------- - -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. +Фильтр по owner необходим для исключения рекурсивного перенаправления соединений от сам. tpws запускается под пользователем "tpws", для него задается исключающее правило. -tpws может использоваться в режиме socks proxy. В этом случае iptables не нужны, а нужно прописать socks +tpws может использоваться в режиме socks proxy. В этом случае iptables не нужны, а нужно прописа socks в настройки программы (например, броузера), с которой будем обходить блокировки. transparent proxy отличается от socks именно тем, что в варианте transparent настраивать клиентские программы не нужно.