mirror of
https://github.com/bol-van/zapret.git
synced 2025-04-17 04:22:59 +03:00
readme: rewrite intro part
This commit is contained in:
bol-van
parent
bfb6042671
commit
626b1444dc
@ -1,7 +1,8 @@
|
||||
What is it for
|
||||
--------------
|
||||
|
||||
Bypass the blocking of web sites http.
|
||||
Bypass the blocking of http/https web sites on DPI without the use of third-party servers.
|
||||
|
||||
The project is mainly aimed at the Russian audience to fight russian regulator named "Roskomnadzor".
|
||||
Some features of the project are russian reality specific (such as getting list of sites
|
||||
blocked by Roskomnadzor), but most others are common.
|
||||
@ -9,10 +10,18 @@ blocked by Roskomnadzor), but most others are common.
|
||||
How it works
|
||||
------------
|
||||
|
||||
DPI providers have gaps. They happen because DPI rules are writtten for
|
||||
ordinary user programs, omitting all possible cases that are permissible by standards.
|
||||
This is done for simplicity and speed. It makes no sense to catch 0.01% hackers,
|
||||
because these blockings are quite simple and easily bypassed even by ordinary users.
|
||||
In the simplest case you are dealing with passive DPI. Passive DPI can read passthrough traffic,
|
||||
inject its own packets, but cannot drop packets.
|
||||
If the request is prohibited the passive DPI will inject its own RST packet and optionally http redirect packet.
|
||||
If fake packets from DPI are only sent to client, you can use iptables commands to drop them if you can write
|
||||
correct filter rules. This requires manual in-deep traffic analysis and tuning for specific ISP.
|
||||
This is how we bypass the consequences of a ban trigger.
|
||||
|
||||
If the passive DPI sends an RST packet also to the server, there is nothing you can do about it.
|
||||
Your task is to prevent ban trigger from firing up. Iptables alone will not work.
|
||||
This project is aimed at preventing the ban rather than eliminating its consequences.
|
||||
|
||||
To do that send what DPI does not expect and what breaks its algorithm of recognizing requests and blocking them.
|
||||
|
||||
Some DPIs cannot recognize the http request if it is divided into TCP segments.
|
||||
For example, a request of the form "GET / HTTP / 1.1 \ r \ nHost: kinozal.tv ......"
|
||||
@ -21,79 +30,59 @@ Other DPIs stumble when the "Host:" header is written in another case: for examp
|
||||
Sometimes work adding extra space after the method: "GET /" => "GET /"
|
||||
or adding a dot at the end of the host name: "Host: kinozal.tv."
|
||||
|
||||
There is also more advanced magic for bypassing DPI at the packet level.
|
||||
|
||||
|
||||
How to put this into practice in the linux system
|
||||
-------------------------------------------------
|
||||
|
||||
How to make the system break the request into parts? You can pipe the entire TCP session
|
||||
through transparent proxy, or you can replace the tcp window size field on the first incoming TCP packet with a SYN, ACK.
|
||||
Then the client will think that the server has set a small window size for it and the first data segment
|
||||
will send no more than the specified length. In subsequent packages, we will not change anything.
|
||||
The further behavior of the system depends on the implemented algorithm in the OS.
|
||||
Experience shows that linux always sends first packet no more than the specified
|
||||
in window size length, the rest of the packets until some time sends no more than max (36, specified_size).
|
||||
After a number of packets, the window scaling mechanism is triggered and starts taking
|
||||
the scaling factor into account. The packet size becomes no more than max (36, specified_ramer << scale_factor).
|
||||
The behavior is not very elegant, but since we do not affect the size of the incoming packets,
|
||||
and the amount of data received in http is usually much higher than the amount sent, then visually
|
||||
there will be only small delays.
|
||||
Windows behaves in a similar case much more predictably. First segment
|
||||
the specified length goes away, then the window size changes depending on the value,
|
||||
sent in new tcp packets. That is, the speed is almost immediately restored to the possible maximum.
|
||||
In short, the options can be classified according to the following scheme:
|
||||
|
||||
Its easy to intercept a packet with SYN, ACK using iptables.
|
||||
However, the options for editing packets in iptables are severely limited.
|
||||
It’s not possible to change window size with standard modules.
|
||||
For this, we will use the NFQUEUE. This tool allows transfer packets to the processes running in user mode.
|
||||
The process, accepting a packet, can change it, which is what we need.
|
||||
1) Passive DPI not sending RST to the server. ISP tuned iptables commands can help.
|
||||
This option is out of the scope of the project. If you do not allow ban trigger to fire, then you won’t have to
|
||||
deal with its consequences.
|
||||
2) Modification of the TCP connection at the stream level. Implemented through a proxy or transparent proxy.
|
||||
3) Modification of TCP connection at the packet level. Implemented through the NFQUEUE queue handler and raw sockets.
|
||||
|
||||
iptables -t mangle -I PREROUTING -p tcp --sport 80 --tcp-flags SYN,ACK SYN,ACK -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
For options 2 and 3, tpws and nfqws programs are implemented, respectively.
|
||||
You need to run them with the necessary parameters and redirect certain traffic with iptables.
|
||||
|
||||
It will queue the packets we need to the process that listens on the queue with the number 200.
|
||||
Process will replace the window size. PREROUTING will catch packets addressed to the host itself and routed packets.
|
||||
That is, the solution works the same way as on the client, so on the router. On a PC-based or OpenWRT router.
|
||||
In principle, this is enough.
|
||||
However, with such an impact on TCP there will be a slight delay.
|
||||
In order not to touch the hosts that are not blocked by the provider, you can make such a move.
|
||||
Create a list of blocked domains, resolve them to IP addresses and save to ipset named "zapret".
|
||||
Add to rule:
|
||||
To redirect a TCP connection to a transparent proxy, the following commands are used:
|
||||
|
||||
iptables -t mangle -I PREROUTING -p tcp --sport 80 --tcp-flags SYN,ACK SYN,ACK -m set --match-set zapret src -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
forwarded fraffic :
|
||||
iptables -t nat -I PREROUTING -i <internal_interface> -p tcp --dport 80 -j DNAT --to 127.0.0.1:1188
|
||||
outgoing traffic :
|
||||
iptables -t nat -I OUTPUT -o <external_interface> -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to 127.0.0.1:1188
|
||||
|
||||
Thus, the impact will be made only on ip addresses related to blocked sites.
|
||||
The list can be updated in scheduled task every few days.
|
||||
DNAT on localhost works in the OUTPUT chain, but does not work in the PREROUTING chain without enabling the route_localnet parameter:
|
||||
|
||||
If DPI cant be bypassed with splitting a request into segments, then sometimes helps changing case
|
||||
of the "Host:" http header. We may not need a window size replacement, so the do not need PREROUTING chain.
|
||||
Instead, we hang on outgoing packets in the POSTROUTING chain:
|
||||
sysctl -w net.ipv4.conf.<internal_interface>.route_localnet=1
|
||||
|
||||
iptables -t mangle -I POSTROUTING -p tcp --dport 80 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
|
||||
In this case, additional points are also possible. DPI can catch only the first http request, ignoring
|
||||
subsequent requests in the keep-alive session. Then we can reduce the cpu load abandoning the processing of unnecessary packages.
|
||||
|
||||
iptables -t mangle -I POSTROUTING -p tcp --dport 80 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:5 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
|
||||
It happens that the provider monitors the entire HTTP session with keep-alive requests. In this case
|
||||
it is not enough to restrict the TCP window when establishing a connection. Each http request must be splitted
|
||||
to multiple TCP segments. This task is solved through the full proxying of traffic using
|
||||
transparent proxy (TPROXY or DNAT). TPROXY does not work with connections originating from the local system
|
||||
so this solution is applicable only on the router. DNAT works with local connections,
|
||||
but there is a danger of entering into endless recursion, so the daemon is launched as a separate user,
|
||||
and for this user, DNAT is disabled via "-m owner". Full proxying requires more resources than outbound packet
|
||||
manipulation without reconstructing a TCP connection.
|
||||
|
||||
iptables -t nat -I PREROUTING -p tcp --dport 80 -j DNAT --to 127.0.0.1:1188
|
||||
iptables -t nat -I OUTPUT -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to 127.0.0.1:1188
|
||||
|
||||
NOTE: DNAT on localhost works in the OUTPUT chain, but does not work in the PREROUTING chain without enabling the route_localnet parameter:
|
||||
|
||||
sysctl -w net.ipv4.conf.<incoming_interface_name>.route_localnet=1
|
||||
|
||||
You can use "-j REDIRECT --to-port 1188" instead of DNAT, but in this case the transpareny proxy process
|
||||
You can use "-j REDIRECT --to-port 1188" instead of DNAT, but in this case the transparent proxy process
|
||||
should listen on the ip address of the incoming interface or on all addresses. Listen all - not good
|
||||
in terms of security. Listening one (local) is possible, but in the case of automated
|
||||
script will have to recognize it, then dynamically enter it into the command. In any case, additional efforts are required.
|
||||
in terms of security. Listening one (local) is possible, but automated scripts will have to recognize it,
|
||||
then dynamically enter it into the command. In any case, additional efforts are required.
|
||||
|
||||
Owner filter is necessary to prevent recursive redirection of connections from tpws itself.
|
||||
tpws must be started under OS user "tpws".
|
||||
|
||||
|
||||
NFQUEUE redirection of the outgoing traffic and forwarded traffic going towards the external interface,
|
||||
can be done with the following commands:
|
||||
|
||||
iptables -t mangle -I POSTROUTING -o <external_interface> -p tcp --dport 80 -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
|
||||
In order not to touch the traffic to unblocked addresses, you can take a list of blocked hosts, resolve it
|
||||
into IP addresses and put them to ipset 'zapret', then add a filter to the command:
|
||||
|
||||
iptables -t mangle -I POSTROUTING -o <external_interface> -p tcp --dport 80 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
|
||||
Some DPIs catch only the first http request, ignoring subsequent requests in a keep-alive session.
|
||||
Then we can reduce CPU load, refusing to process unnecessary packets.
|
||||
|
||||
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 2:4 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
|
||||
|
||||
|
||||
ip6tables
|
||||
---------
|
||||
@ -131,7 +120,7 @@ It takes the following parameters:
|
||||
|
||||
--debug=0|1 ; 1=print debug info
|
||||
--qnum=<nfqueue_number>
|
||||
--wsize=<window_size> ; set window size. 0 = do not modify
|
||||
--wsize=<window_size> ; set window size. 0 = do not modify (obsolete !)
|
||||
--hostcase ; change Host: => host:
|
||||
--hostspell=HoSt ; exact spelling of the "Host" header. must be 4 chars. default is "host"
|
||||
--hostnospace ; remove space after Host: and add it to User-Agent: to preserve packet size
|
||||
@ -360,10 +349,6 @@ The file /opt/zapret/config is used by various components of the system and cont
|
||||
It needs to be viewed and edited if necessary.
|
||||
Select MODE:
|
||||
|
||||
nfqws_ipset - use nfqws on http, targets are filtered by ipset "zapret"
|
||||
nfqws_ipset_https - use nfqws on http and https, targets are filtered by ipset "zapret"
|
||||
nfqws_all - use nfqws on all http
|
||||
nfqws_all_https - use nfqws on all http and https
|
||||
nfqws_all_desync - use nfqws for DPI desync attack on all http and https
|
||||
nfqws_ipset_desync - use nfqws for DPI desync attack on http and https , targets filtered by ipset "zapret"
|
||||
nfqws_hostlist_desync - use nfqws for DPI desync attack on http and https , only to hostnames from hostlist
|
||||
|
||||
142
docs/readme.txt
142
docs/readme.txt
@ -8,15 +8,26 @@ For english version refer to docs/readme.eng.txt
|
||||
Для чего это надо
|
||||
-----------------
|
||||
|
||||
Обойти блокировки веб сайтов http.
|
||||
Автономно, без задействования сторонних серверов, обойти блокировки веб сайтов http и https на DPI.
|
||||
|
||||
Как это работает
|
||||
----------------
|
||||
|
||||
У провайдеров в DPI бывают бреши. Они случаются от того, что правила DPI пишут для
|
||||
обычных пользовательских программ, опуская все возможные случаи, допустимые по стандартам.
|
||||
Это делается для простоты и скорости. Нет смысла ловить хакеров, которых 0.01%,
|
||||
ведь все равно эти блокировки обходятся довольно просто даже обычными пользователями.
|
||||
В самом простейшем случае вы имеете дело с пассивным 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......"
|
||||
@ -25,89 +36,66 @@ For english version refer to docs/readme.eng.txt
|
||||
Кое-где работает добавление дополнительного пробела после метода : "GET /" => "GET /"
|
||||
или добавление точки в конце имени хоста : "Host: kinozal.tv."
|
||||
|
||||
Существует и более продвинутая магия, направленная на преодоление DPI на пакетном уровне.
|
||||
|
||||
|
||||
Как это реализовать на практике в системе linux
|
||||
-----------------------------------------------
|
||||
|
||||
Как заставить систему разбивать запрос на части ? Можно прогнать всю TCP сессию
|
||||
через transparent proxy, а можно подменить поле tcp window size на первом входящем TCP пакете с SYN,ACK.
|
||||
Тогда клиент подумает, что сервер установил для него маленький window size и первый сегмент с данными
|
||||
отошлет не более указанной длины. В последующих пакетах мы не будем менять ничего.
|
||||
Дальнейшее поведение системы по выбору размера отсылаемых пакетов зависит от реализованного
|
||||
в ней алгоритма. Опыт показывает, что linux первый пакет всегда отсылает не более указанной
|
||||
в window size длины, остальные пакеты до некоторых пор шлет не более max(36,указанный_размер).
|
||||
После некоторого количества пакетов срабатывает механизм window scaling и начинает
|
||||
учитываться фактор скалинга, размер пакетов становится не более max(36,указанный_рамер << scale_factor).
|
||||
Не слишком изящное поведение, но поскольку на размеры входящик пакетов мы не влияем,
|
||||
а объем принимаемых по http данных обычно гораздо выше объема отсылаемых, то визуально
|
||||
появятся лишь небольшие задержки.
|
||||
Windows ведет себя в аналогичном случае гораздо более предсказуемо. Первый сегмент
|
||||
уходит указанной длины, дальше window size меняется в зависимости от значения,
|
||||
присылаемого в новых tcp пакетах. То есть скорость почти сразу же восстанавливается
|
||||
до возможного максимума.
|
||||
Если кратко, то варианты можно классифицировать по следующей схеме :
|
||||
|
||||
Перехватить пакет с SYN,ACK не представляет никакой сложности средствами iptables.
|
||||
Однако, возможности редактирования пакетов в iptables сильно ограничены.
|
||||
Просто так поменять window size стандартными модулями нельзя.
|
||||
Для этого мы воспользуемся средством NFQUEUE. Это средство позволяет
|
||||
передавать пакеты на обработку процессам, работающим в user mode.
|
||||
Процесс, приняв пакет, может его изменить, что нам и нужно.
|
||||
1) Пассивный DPI, не отправляющий RST серверу. Помогут индивидуально настраиваемые под провайдера команды iptables.
|
||||
На rutracker в разделе "обход блокировок - другие способы" по этому вопросу существует отдельная тема.
|
||||
В данном проекте не рассматривается. Если вы не допустите срабатывание триггера запрета, то и не придется
|
||||
бороться с его последствиями.
|
||||
2) Модификация TCP соединения на уровне потока. Реализуется через proxy или transparent proxy.
|
||||
3) Модификация TCP соединения на уровне пакетов. Реализуется через обработчик очереди NFQUEUE и raw сокеты.
|
||||
|
||||
iptables -t mangle -I PREROUTING -p tcp --sport 80 --tcp-flags SYN,ACK SYN,ACK -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
Для вариантов 2 и 3 реализованы программы tpws и nfqws соответственно.
|
||||
Чтобы они работали, необходимо их запустить с нужными параметрами и перенаправить на них определенный трафик
|
||||
средствами iptables.
|
||||
|
||||
Будет отдавать нужные нам пакеты процессу, слушающему на очереди с номером 200.
|
||||
Он подменит window size. PREROUTING поймает как пакеты, адресованные самому хосту,
|
||||
так и маршрутизируемые пакеты. То есть решение одинаково работает как на клиенте,
|
||||
так и на роутере. На роутере на базе PC или на базе OpenWRT.
|
||||
В принципе этого достаточно.
|
||||
Однако, при таком воздействии на TCP будет небольшая задержка.
|
||||
Чтобы не трогать хосты, которые не блокируются провайдером, можно сделать такой ход.
|
||||
Создать список заблоченых доменов или скачать его с rublacklist.
|
||||
Заресолвить все домены в ipv4 адреса. Загнать их в ipset с именем "zapret".
|
||||
Добавить в правило :
|
||||
|
||||
iptables -t mangle -I PREROUTING -p tcp --sport 80 --tcp-flags SYN,ACK SYN,ACK -m set --match-set zapret src -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
Для перенаправления tcp соединения на transparent proxy используются команды следующего вида :
|
||||
|
||||
Таким образом воздействие будет производиться только на ip адреса, относящиеся к заблокированным сайтам.
|
||||
Список можно обновлять через cron раз в несколько дней.
|
||||
Если обновлять через rublacklist, то это займет довольно долго. Более часа. Но ресурсов
|
||||
этот процесс не отнимает, так что никаких проблем это не вызовет, особенно, если система
|
||||
работает постоянно.
|
||||
проходящий трафик :
|
||||
iptables -t nat -I PREROUTING -i <внутренний_интерфейс> -p tcp --dport 80 -j DNAT --to 127.0.0.1:1188
|
||||
исходящий трафик :
|
||||
iptables -t nat -I OUTPUT -o <внешний_интерфейс> -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to 127.0.0.1:1188
|
||||
|
||||
Если DPI не обходится через разделение запроса на сегменты, то иногда срабатывает изменение
|
||||
"Host:" на "host:". В этом случае нам может не понадобится замена window size, поэтому цепочка
|
||||
PREROUTING нам не нужна. Вместо нее вешаемся на исходящие пакеты в цепочке POSTROUTING :
|
||||
DNAT на localhost работает в цепочке OUTPUT, но не работает в цепочке PREROUTING без включения параметра route_localnet :
|
||||
|
||||
iptables -t mangle -I POSTROUTING -p tcp --dport 80 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
|
||||
В этом случае так же возможны дополнительные моменты. DPI может ловить только первый http запрос, игнорируя
|
||||
последующие запросы в keep-alive сессии. Тогда можем уменьшить нагрузку на проц, отказавшись от процессинга ненужных пакетов.
|
||||
|
||||
iptables -t mangle -I POSTROUTING -p tcp --dport 80 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:5 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
|
||||
Случается так, что провайдер мониторит всю HTTP сессию с keep-alive запросами. В этом случае
|
||||
недостаточно ограничивать TCP window при установлении соединения. Необходимо посылать отдельными
|
||||
TCP сегментами каждый новый запрос. Эта задача решается через полное проксирование трафика через
|
||||
transparent proxy (TPROXY или DNAT). TPROXY не работает с соединениями, исходящими с локальной системы,
|
||||
так что это решение применимо только на роутере. DNAT работает и с локальными соединениеми,
|
||||
но имеется опасность входа в бесконечную рекурсию, поэтому демон запускается под отдельным пользователем,
|
||||
и для этого пользователя отключается DNAT через "-m owner". Полное проксирование требует больше ресурсов
|
||||
процессора, чем манипуляция с исходящими пакетами без реконструкции TCP соединения.
|
||||
|
||||
iptables -t nat -I PREROUTING -p tcp --dport 80 -j DNAT --to 127.0.0.1:1188
|
||||
iptables -t nat -I OUTPUT -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to 127.0.0.1:1188
|
||||
|
||||
ПРИМЕЧАНИЕ: DNAT на localhost работает в цепочке OUTPUT, но не работает в цепочке PREROUTING без включения параметра route_localnet :
|
||||
|
||||
sysctl -w net.ipv4.conf.<incoming_interface_name>.route_localnet=1
|
||||
sysctl -w net.ipv4.conf.<внутренний_интерфейс>.route_localnet=1
|
||||
|
||||
Можно использовать "-j REDIRECT --to-port 1188" вместо DNAT , однако в этом случае процесс transparent proxy
|
||||
должен слушать на ip адресе входящего интерфейса или на всех адресах. Слушать на всех - не есть хорошо
|
||||
с точки зрения безопасности. Слушать на одном (локальном) можно, но в случае автоматизированного
|
||||
скрипта придется его узнавать, потом динамически вписывать в команду. В любом случае требуются дополнительные усилия.
|
||||
|
||||
Фильтр по owner необходим для исключения рекурсивного перенаправления соединений от самого tpws.
|
||||
tpws запускается под пользователем "tpws", для него задается исключающее правило.
|
||||
|
||||
|
||||
Для перенаправления на очередь NFQUEUE исходящего и проходящего в сторону внешнего интерфейса трафика используются
|
||||
команды следующего вида :
|
||||
|
||||
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
|
||||
|
||||
Чтобы не трогать трафик на незаблокированные адреса, можно взять список заблокированных хостов, заресолвить его
|
||||
в IP адреса и загнать в ipset zapret, затем добавить фильтр в команду :
|
||||
|
||||
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
|
||||
DPI может ловить только первый http запрос, игнорируя последующие запросы в keep-alive сессии.
|
||||
Тогда можем уменьшить нагрузку на проц, отказавшись от процессинга ненужных пакетов.
|
||||
|
||||
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 2:4 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass
|
||||
|
||||
|
||||
Если ваше устройство поддерживает аппаратное ускорение (flow offloading, hardware nat, hardware acceleration), то iptables могут не работать.
|
||||
При включенном offloading пакет не проходит по обычному пути netfilter.
|
||||
Необходимо его отключить. Да, ваш хилый роутер уже не потянет гигабит, даже 200-250 не потянет, а на торрентах и того меньше.
|
||||
Необходимо его отключить. Да, ваш хилый роутер уже не потянет гигабит, даже 200-250 может не потянуть, а на торрентах и того меньше.
|
||||
Но если у вас такой линк, и вы хотите продвинутых вещей от роутера, то вам стоит задуматься о покупке mini pc с двумя или более gigabit ethernet.
|
||||
|
||||
В новых ядрах (и в более старых, openwrt портировал изменение на 4.14) присутствует software flow offloading (SFO).
|
||||
@ -121,6 +109,7 @@ Offload включается через специальный target в iptable
|
||||
Однако, openwrt не предусматривает выборочного управления offload. Если вы хотите с этим связаться,
|
||||
вам придется городить свой собственный огород вокруг этого.
|
||||
|
||||
|
||||
Особенности применения ip6tables
|
||||
--------------------------------
|
||||
|
||||
@ -135,6 +124,7 @@ DNAT на localhost (::1) возможен только в цепочке OUTPUT
|
||||
откуда пришел пакет.
|
||||
NFQUEUE работает без изменений.
|
||||
|
||||
|
||||
Когда это работать не будет
|
||||
---------------------------
|
||||
|
||||
@ -152,6 +142,7 @@ NFQUEUE работает без изменений.
|
||||
Мелкие провайдеры могут покупать услугу фильтрации у вышестоящих, чтобы самим не морочиться, и
|
||||
они уже будут применять DPI.
|
||||
|
||||
|
||||
nfqws
|
||||
-----
|
||||
|
||||
@ -163,7 +154,7 @@ nfqws
|
||||
--user=<username> ; менять uid процесса
|
||||
--uid=uid[:gid] ; менять uid процесса
|
||||
--qnum=200 ; номер очереди
|
||||
--wsize=4 ; менять tcp window size на указанный размер
|
||||
--wsize=4 ; менять tcp window size на указанный размер (устарело !)
|
||||
--hostcase ; менять регистр заголовка "Host:" по умолчанию на "host:".
|
||||
--hostnospace ; убрать пробел после "Host:" и переместить его в конец значения "User-Agent:" для сохранения длины пакета
|
||||
--hostspell=HoST ; точное написание заголовка Host (можно "HOST" или "HoSt"). автоматом включает --hostcase
|
||||
@ -265,6 +256,7 @@ nfqws способен самостоятельно различать поме
|
||||
|
||||
Почему --connbytes 2:4 : 2 - иногда данные идут в 3-м пакете 3-way handshake. 3 - стандартная ситуация. 4 - для надежности. на случай, если выполнялась одна ретрансмиссия
|
||||
|
||||
|
||||
tpws
|
||||
-----
|
||||
|
||||
@ -386,6 +378,7 @@ tpws полностью работает на асинхронных сокет
|
||||
Это может быть полезно для скрытия факта использования VPN. Пониженный MTU - 1 из способов обнаружения
|
||||
подозрительного подключения. С tcp proxy ваши соединения неотличимы от тех, что сделал бы сам шлюз.
|
||||
|
||||
|
||||
Способы получения списка заблокированных IP
|
||||
-------------------------------------------
|
||||
|
||||
@ -475,6 +468,7 @@ zapret-ip.txt => zapret-ip6.txt
|
||||
Помещенные в них IP не участвуют в процессе.
|
||||
zapret-hosts-user-exclude.txt может содержать домены, ipv4 и ipv6 адреса или подсети.
|
||||
|
||||
|
||||
ip2net
|
||||
------
|
||||
|
||||
@ -516,6 +510,7 @@ ip2net
|
||||
Учтите, что арифметика mul/div - целочисленная. При превышении разрядной сетки 32 bit результат непредсказуем.
|
||||
Не надо делать такое : 5000000/10000000. 1/2 - гораздо лучше.
|
||||
|
||||
|
||||
Фильтрация по именам доменов
|
||||
----------------------------
|
||||
|
||||
@ -537,6 +532,7 @@ init скрипт будет запускать tpws с листом zapret-host
|
||||
При использовании больших списков, в том числе списка РКН, оцените объем RAM на роутере !
|
||||
Если после запуска демона RAM под завязку или случаются oom, значит нужно отказаться от таких больших списков.
|
||||
|
||||
|
||||
Проверка провайдера
|
||||
-------------------
|
||||
|
||||
@ -561,10 +557,6 @@ init скрипт будет запускать tpws с листом zapret-host
|
||||
Его нужно просмотреть и при необходимости отредактировать.
|
||||
Выберите MODE :
|
||||
|
||||
nfqws_ipset - использовать nfqws для модификации трафика на порт 80 только на IP из ipset "zapret"
|
||||
nfqws_ipset_https - использовать nfqws для модификации трафика на порты 80 и 443 только на IP из ipset "zapret"
|
||||
nfqws_all - использовать nfqws для модификации трафика на порт 80 для всех IP
|
||||
nfqws_all_https - использовать nfqws для модификации трафика на порты 80 и 443 для всех IP
|
||||
nfqws_all_desync - использовать nfqws для атаки десинхронизации DPI на http и https для всех IP
|
||||
nfqws_ipset_desync - использовать nfqws для атаки десинхронизации DPI на http и https только на IP из ipset "zapret"
|
||||
nfqws_hostlist_desync - использовать nfqws для атаки десинхронизации DPI на http и https только на хосты из hostlist.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user