loop-uh
0ad0bcc8dd
Some checks failed
Published content check / validate (push) Failing after 5s
Каждая публикуемая заметка получила callout-шапку со ссылкой на свою страницу wiki.zapret.moe (на самой вики она вырезается транформером RemoveMirrorCallout, видна только на зеркале Obsidian Publish и в Forgejo) и SEO-поле description — 1–2 предложения для meta description обоих сайтов. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
276 lines
24 KiB
Markdown
276 lines
24 KiB
Markdown
---
|
||
date: 2026-06-07
|
||
tags:
|
||
- mtproto
|
||
- mtproxy
|
||
- dpi
|
||
- tspu
|
||
- faketls
|
||
- zig
|
||
aliases:
|
||
- mtproto.zig
|
||
- MTProxy на Zig
|
||
- mtbuddy
|
||
- Как работает MTProxy
|
||
link: https://github.com/sleep3r/mtproto.zig
|
||
description: "MTProxy для Telegram и mtproto.zig: как работает FakeTLS, по каким признакам его ловит ТСПУ и какие техники (TCPMSS, nfqws, mask) это обходят."
|
||
---
|
||
|
||
> [!mirror] Резервное зеркало
|
||
> Актуальная версия этой страницы — на основной вики: [wiki.zapret.moe/mtproxy/mtproto-zig](https://wiki.zapret.moe/mtproxy/mtproto-zig)
|
||
|
||
# 🦎 MTProxy и mtproto.zig: что это, как работает и как пережить ТСПУ
|
||
|
||
> [!info] О чём статья
|
||
> Простым языком: что такое **MTProxy** (прокси для Telegram), что такое **FakeTLS**, по каким признакам его ловит DPI/ТСПУ, и какими техниками с этим борется проект **`mtproto.zig`** — современная реализация прокси, которая ставит обход «под ключ». В конце — готовые настройки и чек-лист.
|
||
>
|
||
> Материал **исследовательский и образовательный**: цель — понять механику, а не дать «волшебную галочку».
|
||
>
|
||
> 🛠️ Нужны конкретные команды и пошаговая настройка? → [[mtproxy/mtproto-zig-setup|Runbook: настройка mtproto.zig]].
|
||
|
||
---
|
||
|
||
## TL;DR — если совсем коротко
|
||
|
||
- **MTProxy** — это «дверь» к Telegram в обход блокировки. Телега умеет ходить через него нативно, ставить ничего не надо — достаточно ссылки `tg://`.
|
||
- Современный режим — **FakeTLS**: прокси прикидывается обычным HTTPS-сайтом, чтобы DPI видел «человек зашёл на rutube.ru», а не «кто-то лезет в Telegram».
|
||
- **FakeTLS — это камуфляж, а не невидимость.** Продвинутый DPI (ТСПУ) умеет его распознавать по нескольким признакам.
|
||
- **`mtproto.zig`** наслаивает больше анти-DPI техник, чем другие прокси, и **сам** настраивает обход на уровне ОС (дробление пакетов + zapret). Почти всё включено по умолчанию.
|
||
- Но против **поведенческого** DPI (см. [[VLESS/dpi-tls-june-2026|сибирскую схему]]) MTProxy слабее [[Zapret/mtproto/06-vs-vless|VLESS+REALITY]]. Держите оба: MTProxy — для Telegram «для своих», REALITY — основной канал.
|
||
|
||
---
|
||
|
||
## Часть 1. Что такое MTProxy и зачем он
|
||
|
||
Представьте, что Telegram заблокирован: ваш интернет-провайдер не пускает трафик на серверы Telegram (их называют **DC** — дата-центры). MTProxy — это ваш личный сервер-посредник где-то в другом месте (на VPS). Телефон шлёт всё в Telegram **через него**, а уже он — в настоящие DC.
|
||
|
||
Прелесть в том, что **поддержка прокси встроена в сам Telegram**. Не нужен отдельный VPN-клиент, не нужно ничего устанавливать: человек жмёт на ссылку вида `tg://proxy?...`, Telegram спрашивает «Подключиться?», и всё снова работает.
|
||
|
||
> [!note] MTProto vs MTProxy
|
||
> **MTProto** — это родной протокол шифрования Telegram. **MTProxy** (MTProto Proxy) — прокси, говорящий на этом протоколе. Не путать с обычным SOCKS5/HTTP-прокси: MTProxy «понимает» именно Telegram.
|
||
|
||
### Три режима — и почему важен только один
|
||
|
||
Исторически у MTProxy три способа замаскировать трафик:
|
||
|
||
| Режим | Что делает | Безопасность |
|
||
|---|---|---|
|
||
| **Classic** | голый обфусцированный MTProto | 🔴 ловится мгновенно по сигнатуре |
|
||
| **Secure / dd** | + случайный паддинг, но **без TLS** | 🟠 всё ещё опознаётся как MTProto |
|
||
| **FakeTLS / ee** | завёрнут в настоящий с виду **TLS 1.3** | 🟢 выглядит как обычный HTTPS |
|
||
|
||
На практике сегодня имеет смысл **только FakeTLS** (ссылки-секреты начинаются с `ee`). Остальные DPI видит насквозь.
|
||
|
||
---
|
||
|
||
## Часть 2. Как работает FakeTLS — «на пальцах»
|
||
|
||
Когда вы заходите на любой `https://`-сайт, ваш браузер и сервер сначала здороваются по протоколу **TLS**. Первое сообщение браузера называется **`ClientHello`** — это открытая «визитка»: какие шифры поддерживаю, какие расширения, на какой сайт иду (поле **SNI**). Сервер отвечает **`ServerHello`**. Только потом начинается шифрование.
|
||
|
||
**FakeTLS притворяется этим рукопожатием.** Клиент Telegram шлёт на прокси пакет, который *выглядит* как обычный `ClientHello` (с SNI, например, `rutube.ru`), прокси отвечает правдоподобным `ServerHello` — и для DPI снаружи это «кто-то открыл rutube.ru по HTTPS». А внутри едет зашифрованный MTProto.
|
||
|
||
> [!example] Аналогия
|
||
> FakeTLS — это чемодан с идеальной наклейкой «турист едет в Сочи». Снаружи не отличить от настоящего. Но, как мы увидим, таможня (DPI) научилась смотреть не только на наклейку.
|
||
|
||
---
|
||
|
||
## Часть 3. Как ТСПУ ловит FakeTLS
|
||
|
||
> ТСПУ — «Технические Средства Противодействия Угрозам», DPI-оборудование, установленное у российских операторов. Полный каскад его проверок — в [[Zapret/mtproto/05-censorship|05-censorship]] и [[DPI/dpi-analysis-pipeline|воронке проверок]]. Здесь — то, что бьёт именно по FakeTLS.
|
||
|
||
### Признак 1. Фингерпринт ClientHello (JA3/JA4) — главный
|
||
|
||
Каждая программа собирает `ClientHello` по-своему: свой порядок шифров, свой набор расширений. Этот «почерк» сворачивают в хеш — **JA3** или **JA4**. По нему DPI понимает: «это Chrome 131» или «это клиент Telegram».
|
||
|
||
Проблема: почерк FakeTLS-клиента Telegram **фиксированный и узнаваемый**. В нём нет тех мелочей, что есть у настоящего браузера (GREASE, ECH, post-quantum ключи — подробнее в [[VLESS/dpi-tls-june-2026|разборе про uTLS]]). DPI просто сверяет хеш со списком — и опознаёт прокси.
|
||
|
||
> [!warning] Ключевой момент
|
||
> Этот почерк генерирует **приложение Telegram на телефоне**, а не ваш сервер. Значит, **вы как владелец прокси не можете его поменять.** Нет аналога uTLS из REALITY, который умеет рядиться под Chrome.
|
||
|
||
### Признак 2. Активное зондирование (active probing)
|
||
|
||
ТСПУ не только пассивно смотрит — он сам **стучится** на подозрительный сервер: «А ну-ка покажи, что ты за HTTPS». Если сервер на это отвечает как-то странно (молчит, рвёт соединение) вместо нормального TLS — значит, это не сайт, а прокси. Блок.
|
||
|
||
### Признак 3. Подсеть и ASN
|
||
|
||
DPI смотрит, **откуда** соединение. Если SNI говорит «rutube.ru», а IP принадлежит дешёвому хостингу (Hetzner, Selectel) — это аномалия. В [[VLESS/dpi-tls-june-2026|сибирской схеме]] это вообще Сигнал №1.
|
||
|
||
### Признак 4. Поведение — частота и тайминги
|
||
|
||
Самый современный слой. DPI смотрит не в пакет, а на **манеру**: сколько соединений, как часто, какие размеры пакетов. Прокси открывает залп коннектов к одному «домену» — живой человек так не делает.
|
||
|
||
> [!summary] Итог раздела
|
||
> FakeTLS пробивается через простой DPI («это TLS или нет?»), но против ТСПУ имеет **четыре уязвимых места**: почерк, зонды, подсеть, поведение. Дальше — чем `mtproto.zig` закрывает каждое.
|
||
|
||
---
|
||
|
||
## Часть 4. Чем `mtproto.zig` отвечает на каждый признак
|
||
|
||
`mtproto.zig` — пятая независимая реализация MTProxy (после telemt/mtg/mtprotoproxy/mtproto_proxy, см. [[Zapret/mtproto/02-implementations|02-implementations]]), на языке **Zig**, с CLI-менеджером `mtbuddy`. Главное отличие: она **сама** ставит обход на уровне ОС, а не только проксирует.
|
||
|
||
| Признак ТСПУ | Техника-ответ | Где включается |
|
||
|---|---|---|
|
||
| Фингерпринт ClientHello | **TCPMSS=88** — дробит ClientHello на куски | `mtbuddy install` (OS) |
|
||
| Stateful DPI | **nfqws desync** (fake + split) | `mtbuddy install` (OS) |
|
||
| Сигнатуры в потоке | **Split-TLS / desync** ServerHello | `config.toml` (дефолт on) |
|
||
| Активное зондирование | **Масштировка (mask)** + anti-replay | `config.toml` (дефолт on) |
|
||
| Статистика трафика | **DRS** — мимикрия размеров записей | `config.toml` |
|
||
| Подсеть/бан IP | **IPv6-hopping** | флаг `--ipv6-hop` |
|
||
|
||
### 🔑 Хитрость №1: TCPMSS=88 — обойти «нельзя поменять ClientHello»
|
||
|
||
Мы выяснили, что **содержимое** почерка изменить нельзя. Но можно сделать так, чтобы DPI **физически не увидел его целиком**.
|
||
|
||
При установке соединения сервер сообщает клиенту максимальный размер пакета — **MSS**. Если выставить **MSS = 88 байт**, то клиентский телефон будет вынужден резать всё, что шлёт (включая `ClientHello` ~517 байт), на ~6 крошечных кусочков.
|
||
|
||
DPI, который не собирает поток целиком (а это дорого, и многие не собирают), видит обрывки и **не может приложить сигнатуру** к разорванному почерку.
|
||
|
||
> [!tip] Что это значит
|
||
> Содержимое визитки то же — но она разрезана на 6 частей и приходит по очереди. Таможенник, который читает только первую часть, не может опознать «турист — это прокси».
|
||
|
||
- Включено по умолчанию. Отключить: `--no-tcpmss`. Поменять: `--tcpmss <n>`.
|
||
|
||
### 🔑 Хитрость №2: nfqws TCP desync (zapret) — обмануть stateful DPI
|
||
|
||
`mtproto.zig` встраивает движок **zapret/nfqws** — тот же, что в [[Zapret/about|обходе для YouTube/Discord]]. Он манипулирует исходящими пакетами, чтобы у DPI «поехала» картина соединения:
|
||
|
||
- **fake-пакет** — перед настоящим шлётся фальшивый «валидный» TLS, чтобы запутать машину состояний DPI;
|
||
- **TTL-limited split** — у фейка специально занижен TTL (время жизни): он **долетает до ТСПУ, но умирает до настоящего клиента** (ТСПУ ближе). ТСПУ видит фейк и сбивается, клиент — нет;
|
||
- **md5sig fooling** — к фейку добавляется «битая» TCP-опция: настоящие участники её отбрасывают, а простой парсер ТСПУ принимает в свой учёт.
|
||
|
||
> [!warning] Важная настройка — TTL
|
||
> По умолчанию TTL = `6`, но это **надо тюнить под вашего провайдера** (подсказка из проекта: «4–8 для большинства росс. ISP»). TTL должен быть больше расстояния до ТСПУ, но меньше расстояния до клиента. Прикинуть можно через `traceroute`. Поменять: `mtbuddy nfqws --ttl <n>`.
|
||
|
||
### 🔑 Хитрость №3: Mask — защита от зондов
|
||
|
||
Когда на прокси стучится **неаутентифицированный** клиент (нет правильного секрета — а значит, это либо ошибка, либо зонд ТСПУ), `mtproto.zig` с `mask=true` **молча перенаправляет** его на настоящий `tls_domain`. Зонд получает реальный TLS-ответ настоящего сайта и «верит», что перед ним обычный HTTPS-сервер.
|
||
|
||
Дополнительно есть **anti-replay** и детект зондов **Revisor** (специфичных для ТСПУ).
|
||
|
||
### 🔑 Хитрость №4: правильный домен (`tls_domain`)
|
||
|
||
Прокси в `ServerHello` притворяется конкретным сайтом. Важно выбрать домен, чьё поведение прокси реально может повторить:
|
||
|
||
- ✅ Берите популярные домены с **одним раундом x25519**: `rutube.ru`, `ozon.ru`, `vk.com`, `yandex.ru`.
|
||
- ❌ Избегайте доменов с HRR/secp521r1 (например `wb.ru`) — упрощённый FakeTLS их не повторит, и получится аномалия.
|
||
- ⚠️ Домен **вшивается в ссылку** `tg://` и его **нельзя менять** после раздачи.
|
||
|
||
---
|
||
|
||
## Часть 5. Настройки — что куда ставить
|
||
|
||
> [!important] Главное про конфиг
|
||
> Почти вся защита включена **по умолчанию**. В `config.toml` осознанно трогаете три вещи (`tls_domain`, `mask`, `fake_tls_only`). А **TCPMSS и nfqws — это уровень ОС**, они ставятся флагами `mtbuddy install`, а не в `config.toml`.
|
||
|
||
### Установка «под ключ»
|
||
|
||
```bash
|
||
# Всё включено: FakeTLS + TCPMSS=88 + nginx-masking + nfqws desync
|
||
sudo mtbuddy install --port 443 --domain rutube.ru --yes
|
||
|
||
# Со своим секретом и юзером
|
||
sudo mtbuddy install --port 443 --domain rutube.ru --secret <32hex> --user alice --yes
|
||
```
|
||
|
||
Полезные DPI-флаги: `--tcpmss <n>` (дефолт 88), `--no-tcpmss`, `--no-nfqws`, `--no-masking`, `--ipv6-hop`, `--no-dpi` (выключить всё).
|
||
|
||
### Рекомендуемый `config.toml`
|
||
|
||
Большинство строк — уже дефолты; фиксируем ключевые явно.
|
||
|
||
```toml
|
||
[general]
|
||
use_middle_proxy = true # нужно для медиа на не-Premium и promo-тегов
|
||
|
||
[server]
|
||
port = 443 # любой другой порт подозрителен
|
||
# rate_limit_per_subnet = 0 # ОСТАВЬ 0 для мобильных юзеров РФ (carrier-NAT):
|
||
# иначе зарубишь реальных людей на одной подсети
|
||
|
||
[censorship]
|
||
tls_domain = "rutube.ru" # single-round x25519, НЕ wb.ru; неизменен после раздачи
|
||
mask = true # форвард зондов на домен (анти-probing)
|
||
fake_tls_only = true # реджектить палевный dd-транспорт
|
||
# desync = true # дефолт on — дробит ServerHello
|
||
drs = true # мимикрия размеров TLS-записей под браузер
|
||
fast_mode = true
|
||
|
||
[access.users]
|
||
# секрет на юзера: openssl rand -hex 16
|
||
user1 = "00112233445566778899aabbccddeeff"
|
||
```
|
||
|
||
Осознанные решения:
|
||
|
||
- **`tls_domain`** — единственный критичный выбор (см. Хитрость №4).
|
||
- **`mask = true` + `fake_tls_only = true`** — анти-зонд и отказ от `dd`.
|
||
- **`drs = true`** — дефолт `false`; включить стоит, скорость не падает.
|
||
- **`rate_limit_per_subnet = 0`** — оставить для мобильных юзеров РФ за carrier-NAT, иначе ложные баны реальных людей.
|
||
|
||
---
|
||
|
||
## Часть 6. Чего НЕ делать
|
||
|
||
> [!warning] Лимит SYN-ACK (1/сек) — спорный приём, но может работать
|
||
> Гуляет приём — дропать исходящие SYN-ACK сверх 1/сек правилом nft (`tcp sport <port> ... limit rate over 1/second burst 1 packets drop`). Его часто называют вредным — но это **слишком категорично**.
|
||
>
|
||
> **На пальцах:** SYN-ACK — это ответ сервера «да, можем общаться» во время установки соединения. Если сервер иногда «теряет» этот ответ, клиент переспрашивает через секунду. От этого (а) DPI сбивается со счёта на «кривом» рукопожатии и не опознаёт почерк клиента, и (б) почерк выходит не пачкой, а по одному в секунду — не срабатывает триггер «залпа соединений».
|
||
>
|
||
> Честная картина:
|
||
> - **Цена:** медленная установка новых соединений (каждое сверх лимита ждёт ~1с). Для Telegram с долгоживущими коннектами — терпимая разовая задержка; для веб-сёрфинга было бы больно.
|
||
> - **Глобальный вариант калечит всех юзеров сразу** → правильнее **per-port** лимит (каждому юзеру свой порт = свой бюджет 1/сек).
|
||
> - **Не лечит корень** (фингерпринт) — обходной костыль, может перестать работать при адаптации ТСПУ.
|
||
>
|
||
> Вывод: **тестируй per-port вариант на своём маршруте**. Встроенный `mask`+anti-replay это не заменяет, а дополняет. Подробный разбор с аналогией «на пальцах» и обоими nft-вариантами — в [[Zapret/mtproto/10-telemt-logs-dpi#Лимит SYN-ACK — помогает или нет|10-telemt-logs-dpi]].
|
||
|
||
- **Не раздавайте `dd`-ссылки** при активном DPI — это plain MTProto, палится сразу.
|
||
- **Не меняйте `tls_domain`** после раздачи — он вшит в ссылки.
|
||
- **Не дёргайте настройки под блокировкой** — в [[VLESS/dpi-tls-june-2026|сибирской схеме]] сам паттерн «поймал блок → тут же поменял» провоцирует расширенный блок. Лучше переждать или сменить узел.
|
||
|
||
---
|
||
|
||
## Часть 7. Честный потолок: почему MTProxy слабее REALITY
|
||
|
||
Три структурных причины (подробно — [[VLESS/dpi-tls-june-2026|разбор DPI июнь-2026]]):
|
||
|
||
1. **Почерк клиента не контролируешь** — нет uTLS, JA3/JA4 Telegram фиксирован (Признак 1).
|
||
2. **CDN-фронтинг почти невозможен** — клиент идёт прямо на ваш `IP:port`, подсеть не спрятать (Признак 3). Частичный рычаг — IPv6-hopping и «чистый» провайдер ([[VPS/VPS|VPS]]).
|
||
3. **Нет mux** — залп коннектов сгладить нечем (Признак 4).
|
||
|
||
Сам проект в `THREAT_MODEL.md` честно пишет: *«hardened transport tool, not a universal censorship-proof channel»* — закалённый инструмент, а не универсальная неуязвимость.
|
||
|
||
> [!important] Почерк и SNI меняются только на клиенте
|
||
> Новая детекция (июнь 2026) бьёт по связке «JA4 Telegram + один SNI + залп на
|
||
> один ip:port». Сменить JA4 или ротировать SNI **серверный прокси не может** — их
|
||
> задаёт клиент Telegram, и цензор видит их ещё до сервера. Почему так и что
|
||
> тогда может сервер — в [[mtproxy/ja4-sni-client-side|Кто может менять JA4/SNI]].
|
||
|
||
> [!tip] Правильная стратегия
|
||
> Держите **оба**: MTProxy — удобная «дверь» в Telegram для близких (ноль установки), VLESS+REALITY/XHTTP — основной обход для всего. Когда [[VLESS/dpi-tls-june-2026|VLESS «болеет»]], MTProxy на росс. VPS часто даёт полную скорость, и наоборот.
|
||
|
||
---
|
||
|
||
## ✅ Чек-лист для запуска
|
||
|
||
- [ ] Режим только **FakeTLS** (`ee`-ссылки), **порт 443**, раздача приватная
|
||
- [ ] `tls_domain` — single-round x25519, приличный ASN, выбран один раз
|
||
- [ ] `mask = true`, `fake_tls_only = true`, `drs = true`
|
||
- [ ] `TCPMSS=88` активен (`iptables -t mangle -S` показывает TCPMSS-правило)
|
||
- [ ] nfqws запущен и **TTL подтюнен** под маршрут (`systemctl status nfqws-mtproto`)
|
||
- [ ] `rate_limit_per_subnet = 0`, если юзеры за мобильным NAT РФ
|
||
- [ ] Готов запасной VLESS/XHTTP
|
||
- [ ] Перестал работать → меняй IP/узел, **не крути настройки на лету**
|
||
|
||
---
|
||
|
||
## 📚 См. также
|
||
|
||
- 🔗 **Репозиторий:** [sleep3r/mtproto.zig](https://github.com/sleep3r/mtproto.zig)
|
||
- [[Zapret/mtproto/05-censorship|ТСПУ и обход цензуры для MTProto]] — полный каскад детекции
|
||
- [[Zapret/mtproto/02-implementations|4 реализации MTProxy]] — telemt / mtg / … (без zig)
|
||
- [[Zapret/mtproto/06-vs-vless|MTProxy vs VLESS]]
|
||
- [[Zapret/mtproto/08-best-practices|Best practices: домен и ASN]]
|
||
- [[VLESS/dpi-tls-june-2026|Сибирская схема: подсеть + фингерпринт + частота]]
|
||
- [[DPI/dpi-analysis-pipeline|Воронка проверок DPI: от SYN до ML]]
|
||
- [[VPS/VPS|Выбор VPS и подсети]]
|
||
- [[Zapret/telegram calls|Звонки Telegram]] — через MTProxy не работают
|