mirror of
https://github.com/by-sonic/tglock.git
synced 2026-11-05 07:11:56 +03:00
Никита Sonic
8ce9355243
* 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>
109 lines
5.4 KiB
Markdown
109 lines
5.4 KiB
Markdown
# CLI для ARM64 / OpenWrt
|
|
|
|
Цель сборки — `aarch64-unknown-linux-musl`: ARM64 Linux, статический бинарь без
|
|
зависимости от glibc, OpenSSL или WebView. Это подходит для 64-битной прошивки
|
|
NanoPi R4S и других ARM64-роутеров. MIPS и 32-битный ARM требуют другой сборки.
|
|
Проверьте архитектуру прошивки командой `uname -m`: ожидается `aarch64`.
|
|
|
|
Workflow **Static ARM64 CLI** собирает и запускает тесты на ARM64 runner,
|
|
проверяет ELF (нет `INTERP` и `NEEDED`), запуск CLI, завершение по SIGTERM и
|
|
сохранение секрета между запусками. Артефакт содержит бинарь и SHA-256.
|
|
Release workflow прикладывает такой же проверенный артефакт к будущим релизам.
|
|
Наличие сборки в PR не означает, что уже опубликован новый релиз.
|
|
|
|
Это проверка ARM64 Linux, а не испытание конкретной прошивки OpenWrt или
|
|
доступности Telegram через вашего провайдера.
|
|
|
|
## Установка
|
|
|
|
Скачайте артефакт успешного запуска workflow нужного PR либо файл
|
|
`tglock-cli-aarch64-unknown-linux-musl` из релиза, если он там опубликован.
|
|
Сверьте SHA-256, скопируйте бинарь на роутер и выполните:
|
|
|
|
```sh
|
|
chmod 755 /usr/bin/tglock-cli
|
|
/usr/bin/tglock-cli --version
|
|
mkdir -p /etc/tglock
|
|
chmod 700 /etc/tglock
|
|
```
|
|
|
|
Создайте `/etc/tglock/tglock.toml`:
|
|
|
|
```toml
|
|
port = 1080
|
|
lan = true
|
|
secret_file = "/etc/tglock/secret"
|
|
# worker = ["your-name.workers.dev"]
|
|
```
|
|
|
|
`lan = true` нужен для телефонов и компьютеров в домашней сети. По умолчанию
|
|
CLI слушает только loopback. Секрет создаётся при первом запуске и сохраняется
|
|
в указанном файле; он не должен теряться при перезагрузке или обновлении.
|
|
|
|
```sh
|
|
chmod 600 /etc/tglock/tglock.toml
|
|
/usr/bin/tglock-cli --config /etc/tglock/tglock.toml
|
|
```
|
|
|
|
В Telegram выберите MTProto и используйте LAN-адрес роутера, порт `1080` и
|
|
секрет из напечатанной ссылки. `127.0.0.1` на телефоне означает сам телефон.
|
|
Разрешайте входящий TCP `1080` только из доверенной LAN; не публикуйте порт
|
|
в WAN. Звонки через UDP эта сборка не реализует.
|
|
|
|
## Сервис procd
|
|
|
|
После проверки ручного запуска сохраните `/etc/init.d/tglock`:
|
|
|
|
```sh
|
|
#!/bin/sh /etc/rc.common
|
|
START=95
|
|
STOP=10
|
|
USE_PROCD=1
|
|
|
|
start_service() {
|
|
procd_open_instance
|
|
procd_set_param command /usr/bin/tglock-cli --config /etc/tglock/tglock.toml
|
|
procd_set_param respawn 3600 5 5
|
|
procd_set_param stdout 1
|
|
procd_set_param stderr 1
|
|
procd_close_instance
|
|
}
|
|
```
|
|
|
|
```sh
|
|
chmod 755 /etc/init.d/tglock
|
|
/etc/init.d/tglock enable
|
|
/etc/init.d/tglock start
|
|
logread -e tglock
|
|
```
|
|
|
|
Состояние меняется часто, и stdout сервиса уходит в системный журнал. Чтобы TGLock
|
|
его не забивал, задайте отдельный файл в `/etc/tglock/tglock.toml`:
|
|
|
|
```toml
|
|
# /tmp лежит в оперативной памяти: журнал не изнашивает flash и не переживает
|
|
# перезагрузку. Заполненный файл переименовывается в tglock.log.1, больше двух
|
|
# файлов на диске не бывает.
|
|
log_file = "/tmp/tglock.log"
|
|
log_max_mb = 1
|
|
```
|
|
|
|
Смотреть его: `tail -f /tmp/tglock.log`. То же самое флагами: `--log-file`,
|
|
`--log-max-mb`. Ошибки запуска по-прежнему попадают в `logread`. Если журнал не
|
|
нужен совсем, есть `quiet = true`.
|
|
|
|
Обновление: остановите сервис, замените бинарь после проверки контрольной суммы,
|
|
сохраните `/etc/tglock`, запустите сервис снова. Для отмены автозапуска используйте
|
|
`/etc/init.d/tglock stop` и `/etc/init.d/tglock disable`.
|
|
|
|
## TLS и маршруты
|
|
|
|
Встроенный набор доверенных корневых сертификатов webpki обновляется вместе с
|
|
бинарём. Проверка сертификата и имени включена: при подключении к закреплённому
|
|
IP имя Telegram по-прежнему используется для SNI и проверки сертификата.
|
|
На роутере должно быть установлено правильное время.
|
|
|
|
Если все Telegram IP недоступны, нужен доступный маршрут через собственный
|
|
[Cloudflare Worker](CLOUDFLARE_WORKER.md). Статическая сборка сама по себе не
|
|
устраняет блокировку всех внешних маршрутов.
|