zapret2-mcp 0.7.1 → 0.7.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +15 -0
- package/README.md +6 -4
- package/knowledge/strategies/community-strategies.md +129 -0
- package/knowledge/strategies/fake-packets.md +42 -3
- package/knowledge/strategies/orchestration.md +27 -4
- package/knowledge/troubleshooting/common-issues.md +27 -4
- package/knowledge/tspu/architecture.md +18 -3
- package/knowledge/tspu/blocking-methods.md +30 -2
- package/knowledge/tspu/dpi-engine.md +15 -2
- package/knowledge/tspu/legal-risks.md +37 -0
- package/knowledge/tspu/night-reconfig.md +35 -0
- package/knowledge/tspu/two-stage-blocking.md +4 -2
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,20 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## [0.7.3](https://github.com/rcd27/zapret2-mcp/compare/v0.7.2...v0.7.3) (2026-03-28)
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+
### Bug Fixes
|
|
7
|
+
|
|
8
|
+
* **readme:** актуальное состояние базы знаний в readme ([c91441c](https://github.com/rcd27/zapret2-mcp/commit/c91441ce8ef223bbcfe15619a01ba5f2fa7066ad))
|
|
9
|
+
|
|
10
|
+
## [0.7.2](https://github.com/rcd27/zapret2-mcp/compare/v0.7.1...v0.7.2) (2026-03-28)
|
|
11
|
+
|
|
12
|
+
|
|
13
|
+
### Features
|
|
14
|
+
|
|
15
|
+
* **knowledge:** ряд статей и правок, согласно опыту community ([e7769c0](https://github.com/rcd27/zapret2-mcp/commit/e7769c0cadc372e679c3bf5dff2e234069629e41))
|
|
16
|
+
* **knowledge:** стратегии сообщества + данные по ночным перезагрузкам + правки ([2173d3b](https://github.com/rcd27/zapret2-mcp/commit/2173d3bc39711cc1ee2bdf779effff6d6ffd8a5c))
|
|
17
|
+
|
|
3
18
|
## [0.7.1](https://github.com/rcd27/zapret2-mcp/compare/v0.7.0...v0.7.1) (2026-03-28)
|
|
4
19
|
|
|
5
20
|
|
package/README.md
CHANGED
|
@@ -2,21 +2,22 @@
|
|
|
2
2
|
|
|
3
3
|
[](https://github.com/rcd27/zapret2-mcp/actions/workflows/ci.yml)
|
|
4
4
|
[](https://www.npmjs.com/package/zapret2-mcp)
|
|
5
|
-
[](https://www.npmjs.com/package/zapret2-mcp)
|
|
6
|
+
[](./knowledge/)
|
|
6
7
|
[](LICENSE)
|
|
7
8
|
|
|
8
9
|
База знаний по [zapret2](https://github.com/bol-van/zapret2) (DPI bypass) и [blockcheckw](https://github.com/rcd27/blockcheckw) (сканер стратегий). Работает как [MCP-сервер](https://modelcontextprotocol.io/) для LLM-агентов и как обычная документация.
|
|
9
10
|
|
|
10
|
-
> **Можно использовать без агентов.** [`knowledge/`](./knowledge/) —
|
|
11
|
+
> **Можно использовать без агентов.** [`knowledge/`](./knowledge/) — 35 статей на русском языке. Открывайте и читайте как обычную документацию, без установки чего-либо.
|
|
11
12
|
|
|
12
13
|
## Что внутри
|
|
13
14
|
|
|
14
15
|
| Раздел | Статей | Темы |
|
|
15
16
|
|--------|--------|------|
|
|
16
|
-
| [strategies/](./knowledge/strategies/) |
|
|
17
|
+
| [strategies/](./knowledge/strategies/) | 10 | TCP segmentation, fake packets, Lua scripting, QUIC, circular, Discord, Telegram, orchestration, community production strategies |
|
|
17
18
|
| [config/](./knowledge/config/) | 9 | nfqws2 CLI, zapret2 config, desync profiles, hostlists/ipsets, auto-hostlist, security hardening, UCI, blobs, миграция v1 → v2 |
|
|
18
19
|
| [troubleshooting/](./knowledge/troubleshooting/) | 5 | Smart TV + YouTube, QUIC, IPv6, FLOWOFFLOAD, конфликты с Podkop |
|
|
19
|
-
| [tspu/](./knowledge/tspu/) |
|
|
20
|
+
| [tspu/](./knowledge/tspu/) | 6 | Архитектура ТСПУ, DPI engine, методы блокировки, двухстадийная система, ночные реконфигурации, юридические риски |
|
|
20
21
|
| [workflows/](./knowledge/workflows/) | 2 | Установка, поиск стратегии |
|
|
21
22
|
| [blockcheckw/](./knowledge/blockcheckw/) | 2 | Overview, команды |
|
|
22
23
|
| [platforms/](./knowledge/platforms/) | 1 | Linux, OpenWrt, Windows, FreeBSD, OpenBSD, Android |
|
|
@@ -94,6 +95,7 @@ npm start
|
|
|
94
95
|
- [zapret2](https://github.com/bol-van/zapret2) — DPI bypass от bol-van
|
|
95
96
|
- [blockcheckw](https://github.com/rcd27/blockcheckw) — быстрый сканер стратегий
|
|
96
97
|
- [tspu-docs](https://github.com/DanielLavrushin/tspu-docs) — документация ТСПУ
|
|
98
|
+
- Academic: [IMC 2022](https://dl.acm.org/doi/10.1145/3517745.3561461), [IMC 2021](https://dl.acm.org/doi/10.1145/3487552.3487858), [NDSS 2020](https://www.ndss-symposium.org/ndss-paper/decentralized-control-a-case-study-of-russia/), [USENIX Security 2023](https://www.usenix.org/conference/usenixsecurity23/presentation/ramesh-network-responses) — рецензированные исследования архитектуры и поведения ТСПУ
|
|
97
99
|
- Community — обезличенные знания из открытых обсуждений
|
|
98
100
|
|
|
99
101
|
## Лицензия
|
|
@@ -0,0 +1,129 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Community Strategies — Production Examples
|
|
3
|
+
zapret2-version: v0.9.4.5
|
|
4
|
+
tags: community, strategies, circular, production, youtube, examples, multidisorder, multisplit, hostfakesplit
|
|
5
|
+
source: community
|
|
6
|
+
created: 2026-03-29
|
|
7
|
+
updated: 2026-03-29
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Community-стратегии (production-примеры)
|
|
11
|
+
|
|
12
|
+
**Важно:** "серебряной пули" не существует. Эффективность стратегий зависит от провайдера, региона и текущей конфигурации ТСПУ. Используйте `blockcheckw scan` + `blockcheckw check` для поиска рабочей стратегии на вашем подключении.
|
|
13
|
+
|
|
14
|
+
Приведённые примеры — обезличенные стратегии, зарекомендовавшие себя у множества пользователей на разных провайдерах. Актуальность: март 2026.
|
|
15
|
+
|
|
16
|
+
## Шаблон circular-стратегии
|
|
17
|
+
|
|
18
|
+
Большинство production-стратегий используют единый шаблон:
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
--out-range=-s34228
|
|
22
|
+
--payload=tls_client_hello
|
|
23
|
+
--in-range=-s5556 --lua-desync=circular:fails=3:maxtime=60
|
|
24
|
+
--in-range=x
|
|
25
|
+
--lua-desync=<action>:strategy=1
|
|
26
|
+
--lua-desync=<action>:strategy=2
|
|
27
|
+
...
|
|
28
|
+
--lua-desync=<action>:strategy=N:final
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
Разбор:
|
|
32
|
+
- `--out-range=-s34228` — обрабатывать исходящие пакеты в пределах ~25 TCP-пакетов
|
|
33
|
+
- `--in-range=-s5556` — обрабатывать входящие до ~5 TCP-пакетов (для circular-детекции сбоев)
|
|
34
|
+
- `--lua-desync=circular:fails=3:maxtime=60` — переключение стратегии после 3 неудач или 60 секунд
|
|
35
|
+
- `--in-range=x` — отключить обработку входящих для desync-действий (только для circular-мониторинга)
|
|
36
|
+
- `:final` — маркер последней стратегии в цепочке circular
|
|
37
|
+
|
|
38
|
+
## Стратегия: multidisorder + fake (широкая совместимость)
|
|
39
|
+
|
|
40
|
+
Работает на многих провайдерах. Два варианта в circular-ротации:
|
|
41
|
+
|
|
42
|
+
```
|
|
43
|
+
--out-range=-s34228
|
|
44
|
+
--payload=tls_client_hello
|
|
45
|
+
--in-range=-s5556 --lua-desync=circular:fails=3:maxtime=60
|
|
46
|
+
--in-range=x
|
|
47
|
+
--lua-desync=multidisorder:pos=1,sniext+1,host+1,midsld-2,midsld,midsld+2,endhost-1:strategy=1
|
|
48
|
+
--lua-desync=fake:blob=fake_default_tls:badsum:tls_mod=sni=rzd.ru:repeat=8:strategy=1
|
|
49
|
+
--lua-desync=multidisorder:pos=1,sniext+1,host+1,midsld-2,midsld,midsld+2,endhost-1:strategy=2
|
|
50
|
+
--lua-desync=fake:blob=blob_tls_clienthello_www_google_com:optional:tcp_seq=-10000:tcp_ack=-66000:badsum:tls_mod=rnd,dupsid,sni=rzd.ru:repeat=4:strategy=2:final
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
Как работает:
|
|
54
|
+
1. **multidisorder** разбивает ClientHello на 7 точек (SNI extension, hostname, середина SLD, конец hostname) — делает SNI непарсабельным для DPI
|
|
55
|
+
2. **fake** отправляет поддельный ClientHello с подменённым SNI, битой checksum и смещёнными TCP sequence/ack — DPI "залипает" на фейке, сервер отбрасывает
|
|
56
|
+
|
|
57
|
+
## Стратегия: простая fake + multisplit
|
|
58
|
+
|
|
59
|
+
Минимальная стратегия для провайдеров с менее агрессивным DPI:
|
|
60
|
+
|
|
61
|
+
```
|
|
62
|
+
--out-range=-s34228
|
|
63
|
+
--payload=tls_client_hello
|
|
64
|
+
--in-range=-s5556 --lua-desync=circular:fails=3:maxtime=90
|
|
65
|
+
--in-range=x
|
|
66
|
+
--lua-desync=fake:blob=fake_default_tls:tcp_seq=1000000:repeats=1:strategy=1
|
|
67
|
+
--lua-desync=multisplit:pos=2:strategy=1
|
|
68
|
+
--lua-desync=fake:blob=fake_default_tls:tcp_seq=1000000:repeats=1:strategy=2
|
|
69
|
+
--lua-desync=multisplit:pos=midsld:strategy=2
|
|
70
|
+
--lua-desync=fake:blob=fake_default_tls:badsum:repeats=1:strategy=3
|
|
71
|
+
--lua-desync=hostfakesplit:badsum:repeats=1:strategy=3
|
|
72
|
+
--lua-desync=fake:blob=fake_default_tls:tcp_flags_unset=ACK:repeats=1:strategy=4
|
|
73
|
+
--lua-desync=hostfakesplit:disorder_after:tcp_flags_unset=ACK:repeats=1:strategy=4
|
|
74
|
+
--lua-desync=fake:blob=fake_default_tls:tcp_flags_set=SYN:repeats=1:strategy=5
|
|
75
|
+
--lua-desync=hostfakesplit:midhost=midsld:tcp_flags_set=SYN:repeats=1:strategy=5:final
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
5 стратегий в ротации, каждая использует разные методы fooling: tcp_seq offset, badsum, tcp_flags.
|
|
79
|
+
|
|
80
|
+
## Стратегия: расширенная с TTL-перебором
|
|
81
|
+
|
|
82
|
+
Для провайдеров, где DPI чувствителен к TTL:
|
|
83
|
+
|
|
84
|
+
```
|
|
85
|
+
--out-range=-s34228
|
|
86
|
+
--payload=tls_client_hello
|
|
87
|
+
--in-range=-s5556 --lua-desync=circular:fails=3:maxtime=60
|
|
88
|
+
--in-range=x
|
|
89
|
+
--lua-desync=fake:blob=fake_default_tls:ip_ttl=2:repeats=1 --payload=empty --out-range=s1<d1 --lua-desync=pktmod:ip_ttl=1:strategy=1
|
|
90
|
+
--lua-desync=fake:blob=fake_default_tls:ip_ttl=3:repeats=1 --payload=empty --out-range=s1<d1 --lua-desync=pktmod:ip_ttl=1:strategy=2
|
|
91
|
+
...
|
|
92
|
+
--lua-desync=fake:blob=fake_default_tls:ip_ttl=8:repeats=1 --payload=empty --out-range=s1<d1 --lua-desync=pktmod:ip_ttl=1:strategy=7
|
|
93
|
+
--lua-desync=fake:blob=fake_default_tls:badsum:repeats=1:strategy=8
|
|
94
|
+
--lua-desync=fake:blob=fake_default_tls:tcp_ts=-1000:repeats=1:strategy=9:final
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
Circular перебирает TTL от 2 до 8, затем fallback на badsum и tcp_ts. Используется `pktmod:ip_ttl=1` для уменьшения TTL реальных пакетов после отправки fake.
|
|
98
|
+
|
|
99
|
+
## Стратегия: простая без circular (лёгкий DPI)
|
|
100
|
+
|
|
101
|
+
Для провайдеров с простым DPI, где достаточно TCP segmentation:
|
|
102
|
+
|
|
103
|
+
```
|
|
104
|
+
--payload=tls_client_hello
|
|
105
|
+
--lua-desync=tcpseg:pos=0,midsld:ip_id=rnd:repeats=1
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
Минимальный overhead, работает на провайдерах, где DPI не умеет собирать TCP-фрагменты.
|
|
109
|
+
|
|
110
|
+
## Стратегия: fake + multidisorder без circular
|
|
111
|
+
|
|
112
|
+
Простой двухступенчатый bypass без circular-ротации:
|
|
113
|
+
|
|
114
|
+
```
|
|
115
|
+
--payload=tls_client_hello
|
|
116
|
+
--lua-desync=fake:blob=blob_tls_clienthello_escapefromtarkov_com:badsum:tcp_ts=-600000:repeats=6
|
|
117
|
+
--lua-desync=multidisorder:pos=1,sniext+1,host+1,midsld-2,midsld,midsld+2,endhost-1
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
1. 6 fake ClientHello с битой checksum и сильно сдвинутым timestamp
|
|
121
|
+
2. Настоящий ClientHello разбивается multidisorder на 7 позиций
|
|
122
|
+
|
|
123
|
+
## Рекомендации по выбору
|
|
124
|
+
|
|
125
|
+
1. **Начни с простой** (`tcpseg` без circular) — если работает, не усложняй
|
|
126
|
+
2. **Если простая не работает** — попробуй multidisorder + fake (широкая совместимость)
|
|
127
|
+
3. **Если ломается через время** — добавь circular с 3+ стратегиями
|
|
128
|
+
4. **YouTube требует особого подхода** — используй стратегии с out-range=-s34228 для обработки больших ClientHello
|
|
129
|
+
5. **Используй `blockcheckw scan` + `check`** — автоматический подбор всегда лучше ручного
|
|
@@ -4,8 +4,8 @@ zapret2-version: v0.9.4.5
|
|
|
4
4
|
tags: fake, rst, rstack, syndata, fooling, md5sig, badsum, autottl, ttl, ip6, extension headers, tcp_ts_up, tcp_nop_del, ip_id, ipfrag2, synhide
|
|
5
5
|
source: deepwiki/bol-van/zapret2, official-docs
|
|
6
6
|
created: 2026-03-25
|
|
7
|
-
updated: 2026-03-
|
|
8
|
-
revision:
|
|
7
|
+
updated: 2026-03-29
|
|
8
|
+
revision: 3
|
|
9
9
|
---
|
|
10
10
|
|
|
11
11
|
# Fake Packets (инъекция пакетов-обманок)
|
|
@@ -23,6 +23,42 @@ revision: 2
|
|
|
23
23
|
### syndata
|
|
24
24
|
Отправляет данные в SYN-пакете (нестандартное поведение). Сбивает некоторые DPI.
|
|
25
25
|
|
|
26
|
+
### fakeddisorder
|
|
27
|
+
Комбинация fake + disorder в одном действии. Отправляет fake-пакет и переупорядочивает сегменты:
|
|
28
|
+
```
|
|
29
|
+
--lua-desync=fakeddisorder:pos=method+2:tcp_md5
|
|
30
|
+
--lua-desync=fakeddisorder:pos=10,midsld:seqovl=336:seqovl_pattern=blob_tls_clienthello_www_google_com:badsum
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
### tls_client_hello_clone
|
|
34
|
+
Клонирует реальный TLS ClientHello в blob для использования как fake. Создаёт максимально правдоподобный fake, т.к. он основан на реальном пакете:
|
|
35
|
+
```
|
|
36
|
+
--lua-desync=tls_client_hello_clone:blob=cloned_tls:fallback=fake_default_tls
|
|
37
|
+
--lua-desync=fake:blob=cloned_tls:optional:tcp_seq=10000000:tls_mod=rnd,dupsid,sni=fonts.google.com
|
|
38
|
+
```
|
|
39
|
+
Параметры:
|
|
40
|
+
- `blob=<name>` — имя для сохранения клона
|
|
41
|
+
- `fallback=<blob>` — fallback blob, если клонирование не удалось
|
|
42
|
+
|
|
43
|
+
### hostfakesplit
|
|
44
|
+
Split с fake на уровне hostname. Позволяет указать конкретный хост для fake-части:
|
|
45
|
+
```
|
|
46
|
+
--lua-desync=hostfakesplit:host=ozon.ru:midhost=host-2:seqovl=sniext+3:seqovl_pattern=tls_clienthello:badsum:tcp_md5:tcp_ts_up
|
|
47
|
+
--lua-desync=hostfakesplit:host=google.com:tcp_ts=-600000
|
|
48
|
+
```
|
|
49
|
+
Параметры:
|
|
50
|
+
- `host=<domain>` — домен для fake-части
|
|
51
|
+
- `midhost=<pos>` — позиция разделения внутри hostname (`midsld`, `host-2` и т.д.)
|
|
52
|
+
- `altorder=1` — альтернативный порядок отправки сегментов
|
|
53
|
+
- `disorder_after` — переупорядочить после split
|
|
54
|
+
|
|
55
|
+
### pktmod
|
|
56
|
+
Модификация пакета без отправки fake. Используется для изменения параметров реальных пакетов:
|
|
57
|
+
```
|
|
58
|
+
--lua-desync=pktmod:ip_ttl=1
|
|
59
|
+
```
|
|
60
|
+
Часто используется в паре с fake в circular-стратегиях для TTL-перебора.
|
|
61
|
+
|
|
26
62
|
## Параметры fake-пакетов
|
|
27
63
|
|
|
28
64
|
```
|
|
@@ -40,8 +76,11 @@ Lua-формат:
|
|
|
40
76
|
- `blob=<payload>` — binary payload для fake
|
|
41
77
|
- `tcp_md5` — добавить MD5 signature (fooling)
|
|
42
78
|
- `tcp_seq=<offset>` — смещение TCP sequence
|
|
43
|
-
- `tls_mod=<mods>` — модификации TLS: `rnd`, `rndsni`, `sni=<str>`, `dupsid`, `padencap`
|
|
79
|
+
- `tls_mod=<mods>` — модификации TLS: `rnd`, `rndsni`, `sni=<str>`, `dupsid`, `padencap`, `none`
|
|
44
80
|
- `repeats=<N>` — количество повторений fake-пакета
|
|
81
|
+
- `tcp_ack=<delta>` — сдвиг TCP acknowledgment number (например `-66000`)
|
|
82
|
+
- `optional` — не считать ошибкой, если blob не найден
|
|
83
|
+
- `nodrop` — не дропать оригинальный пакет (для multisplit с blob)
|
|
45
84
|
|
|
46
85
|
## Fooling (маскировка fakes)
|
|
47
86
|
|
|
@@ -4,7 +4,7 @@ zapret2-version: v0.9.4.5
|
|
|
4
4
|
tags: circular-strategy, rotation, resilience, multi-strategy, profiles, autohostlist
|
|
5
5
|
source: official-docs
|
|
6
6
|
created: 2026-03-25
|
|
7
|
-
updated: 2026-03-
|
|
7
|
+
updated: 2026-03-29
|
|
8
8
|
---
|
|
9
9
|
|
|
10
10
|
# Оркестрация стратегий
|
|
@@ -22,9 +22,22 @@ Circular — автоматическая ротация между нескол
|
|
|
22
22
|
Параметры:
|
|
23
23
|
- `fails=N` — порог неудач для смены стратегии (по умолчанию 2)
|
|
24
24
|
- `maxtime=N` — временное окно в секундах (по умолчанию 60)
|
|
25
|
+
- `time=N` — альтернативное имя для `maxtime`
|
|
26
|
+
- `retrans=N` — количество ретрансмиссий до считывания неудачи
|
|
27
|
+
- `nld=N` — количество записей в NLD (network latency detection)
|
|
25
28
|
|
|
26
29
|
**Важно:** параметры circular должны быть без пробелов между стратегиями.
|
|
27
30
|
|
|
31
|
+
### Маркер `:final`
|
|
32
|
+
|
|
33
|
+
Последняя стратегия в circular-цепочке должна быть помечена `:final`:
|
|
34
|
+
|
|
35
|
+
```
|
|
36
|
+
--lua-desync=multisplit:pos=1,midsld:strategy=3:final
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
После достижения последней стратегии circular начинает цикл заново с strategy=1.
|
|
40
|
+
|
|
28
41
|
### Привязка стратегий к circular
|
|
29
42
|
|
|
30
43
|
Каждый `--lua-desync` может быть привязан к конкретной стратегии ротации через `strategy=N`:
|
|
@@ -72,9 +85,19 @@ nfqws2 \
|
|
|
72
85
|
|
|
73
86
|
### Range-параметры в circular
|
|
74
87
|
|
|
75
|
-
- `--out-range=-s34228` — обрабатывать исходящие пакеты до ~25 TCP-пакетов (по TCP sequence)
|
|
76
|
-
- `--in-range=-s5556` — обрабатывать входящие пакеты до ~5 TCP
|
|
77
|
-
- `--in-range=x` — отключить обработку входящих (после circular
|
|
88
|
+
- `--out-range=-s34228` — обрабатывать исходящие пакеты до ~25 TCP-пакетов (по TCP sequence). Достаточно для полного TLS ClientHello включая большие (YouTube)
|
|
89
|
+
- `--in-range=-s5556` — обрабатывать входящие пакеты до ~5 TCP-пакетов. Используется circular для детекции сбоев (отсутствие Server Hello = неудача)
|
|
90
|
+
- `--in-range=x` — отключить обработку входящих для desync-действий (ставится после circular-директивы, чтобы desync-действия не реагировали на входящие пакеты)
|
|
91
|
+
|
|
92
|
+
### pktmod в circular
|
|
93
|
+
|
|
94
|
+
`pktmod` — специальное действие для модификации пакета без desync. Используется в паре с TTL-перебором:
|
|
95
|
+
|
|
96
|
+
```
|
|
97
|
+
--lua-desync=fake:blob=fake_default_tls:ip_ttl=3:repeats=1 --payload=empty --out-range=s1<d1 --lua-desync=pktmod:ip_ttl=1:strategy=2
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
Логика: fake отправляется с TTL=3 (умрёт после 3 хопов), затем `pktmod` уменьшает TTL реальных пакетов до 1 для out-range условия `s1<d1` (первый пакет после fake).
|
|
78
101
|
|
|
79
102
|
## Multi-profile конфигурация
|
|
80
103
|
|
|
@@ -4,7 +4,7 @@ zapret2-version: v0.9.4.5
|
|
|
4
4
|
tags: troubleshooting, diagnosis, problems, fixes
|
|
5
5
|
source: official-docs
|
|
6
6
|
created: 2026-03-25
|
|
7
|
-
updated: 2026-03-
|
|
7
|
+
updated: 2026-03-29
|
|
8
8
|
---
|
|
9
9
|
|
|
10
10
|
# Диагностика проблем zapret2
|
|
@@ -50,10 +50,13 @@ blockcheckw status -d example.com
|
|
|
50
50
|
|
|
51
51
|
### Стратегия перестала работать
|
|
52
52
|
|
|
53
|
-
**Причина:** DPI обновился. Стратегия, работавшая вчера, может не работать сегодня.
|
|
53
|
+
**Причина:** DPI обновился. ТСПУ периодически обновляет конфигурации, чаще всего ночью. Стратегия, работавшая вчера, может не работать сегодня.
|
|
54
54
|
**Решение:**
|
|
55
|
-
1.
|
|
56
|
-
2.
|
|
55
|
+
1. Если перестала работать ночью — подождать 15-30 минут, возможна реконфигурация ТСПУ
|
|
56
|
+
2. Запустить `blockcheckw scan` заново для поиска новой стратегии
|
|
57
|
+
3. Для resilience: использовать `--lua-desync=circular:fails=3:maxtime=60` с 3+ стратегиями в ротации
|
|
58
|
+
|
|
59
|
+
Подробнее о ночных реконфигурациях: `tspu/night-reconfig.md`
|
|
57
60
|
|
|
58
61
|
### Модуль NFQUEUE не загружен
|
|
59
62
|
|
|
@@ -100,6 +103,26 @@ echo "nameserver 1.1.1.1" > /etc/resolv.conf
|
|
|
100
103
|
**Диагностика:** blockcheckw check с `--passes 3` обнаружит эту проблему.
|
|
101
104
|
**Решение:** Выбрать стратегию, прошедшую check (32KB+ download).
|
|
102
105
|
|
|
106
|
+
### CPU 100% на слабых роутерах
|
|
107
|
+
|
|
108
|
+
**Симптомы:** Процессор загружен на 100% при активном bypass, роутер тормозит, Wi-Fi отваливается.
|
|
109
|
+
**Причина:** Сложные circular-стратегии с множеством desync-действий (multidisorder, множественные fake) нагружают CPU. Особенно критично на роутерах с одноядерными SoC (Keenetic 1713 и аналоги).
|
|
110
|
+
**Решение:**
|
|
111
|
+
1. Упростить стратегию — использовать `tcpseg` или `split2` вместо multidisorder с 7 позициями
|
|
112
|
+
2. Уменьшить `repeats` в fake (6→2)
|
|
113
|
+
3. Убрать лишние стратегии из circular — оставить 2-3 вместо 10+
|
|
114
|
+
4. Отключить QUIC-обработку, если не нужна
|
|
115
|
+
5. Для YouTube рассмотреть выделение через VPN/прокси вместо zapret2
|
|
116
|
+
|
|
117
|
+
### DNS-резолвер блокирует DoH/DoT
|
|
118
|
+
|
|
119
|
+
**Симптомы:** DNS резолвится, но DoH/DoT подключения к внешним DNS-серверам (1.1.1.1, 8.8.8.8) не работают.
|
|
120
|
+
**Причина:** ТСПУ блокирует DoH/DoT по SNI (dns.google, cloudflare-dns.com) или по IP.
|
|
121
|
+
**Решение:**
|
|
122
|
+
1. Использовать DNS-резолвер роутера с перенаправлением (dnsmasq)
|
|
123
|
+
2. Попробовать менее известные DoH-провайдеры
|
|
124
|
+
3. Применить zapret2 к DNS-трафику (добавить домены DNS-серверов в hostlist)
|
|
125
|
+
|
|
103
126
|
## Диагностические команды
|
|
104
127
|
|
|
105
128
|
```bash
|
|
@@ -1,15 +1,28 @@
|
|
|
1
1
|
---
|
|
2
2
|
title: TSPU Architecture — How Russian DPI Works
|
|
3
3
|
tags: tspu, dpi, architecture, ecofilter, bypass, balancer, filter, blocking
|
|
4
|
-
source: github/DanielLavrushin/tspu-docs
|
|
4
|
+
source: github/DanielLavrushin/tspu-docs, academic/IMC-2022, academic/IMC-2021
|
|
5
5
|
created: 2026-03-25
|
|
6
|
-
updated: 2026-03-
|
|
6
|
+
updated: 2026-03-29
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# Архитектура ТСПУ (DPI-система блокировок)
|
|
10
10
|
|
|
11
11
|
ТСПУ (Технические средства противодействия угрозам) — аппаратный комплекс DPI, установленный у операторов связи в России. Понимание его архитектуры помогает выбирать эффективные стратегии обхода.
|
|
12
12
|
|
|
13
|
+
## Масштаб развёртывания (научные данные)
|
|
14
|
+
|
|
15
|
+
По данным академического исследования (IMC 2022, Diwen Xue et al. "TSPU: Russia's Decentralized Censorship System"):
|
|
16
|
+
|
|
17
|
+
- **1 000 000+** эндпоинтов в России идентифицированы за ТСПУ-устройствами
|
|
18
|
+
- **650+ AS** (автономных систем) охвачены
|
|
19
|
+
- **70%** ТСПУ-устройств расположены **в пределах 2 хопов** от конечного IP-адреса пользователя
|
|
20
|
+
- Устройства работают **in-path** (в разрыв канала), а не off-path/mirrored
|
|
21
|
+
- **Stateful** — поддерживают состояние TCP-сессий с уникальными характеристиками state management
|
|
22
|
+
- **Направленность**: ТСПУ блокирует только соединения, **инициированные из России**. Входящие соединения извне не блокируются.
|
|
23
|
+
|
|
24
|
+
Физическое развёртывание децентрализовано (на площадках провайдеров), но политики блокировки **централизованно управляются** Роскомнадзором.
|
|
25
|
+
|
|
13
26
|
## Компоненты ТСПУ
|
|
14
27
|
|
|
15
28
|
```
|
|
@@ -31,7 +44,7 @@ updated: 2026-03-28
|
|
|
31
44
|
### Фильтр (EcoFilter)
|
|
32
45
|
DPI-устройство. Работает на L2 (прозрачный «провод»). Не имеет IP-интерфейсов в data plane. Отключён LLDP.
|
|
33
46
|
|
|
34
|
-
|
|
47
|
+
**Аппаратура** (из утечек/community, не подтверждено научными публикациями): Intel Xeon Gold 6212 (24 ядра), 192-384 ГБ RAM. До 4160 ядер в старшей линейке.
|
|
35
48
|
|
|
36
49
|
## Путь пакета через фильтр
|
|
37
50
|
|
|
@@ -55,3 +68,5 @@ DPI-устройство. Работает на L2 (прозрачный «пр
|
|
|
55
68
|
- Симметричный хэш → обе стороны сессии на одном ядре → фильтр видит полную картину
|
|
56
69
|
- DPI-листы загружаются периодически → есть окно между появлением ресурса и блокировкой
|
|
57
70
|
- `send RST off` может быть включён → тогда HTTPS блокируется тихим drop вместо RST
|
|
71
|
+
- Направленность → ТСПУ блокирует только outbound-соединения из РФ. Это значит, что серверы за рубежом могут инициировать соединения к российским IP без блокировки
|
|
72
|
+
- Близость к пользователю (2 хопа) → фильтр видит трафик до NAT провайдера, что усложняет использование TTL-based fooling (мало хопов между пользователем и DPI)
|
|
@@ -1,18 +1,29 @@
|
|
|
1
1
|
---
|
|
2
2
|
title: TSPU Blocking Methods and Protocol Degradation
|
|
3
3
|
tags: tspu, blocking, degradation, capacity, rst, redirect, drop, dpi-list, quic
|
|
4
|
-
source: github/DanielLavrushin/tspu-docs
|
|
4
|
+
source: github/DanielLavrushin/tspu-docs, academic/IMC-2022, academic/IMC-2021
|
|
5
5
|
created: 2026-03-25
|
|
6
|
-
updated: 2026-03-
|
|
6
|
+
updated: 2026-03-29
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# Методы блокировки ТСПУ
|
|
10
10
|
|
|
11
|
+
## Три типа триггеров (IMC 2022)
|
|
12
|
+
|
|
13
|
+
По данным академического исследования, ТСПУ использует три типа триггеров для блокировки:
|
|
14
|
+
|
|
15
|
+
1. **SNI-based** — анализ Server Name Indication в TLS ClientHello. Основной метод для HTTPS.
|
|
16
|
+
2. **IP-based** — блокировка по IP-адресу назначения (через DPI-листы или Eco Highway BGP).
|
|
17
|
+
3. **QUIC-based** — анализ QUIC Initial packet, извлечение SNI.
|
|
18
|
+
|
|
19
|
+
Эти три триггера порождают **шесть различных типов блокирующего поведения**, в зависимости от комбинации триггера, протокола и конфигурации DPI-листа.
|
|
20
|
+
|
|
11
21
|
## Типы блокировки (DPI behavior)
|
|
12
22
|
|
|
13
23
|
| Behavior | Действие | Протоколы |
|
|
14
24
|
|----------|----------|-----------|
|
|
15
25
|
| **block** | Блокировка трафика | HTTP → 302 redirect, HTTPS → TCP RST или silent drop |
|
|
26
|
+
| **throttle** | Ограничение скорости (дроп пакетов с вероятностью) | Все |
|
|
16
27
|
| **ignore** | Распознать, но пропустить (для двухстадийной блокировки) | Все |
|
|
17
28
|
| **redirect** | HTTP-редирект на страницу-заглушку | Только HTTP |
|
|
18
29
|
| **color** | Пометить трафик (для мониторинга) | Все |
|
|
@@ -29,6 +40,23 @@ updated: 2026-03-28
|
|
|
29
40
|
|
|
30
41
|
**`send RST off`** — критический параметр. Когда включён, приложения бесконечно пытаются переподключиться (нет явного отказа). Когда выключен — отправляется RST, что является явным сигналом блокировки.
|
|
31
42
|
|
|
43
|
+
## Throttling (целенаправленное замедление)
|
|
44
|
+
|
|
45
|
+
Отдельный от capacity degradation метод. Подтверждён научными исследованиями:
|
|
46
|
+
|
|
47
|
+
**Twitter (март 2021, IMC 2021):**
|
|
48
|
+
- Первый задокументированный случай mass throttling через ТСПУ
|
|
49
|
+
- Триггер: SNI в TLS ClientHello содержит домен Twitter
|
|
50
|
+
- Скорость ограничена до 130-150 kbps путём дропа пакетов
|
|
51
|
+
- Подтверждено замерами из 401 AS в России
|
|
52
|
+
|
|
53
|
+
**YouTube (июль 2024+, DFRLab 2025):**
|
|
54
|
+
- Throttling через дроп ACK-пакетов (client-to-server)
|
|
55
|
+
- Первоначально тестировалось на Ростелеком и Теле2, затем расширено
|
|
56
|
+
- Видео буферизуется, но не блокируется полностью
|
|
57
|
+
|
|
58
|
+
**Отличие от capacity degradation:** throttling — фиксированное ограничение скорости, capacity degradation — вероятностный дроп пакетов. Оба метода обходятся стратегиями DPI bypass, т.к. DPI перестаёт распознавать протокол.
|
|
59
|
+
|
|
32
60
|
## Деградация протоколов (capacity)
|
|
33
61
|
|
|
34
62
|
ТСПУ может **частично** блокировать протокол, дропая пакеты с заданной вероятностью:
|
|
@@ -3,7 +3,7 @@ title: TSPU DPI Engine — How Protocols Are Recognized
|
|
|
3
3
|
tags: tspu, dpi, engine, recognition, protocols, analysis, signatures, obfuscation
|
|
4
4
|
source: github/DanielLavrushin/tspu-docs
|
|
5
5
|
created: 2026-03-25
|
|
6
|
-
updated: 2026-03-
|
|
6
|
+
updated: 2026-03-29
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# DPI Engine ТСПУ — как распознаются протоколы
|
|
@@ -46,10 +46,23 @@ DPI парсит SNI из ClientHello. Если пакет разбит на ф
|
|
|
46
46
|
DPI обрабатывает пакеты последовательно. Fake с поддельным SNI обрабатывается первым, DPI "запоминает" фальшивый домен, настоящий пакет проходит без инспекции.
|
|
47
47
|
|
|
48
48
|
### Почему multisplit нужен против продвинутого DPI
|
|
49
|
-
ТСПУ может пересобирать single-split сегменты (
|
|
49
|
+
ТСПУ предположительно может пересобирать single-split сегменты (community observation; научные публикации не подтверждают TCP reassembly capability напрямую, но эмпирически split2 перестал работать на многих провайдерах). Multi-split на нескольких позициях усложняет reassembly.
|
|
50
50
|
|
|
51
51
|
### Почему capacity degradation (0-100) опасна
|
|
52
52
|
ТСПУ может не полностью блокировать протокол, а дропать пакеты с вероятностью. При capacity 2-10% протокол становится практически нерабочим: голосовые вызовы рвутся, видео буферизуется, страницы не грузятся.
|
|
53
53
|
|
|
54
54
|
### Почему стратегии "протухают"
|
|
55
55
|
ЦСУ видит **все** сессии со **всех** 350 площадок (~5000 устройств). Статистический анализ на таком объёме позволяет выявлять новые паттерны обхода и обновлять сигнатуры.
|
|
56
|
+
|
|
57
|
+
## IPv6 на ТСПУ (март 2026)
|
|
58
|
+
|
|
59
|
+
ТСПУ научился блокировать по IPv6. Ранее IPv6-трафик часто проходил мимо DPI-инспекции, и ресурсы были доступны по IPv6 без каких-либо стратегий bypass. По состоянию на март 2026 это уже не так — ТСПУ обрабатывает IPv6 наравне с IPv4.
|
|
60
|
+
|
|
61
|
+
Последствия:
|
|
62
|
+
- Стратегии, которые работали "из коробки" через IPv6 — перестали работать
|
|
63
|
+
- Необходимо настраивать bypass для IPv6 отдельно: `DISABLE_IPV6=0` в конфиге, поиск стратегий через `IPVS=6`
|
|
64
|
+
- Подробнее см. `troubleshooting/ipv6-trap.md`
|
|
65
|
+
|
|
66
|
+
## Перегрузка ТСПУ через MTProto
|
|
67
|
+
|
|
68
|
+
Массовое использование бесплатных MTProto прокси создаёт значительную нагрузку на ТСПУ. При перегрузке DPI может временно пропускать трафик, который обычно блокирует. Это побочный эффект объёма трафика, а не целенаправленная атака на DPI.
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Legal Risks and ISP Enforcement
|
|
3
|
+
tags: tspu, legal, isp, fine, revizor, rkn, provider, enforcement
|
|
4
|
+
source: community
|
|
5
|
+
created: 2026-03-29
|
|
6
|
+
updated: 2026-03-29
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Юридические риски и контроль провайдеров
|
|
10
|
+
|
|
11
|
+
## Система "Ревизор"
|
|
12
|
+
|
|
13
|
+
РКН использует автоматизированную систему "Ревизор" для мониторинга корректности работы ТСПУ у провайдеров. Система проверяет доступность заблокированных ресурсов из сети провайдера.
|
|
14
|
+
|
|
15
|
+
### Как работает
|
|
16
|
+
- Ревизор выполняет запросы к заблокированным ресурсам через сеть провайдера
|
|
17
|
+
- Если ресурс доступен (трафик не проходит через ТСПУ или ТСПУ не блокирует) — фиксируется нарушение
|
|
18
|
+
- Нарушения агрегируются и передаются в судебную систему
|
|
19
|
+
|
|
20
|
+
### Прецеденты
|
|
21
|
+
- Провайдеры штрафуются по закону "О связи" за обход или некорректную работу ТСПУ
|
|
22
|
+
- Минимальный штраф по статье — 500 000 рублей, суды могут снижать до 250 000 рублей
|
|
23
|
+
|
|
24
|
+
## Что это значит для пользователей zapret2
|
|
25
|
+
|
|
26
|
+
### zapret2 работает на стороне пользователя
|
|
27
|
+
- zapret2/nfqws2 модифицирует трафик на стороне клиента (роутер пользователя)
|
|
28
|
+
- Провайдер не участвует в обходе — ТСПУ установлен у провайдера, но обход происходит на уровне пакетов до ТСПУ
|
|
29
|
+
- Ревизор проверяет провайдера, не пользователя
|
|
30
|
+
|
|
31
|
+
### Отличие от провайдерского обхода
|
|
32
|
+
- Провайдер, маршрутизирующий трафик мимо ТСПУ — нарушает закон
|
|
33
|
+
- Пользователь, модифицирующий свой трафик через zapret2 — другая юридическая ситуация
|
|
34
|
+
|
|
35
|
+
## MTProto прокси и нагрузка на ТСПУ
|
|
36
|
+
|
|
37
|
+
Массовое использование бесплатных MTProto прокси создаёт значительную нагрузку на ТСПУ, что иногда приводит к сбоям в работе DPI. Это побочный эффект, а не целенаправленный обход.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: TSPU Night Reconfiguration
|
|
3
|
+
tags: tspu, reconfig, night, strategy-breaks, timing, maintenance
|
|
4
|
+
source: community
|
|
5
|
+
created: 2026-03-29
|
|
6
|
+
updated: 2026-03-29
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Ночные реконфигурации ТСПУ
|
|
10
|
+
|
|
11
|
+
## Явление
|
|
12
|
+
|
|
13
|
+
ТСПУ периодически обновляет свои конфигурации, преимущественно в ночное время. В момент обновления ранее рабочие стратегии bypass могут временно перестать работать.
|
|
14
|
+
|
|
15
|
+
## Поведение
|
|
16
|
+
|
|
17
|
+
- Обновления происходят нерегулярно, чаще всего ночью (по московскому времени)
|
|
18
|
+
- Во время реконфигурации DPI может вести себя непредсказуемо: пропускать трафик, блокировать ранее работавшие стратегии, или менять паттерны фильтрации
|
|
19
|
+
- После завершения реконфигурации поведение стабилизируется, но набор эффективных стратегий может измениться
|
|
20
|
+
|
|
21
|
+
## Практические последствия
|
|
22
|
+
|
|
23
|
+
### Для пользователей
|
|
24
|
+
- Если стратегия перестала работать ночью — не паниковать, подождать 15-30 минут
|
|
25
|
+
- Если после ожидания не восстановилось — запустить `blockcheckw scan` для поиска новой стратегии
|
|
26
|
+
- Circular strategy с несколькими вариантами (`--lua-desync=circular`) значительно повышает устойчивость к реконфигурациям
|
|
27
|
+
|
|
28
|
+
### Для поиска стратегий
|
|
29
|
+
- Результаты blockcheckw/blockcheck2, полученные ночью в момент реконфигурации, могут быть неточными
|
|
30
|
+
- Оптимальное время для поиска стратегий — дневные часы, когда конфигурация ТСПУ стабильна
|
|
31
|
+
- Верификация через `blockcheckw check --passes 3` помогает отсеять нестабильные результаты
|
|
32
|
+
|
|
33
|
+
### Для circular strategy
|
|
34
|
+
- Circular с 3+ стратегиями автоматически переключается при сбое, что минимизирует влияние реконфигураций
|
|
35
|
+
- Рекомендуемые параметры: `--lua-desync=circular:fails=3:maxtime=60` — даёт ТСПУ время на стабилизацию перед переключением
|
|
@@ -1,13 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
title: TSPU Two-Stage Blocking Process
|
|
3
3
|
tags: tspu, blocking, two-stage, spfs, csu, protocol lists, timing
|
|
4
|
-
source: github/DanielLavrushin/tspu-docs
|
|
4
|
+
source: github/DanielLavrushin/tspu-docs, community
|
|
5
5
|
created: 2026-03-25
|
|
6
|
-
updated: 2026-03-
|
|
6
|
+
updated: 2026-03-29
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# Двухстадийная блокировка ТСПУ
|
|
10
10
|
|
|
11
|
+
**Примечание:** Описание двухстадийного процесса основано на утёкших документах и community-анализе (github/DanielLavrushin/tspu-docs). Академические исследования (IMC 2022) описывают ТСПУ как единую систему и не разделяют на тип А/Б. Внутренняя архитектура не противоречит внешним наблюдениям, но не верифицирована независимо.
|
|
12
|
+
|
|
11
13
|
ТСПУ не блокирует протоколы мгновенно. Процесс блокировки состоит из двух стадий с задержкой 5-15 минут.
|
|
12
14
|
|
|
13
15
|
## Стадия 1: Распознавание (ТСПУ тип А)
|