* fix(tunnel): медиа и «прокси не настроен»: один пакет на кадр, настоящие фронты, kwsN-1 только для медиа
Три причины, каждая проверена на живом Telegram запросом req_DH_params:
сервер сверяет номер DC внутри него с собой и отвечает -444 на чужой.
- WebSocket-фронт разбирает один пакет на входящий кадр, остаток ждёт
следующего. Клиент пишет запросы пачками, TGLock слал их одним кадром,
и всё, что шло вторым, застревало: текст проходил, файлы вставали.
Теперь поток режется на пакеты, как в Flowseal/tg-ws-proxy. Пачка через
beta.18 висит на всех DC, через эту сборку принимается на всех.
- Кластер kwsN-1 отвергает обычное соединение с -444, а Telegram Desktop
в ответ выключает прокси как настроенный неверно. При сбое kwsN основное
соединение откатывалось именно туда. Теперь kwsN-1 только для медиа.
- Адреса из списка DC не говорят на TLS ни из какой сети (проверено с чистой
сети), поэтому первый маршрут каждого DC не работал никогда. Закреплены
настоящие фронты, и DC1, DC3, DC5 стали доступны по WebSocket, чего не было.
У CDN203 своего фронта нет: остались TCP, Worker и CF-прокси.
Обрыв туннеля, через который уже шли данные, больше не ставит маршрут на
паузу. Таймаут соединения 8 с, как в tg-ws-proxy. probe_proxy.mjs получил
--identity и --batched: они и нашли эти баги.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* feat: журнал ошибок в диагностике, --log-file для роутеров; 2.0.0-beta.19
«Скопировать диагностику» отдавала только счётчики, и по ней нельзя было
понять, какой маршрут не ответил. Теперь в отчёте есть строки сбоев туннелей,
а домены Worker и CF-прокси в них заменены на <домен>.
--log-file и --log-max-mb (log_file, log_max_mb в настройках), как в
tg-ws-proxy: журнал идёт в файл с ротацией, а не в системный журнал роутера.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* feat(routes): запасной WebSocket на порту 80 родных адресов, включая CDN203
Родные адреса Telegram принимают WebSocket без TLS на порту 80. Измерено
req_DH_params: DC определяется адресом, имя хоста не важно, а 91.105.192.100
отдаёт ключи CDN. Для CDN203, откуда часто идёт видео, это первый прямой
WebSocket: на 443 фронта у него нет, и там, где провайдер закрыл только 443,
до него раньше было не достать без Worker.
Защита та же, что у родного TCP: внутри тот же обфусцированный MTProto. В Host
идёт адрес, имени Telegram в открытом виде нет. Маршрут разрешён только до
закреплённых адресов и пробуется последним.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(routes): паузы маршрутов по результатам ревью, пределы и журнал
- Обрыв не наказывает маршрут, только если туннель работал и получал ответы
15 с. Одного ответа мало: маршрут, который ответил раз и умер, оставался
предпочтительным навсегда.
- Клиент спросил, не дождался ответа за 5 с и ушёл: маршрут считается
неработающим. Иначе CDN, принявший TCP и молчащий, держал первое место, и
очередь до порта 80 не доходила.
- Предел пакета 2 МиБ вместо 16: чужое устройство в LAN-режиме не заставит
роутер копить десятки мегабайт на соединение.
- Журнал: разовая ошибка записи его больше не выключает, неудачная ротация
не теряет бэкап и держит предел, права 0600 и на уже существующем файле.
- В отчёт диагностики не попадает Worker, заданный адресом.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: babin <Thartewerner536e@engineer.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* feat: native MTProto TCP fallback and CF-proxy domains, after Flowseal/tg-ws-proxy; 2.0.0-beta.17
Two routes Flowseal/tg-ws-proxy has and TGLock lacked.
Native TCP fallback. When every WebSocket route for a DC fails, TGLock now
tries plain obfuscated2 MTProto to the DC's primary address, which the
CDN203 route already used. Measured from a Russian ISP: TLS to .51, .91,
.50, .100 and .5 was cut, while native TCP to each answered req_pq_multi,
for main and media DCs alike. 149.154.167.220 is a WebSocket frontend only
and gets no TCP route. TCP opens before Telegram answers, so it is raced
only after all other routes failed; it can never displace a slower working
WebSocket. Raw TCP stays restricted to the pinned Telegram addresses.
CF proxy. A user's own Cloudflare domain with kws1..kws5/kws203 records
pointing at Telegram proxies the WebSocket without a Worker or its limits
(--cf-proxy, cf_proxy in tglock.toml, a GUI field; docs/CF_PROXY.md).
GUI settings now deserialize with serde(default): a file written before a
field existed used to fail to parse and silently reset to defaults.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* style: cargo fmt
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: babin <Thartewerner536e@engineer.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* worker: set binaryType = "arraybuffer" to fix 1003 "binary messages required"
Since compatibility date 2026-03-17 Cloudflare delivers binary WebSocket messages as Blob (websocket_standard_binary_type). The message handler accepts only ArrayBuffer and closes every tunnel with 1003. Setting binaryType before accept() restores ArrayBuffer delivery regardless of the compatibility date.
* fix(worker): accept Blob frames and name an outdated Worker in the log; 2.0.0-beta.16
Since compatibility date 2026-03-17 Cloudflare delivers binary WebSocket
frames as Blob unless binaryType is "arraybuffer", and the Worker closed
every tunnel with 1003 right after the handshake. wrangler.toml itself pins
2026-09-19, so every fresh deployment was broken (#58, #50, #53).
On top of #61 (binaryType before accept) the Worker now also relays Blob
frames in order, and the client log tells the user to redeploy the script
when a Worker closes with "1003 binary messages required".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Dmitry Sankevich <16187308+avost@users.noreply.github.com>
Co-authored-by: babin <Thartewerner536e@engineer.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* fix: address routing, media, worker and platform issues
* ci: use available Android tools and verify Windows CLI artifact
* fix(gui): return a result from asynchronous stop command
* test(android): verify installed APK and proxy lifecycle on emulator
* fix(media): use native MTProto for CDN203 and retain recent diagnostics
* Fix owned WebSocket split after transport boxing
* Clarify CDN transport and connection status guarantees
* Recognize accessible Android power button labels
* chore(release): prepare 2.0.0-beta.15 with verified draft publication
---------
Co-authored-by: babin <Thartewerner536e@engineer.com>
Скрипт воркера писал в сокет Telegram так:
server.addEventListener("message", (event) => {
writer.write(chunk).catch(shutdown);
});
`write()` вызывался поверх незавершённого, `writer.ready` не спрашивался вовсе.
Пока в клиенте голодала отправка, настоящего потока вверх через воркер не
возникало, и код держался. В beta.12 голодание починили — поток появился, и
репортёр #42 сразу получил переподключения на обоих клиентах, которых на
beta.11 с тем же воркером не было.
Запись сериализована цепочкой промисов: следующий чанк уходит после того, как
записан предыдущий, и только когда писатель готов. Кто разворачивал воркер
раньше — нужен передеплой, о чём сказано в docs/CLOUDFLARE_WORKER.md.
Причина у репортёра не подтверждена: рантайма Workers у меня нет, проверить
можно только у него.
Заодно счётчик «промолчали». Соединение, которое открылось и ничего не
прислало за `IO_TIMEOUT`, закрывалось и не попадало ни в один счётчик:
`unknown_clients` растёт, только когда запрос пришёл и не разобрался, а не
когда его не дождались. Тот же репортёр сообщил, что его телефон
переустанавливает соединение примерно раз в десять секунд — ровно период
`IO_TIMEOUT`. Проверить это по диагностике было нечем, теперь есть чем.
Тесты: Ping через туннель (путь не был покрыт вовсе, а Ping бывает только на
маршруте воркера) и молчащий клиент. Второй гоняет виртуальное время, чтобы не
ждать десять секунд по-настоящему, — отсюда dev-зависимость на tokio/test-util.
Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>
`TransportEngine::connect` собирает подробный перечень попыток — какой адрес не
ответил, где истёк TLS, что вернул воркер, — и возвращает его в `Err`. Дальше
этот `Err` доходил до `serve`, где выбрасывался: `let _ = handle(...)`.
Увеличивался только счётчик.
Снаружи это выглядит как `туннелей 0 · сбоев 249 · падений маршрутов 395` без
единого слова о том, почему их ноль. Отличить «провайдер режет закреплённые
адреса» от «воркер отвечает отказом» нечем, хотя рядом есть журнал событий, в
который пишутся куда менее важные вещи.
Теперь причина попадает в журнал строкой вида:
Не поднялся туннель до DC2: 149.154.167.51 — не отвечает (таймаут TCP);
kws2.web.telegram.org — таймаут TLS/WebSocket
Дедупликация журнала делает её разовой: набор маршрутов у DC стабилен.
Там же вторая слепая зона. Домен воркера, не похожий на имя хоста, отбрасывался
молча: `https://name.workers.dev/` со схемой или слэшем не проходит
`valid_domain`, маршрут не появляется, и «воркер настроен» неотличимо от
«воркера нет». `set_worker_domains` теперь возвращает принятые и отвергнутые
по отдельности, отвергнутые называются вместе с причиной, принятые
подтверждаются.
Тексты отказов переведены на русский: их читает не разработчик, а человек,
который прислал скриншот и ждёт ответа.
Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>
Оба направления туннеля обслуживал один `select!` с пометкой `biased`.
`biased` опрашивает ветки строго по порядку: пока в первой — «Telegram →
клиент» — есть данные, до второй очередь не доходит вообще. При непрерывном
потоке вниз, то есть при первичной синхронизации телефона или загрузке медиа,
исходящие пакеты клиента не читались.
Второй дефект в том же цикле: одна задача на оба направления. `tcp_w.write_all`
ждёт, пока клиент разберёт присланное, и всё это время не опрашивается чтение
от клиента. Телефон по Wi-Fi разбирает поток медленнее, чем Telegram Desktop на
той же машине через loopback, — отсюда асимметрия «на компьютере работает, на
телефоне нет».
Для MTProto это фатально: клиент обязан слать подтверждения, а за каждым
следующим куском файла — свой `upload.getFile`. Первый запрос уходит, дальше
идёт поток вниз, и следующие запросы наверх не попадают. Снаружи это выглядит
как «Подключено» при живом туннеле, нулевых сбоях и нулевых отклонениях: чаты
на месте, иконки не грузятся, отправка виснет с часиками.
Направления разделены на две независимые половины: `ws.split()` плюс
`CryptoContext::split()`, потому что шифры направлений независимы — два потока
AES-CTR со своими ключами. Ping приходит в читающую половину, а отвечает на
него пишущая, через канал на четыре слота: владелец отправляющей половины
должен оставаться ровно один.
Два теста, падающие на beta.11: за пять секунд непрерывной загрузки наверх не
уходит ни одного байта, и клиент, не успевающий читать, замораживает
собственную отправку. Снятие одного `biased` чинит только первый — это и
показывает, что дефекта два.
Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>
В диагностике из #42 встречаются строки вида
соединений 9 · туннелей 9 · DC5 · Запасной Telegram IP · сбоев 12
Такого сочетания не бывает: у DC1, DC3, DC5 и DC203 закреплённый адрес ровно
один, и маршрута «запасной адрес» у них не существует в принципе. Значит номер
и маршрут пришли из разных соединений.
Так и было. `last_dc` писало соединение при разборе init, `last_route` — другое
соединение после рукопожатия, двумя независимыми атомиками. У репортёра от
пяти до двадцати шести одновременных соединений, поэтому пара складывалась
случайно. Читается она как «до этого DC шли этим маршрутом» и в этом качестве
врала — ровно тот класс дефектов, ради которого затевалась честная диагностика
в #38.
Теперь пара пишется одним значением в момент, когда туннель поднялся:
`dc << 8 | route`. Пока туннеля не было, показывается разобранный DC и
«маршрут ещё не выбран» — это состояние тоже настоящее и его терять не надо.
Поля стали приватными, наружу выведены `last_dc()` и `last_route()`, чтобы
рассогласовать их снаружи было нельзя.
Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>
Диагностика от @alexsagaidak в #42 показала третий случай, которого ни один
счётчик не различал. У него ноль отклонённых и живые туннели, то есть оба
показателя говорят «всё хорошо»:
соединений 17 · туннелей 6 · DC4 · Запасной Telegram IP · сбоев 0 ·
падений маршрутов 26 · отклонено 0
Клиент, который дошёл до прокси, но не сумел договориться, не попадал ни в
blocked, ни в ws_failures. Ошибка из handle() выбрасывалась в `let _ =`,
соединение закрывалось, и наружу это выглядело как active, дёрнувшийся вверх и
обратно. По диагностике неотличимо от клиента, который подключился и работает.
Теперь такие клиенты считает unknown_clients, а журнал называет адрес и
причину. Причин две:
MTProto-init не разбирается под текущим секретом. Почти всегда это ссылка
tg://proxy от прошлого запуска: секрет — её половина, и клиент с сохранённой
старой ссылкой попадает ровно сюда. Со стороны Telegram это и есть «прокси
настроен неверно и будет отключён» — то, с чем пришли в #37 и что до сих пор
нельзя было подтвердить со стороны прокси.
SOCKS5-приветствие не разбирается. Сюда же попадает MTProto-соединение,
ушедшее в SOCKS5-ветку по неоднозначному первому байту, если полный init не
успел прийти за PROTOCOL_PROBE_TIMEOUT. На loopback этого не бывает, а через
Wi-Fi с телефона — уже вопрос задержки.
От ws_failures отличается тем, что тот растёт после успешного рукопожатия с
клиентом: там договорились с клиентом, но не смогли с Telegram. Различать их
важно, иначе непонятно, в какую сторону смотреть.
В интерфейсе — метрика «Не опознаны» с пояснением, в строке статуса CLI —
поле «не опознано N».
Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>
@alexsagaidak: с компьютера прокси работает, с телефона — нет. Адрес машины
вписан верно, порт верный, брандмауэр выключен, порт добавлен в исключения.
Причина нашлась в проверке «это Telegram?». Она сравнивала два первых октета:
(149, 154) => Some(...)
(91, 108) => Some(...)
То есть «телеграмом» считались целиком четыре /16 — десятки тысяч чужих
адресов, — а IPv6 не распознавался вообще ни один. Telegram владеет
149.154.160.0/20, шестью /22 в 91.108, 91.105.192.0/23, 185.76.151.0/24 и пятью
блоками IPv6.
Ошибка в обе стороны, и на loopback она не видна. Там allow_direct включён, и
неопознанный адрес всё равно релеится напрямую — соединение просто работает.
На сетевом слушателе allow_direct выключен, и тот же адрес получает SOCKS5
0x02. Отсюда ровно то, что описал репортёр: на компьютере работает, с телефона
нет. Заодно чужие адреса внутри этих /16 уходили в MTProto-туннель и умирали
там.
Список сетей теперь опубликованный самим Telegram
(core.telegram.org/resources/cidr.txt), проверка по маске префикса, IPv4 и
IPv6, с тестами на края блоков и на соседей за границей.
Отдельно разрешены имена веб-инфраструктуры: telegram.org, t.me, telegram.me,
telesco.pe, cdn-telegram.org. Это не MTProto, а обычный HTTPS — клиент ходит
туда за конфигурацией, превью и файлами CDN, и на телефоне эти запросы идут
через тот же прокси. Заворачивать их в туннель нельзя, поэтому они идут прямым
релеем. Совпадение по границе метки, так что telegram.org.example.com —
посторонний домен. В ограниченном режиме имя разрешается заранее и адреса
внутри локальной сети отбрасываются: назначение выбирает чужое устройство, и
DNS-ответ не должен открывать доступ к 192.168.х этой машины.
И главное для разбора следующего такого случая: отказ перестал быть
молчаливым. Появился счётчик «Отклонено» в диагностике и в строке статуса CLI,
отклонённый адрес один раз называется в журнале, и отдельно отмечается первое
подключение с каждого сетевого адреса. Без этого «с телефона не работает»
неразличимо распадалось на два случая: телефон не дошёл до машины — и дошёл,
но попросил адрес, который мы не пускаем. Теперь первый виден как ноль
соединений и ноль отказов, второй — как соединения есть, отказы растут.
Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>
Два дефекта одного класса: состояние, которое не отражает реальность. Оба
найдены по данным из #32 и #37.
#32. Присланный лог показывал «сбоев 0» при том, что DC2 и DC4 всегда шли через
«Запасной Telegram IP», а DC203 всегда через «Системный DNS» — то есть
основные закреплённые адреса не использовались ни разу. Причина в счётчике:
ws_failures растёт только когда упали ВСЕ маршруты и соединение не состоялось.
Падения отдельных маршрутов через record_failure не попадали никуда, поэтому
перебор с откатом на запасной адрес выглядел как полное отсутствие проблем.
Добавлен route_failures: растёт на каждое падение маршрута, виден в строке
статуса CLI и в диагностике интерфейса. Теперь по логу сразу видно, что
закреплённый адрес мёртв, а не приходится это выводить.
#37. Симптом: Telegram пишет «прокси настроен неверно и будет отключён», при
этом Check status показывает Available. Это картина несовпадения секрета: TCP
проходит, init не разбирается под другим секретом, соединение закрывается.
Секрет мог меняться молча:
#[cfg(not(unix))]
fn write_secret_file(path: &Path, value: &str) {
let _ = std::fs::write(path, value); // ошибка выброшена
}
create_dir_all рядом — так же. Если запись в %APPDATA%\TGLock\secret не
удавалась, программа генерировала новый секрет при каждом запуске и ничего об
этом не сообщала.
Теперь write_secret_file возвращает Result, load_or_create_secret_at отдаёт
StoredSecret с полем write_error, а оба интерфейса показывают предупреждение:
CLI строкой при старте, GUI записью в журнал. Прокси при этом продолжает
работать — просто до перезапуска.
Тесты: every_route_failure_is_counted, a_failed_write_is_reported_instead_of
_swallowed (родитель пути — файл, поэтому каталог не создать),
a_successful_write_reports_no_error (секрет переживает второй запуск).
В диагностике интерфейса добавлена подсказка: падения маршрутов больше нуля
при работающем Telegram — норма, значит закреплённый адрес недоступен и
подключение идёт через запасной.
Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>
Резервный маршрут через Worker был в коде с 2.0, но воспользоваться им никто
не мог: в ARCHITECTURE_V2.md описан только контракт эндпоинта — это
спецификация для того, кто будет писать воркер, а не руководство. Ни скрипта,
ни шагов в репозитории не было. Поэтому люди, у которых легли все обычные
маршруты, писали «не работает» вместо того, чтобы включить запасной выход.
Добавлено:
- worker/tglock-worker.js — готовый скрипт. Проверяет путь и upgrade,
подтверждает подпротокол binary (без этого клиент рвёт рукопожатие),
соединяется только с семью адресами Telegram, которые запрашивает TGLock,
и поддерживает необязательный TGLOCK_TOKEN. Без списка адресов воркер стал
бы открытым TCP-прокси для любого, кто узнает его адрес.
- docs/CLOUDFLARE_WORKER.md — когда это нужно и когда нет (таблица
«что видно в приложении → нужен ли Worker»), установка через веб-интерфейс,
проверка живости, подключение в GUI и через --worker, ограничение доступа,
контракт для своих реализаций.
- Ссылки из README: в FAQ про блокировку web.telegram.org и в блок docs.
Контракт закреплён тестами, чтобы документация не разошлась с кодом:
- worker_path вынесен в функцию, из неё же строятся боевые маршруты;
- documented_worker_contract_matches_the_requested_path сверяет формат пути;
- worker_allowlist_covers_every_address_a_route_can_ask_for падает, если в
маршрутах появится адрес, которого нет в скрипте воркера;
- connects_through_the_documented_worker_contract поднимает сервер, ведущий
себя ровно по документации, и проверяет что туннель работает в обе стороны
и что запрошен именно документированный URI.
Чего тесты не проверяют: развёрнутый воркер в самом Cloudflare. Это указано и
в самой инструкции.
Отдельно: снят флаг prerelease в release.yml. До правки /releases/latest
отдавал v2.0.0-beta.1, то есть кнопка «Скачать» в README вела на сборку без
CLI и без фикса рендера. Существующий релиз v2.0.0-beta.2 помечен как latest
вручную.
Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>
fix(proxy): считать туннель только после успешного рукопожатия
README обещал то, чего код не делает. Проверено по исходникам, исправлено:
- «Голосовые/видеозвонки рвутся» стояло в списке «кому подойдёт», то есть
подразумевалось, что TGLock их лечит. Не лечит: звонки по UDP, проксируется
только TCP. То же обещание было в FAQ. Появился явный раздел «чего TGLock
не делает» — звонки, всё кроме Telegram, Android и iOS.
- «IP отобразится прямо в интерфейсе TGLock» в описании LAN-режима. Такого
поля в интерфейсе нет: StatusSnapshot отдаёт только порт. Заменено на то,
что есть — готовую tg://-ссылку и команды для поиска адреса руками.
- «Кода ~350 строк» — в действительности 2872 строки Rust (из них ~1140
тесты) и ~380 строк TypeScript.
- «DC ID — i32 в [60..64]» — на самом деле i16 в [60..62], отрицательное
значение означает медиа-соединение.
- Транспорт описывался как единственный маршрут через web.telegram.org. В 2.0
это каскад: закреплённые IP, дублёры kwsN-1, системный DNS и опциональный
Cloudflare Worker, с cooldown на упавших. Указано, что системный DNS и hosts
не изменяются, а SNI и Host остаются настоящими.
- FAQ про macOS ссылался на файл tglock-macos-arm64, которого в релизах нет.
- «Собирает бинарники для всех 4 платформ» — их три, плюс CLI.
- Пустая колонка «Размер» в таблице загрузок заполнена реальными размерами.
- FAQ про использование как обычного SOCKS5 не отражал, что на сетевом адресе
не-Telegram запросы отклоняются.
- FAQ про блокировку web.telegram.org обещал спасение, которого нет; теперь
там сказано и про запас маршрутов, и про предел подхода.
Реклама RoseVPN сведена в один блок сверху: удалены секция внизу, три вставки
в FAQ и ссылка в подвале.
Добавлен раздел «Как помочь» с тем, что прислать в баг-репорте, и списком
известных ограничений, по которым issue открывать не нужно.
Правка кода, без которой один из абзацев README был бы неправдой: счётчик
Stats::ws увеличивался до WebSocket-рукопожатия, поэтому пока прокси перебирал
маршруты по несколько секунд каждый, интерфейс уже показывал «Telegram на
связи». Теперь счёт ведёт RAII-guard после успешного connect, и состояния
«порт открыт», «идёт перебор» и «туннель есть» различимы. Тест
a_tunnel_counts_only_after_the_handshake_succeeds держит это: молчащий
listener, рукопожатие в полёте, ws и last_route обязаны остаться нулями.
Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>
Реализует направление PR #15 поверх архитектуры 2.0. Сам PR смерджить нельзя:
он патчит src/bypass.rs, src/network.rs и src/ws_proxy.rs, которых больше нет,
и правит системный DNS — в 2.0 это не нужно, потому что адреса Telegram зашиты
в маршрутах, а SNI остаётся настоящим. Взято разделение GUI/CLI и произвольный
bind-адрес, отброшены DNS-менеджмент и проверка root: CLI не требует прав.
Closes#10, #17 — GUI не создаёт окно без 3D-ускорения, на машине без монитора
и в виртуалке. Причина в WebView под Tauri, поэтому лечится не программным
рендером, а бинарём, в котором WebView нет вовсе: при выключенной фиче gui
Tauri и фронтенд в сборку не попадают. Отдельная задача CI собирает и гоняет
CLI на голом ubuntu без Node.js и без libwebkit2gtk.
Структура:
- src/lib.rs — ядро (mtproto, proxy, transport, config), без Tauri
- src/main.rs — GUI, required-features = ["gui"]
- src/bin/cli.rs — headless-бинарь на clap
- build.rs вызывает tauri_build только при включённой фиче gui
Исправлено по пути:
- Определение протокола: SOCKS5 и MTProto различались по первому байту, но
is_reserved_init не исключает 0x05, поэтому примерно одно соединение из 256
уезжало в SOCKS5-ветку и умирало. Теперь неоднозначный первый байт решается
по полному 64-байтному init и секрету.
- Ярлык маршрута в UI: код 2 подписывался как «Cloudflare Worker», хотя это
запасной Telegram IP, а системный DNS и настоящий Worker оба показывались
как «Автоматический маршрут». Метки переехали в transport::route_label,
общий для обоих интерфейсов.
- Секрет прокси: под DynamicUser и ProtectHome домашней папки нет, secret_path
возвращает None и секрет генерировался заново при каждом старте, ломая всем
настроенным клиентам tg://-ссылку. Добавлен --secret-file.
- README обещал Rust 1.75+, тогда как Cargo.toml требует 1.88 и CI это
проверяет. Это и есть первопричина #3.
Политика доступа: прямые не-Telegram соединения разрешены только на loopback,
на любом сетевом адресе нужен явный --allow-direct. Правило из ISSUE_AUDIT о
том, что LAN не должен становиться открытым SOCKS5, теперь выражено в типе
ListenConfig и покрыто тестами.
Тесты: 46 в библиотеке + 12 в CLI. Появился сквозной тест туннеля против
мок-релея, который реализует сторону Telegram по obfuscated2 — проверяется
не внутренняя консистентность, а что реле получает ровно тот открытый текст,
который отправил клиент, и обратно. Плюс расписание backoff, фолбэк при всех
маршрутах в cooldown, валидация Worker-доменов, отказы SOCKS5, устойчивость
секрета к перезапуску и корректная остановка по SIGTERM.
Документация: секция CLI в README с юнитом systemd и Dockerfile.
Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>
Никита Sonic