Files
Никита Sonic 8ce9355243 fix: медиа и «прокси не настроен»: пакет на кадр, настоящие фронты, kwsN-1 только для медиа; beta.19 (#75)
* 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>
2026-10-31 07:32:03 +00:00

5.4 KiB

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, скопируйте бинарь на роутер и выполните:

chmod 755 /usr/bin/tglock-cli
/usr/bin/tglock-cli --version
mkdir -p /etc/tglock
chmod 700 /etc/tglock

Создайте /etc/tglock/tglock.toml:

port = 1080
lan = true
secret_file = "/etc/tglock/secret"
# worker = ["your-name.workers.dev"]

lan = true нужен для телефонов и компьютеров в домашней сети. По умолчанию CLI слушает только loopback. Секрет создаётся при первом запуске и сохраняется в указанном файле; он не должен теряться при перезагрузке или обновлении.

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:

#!/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
}
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:

# /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. Статическая сборка сама по себе не устраняет блокировку всех внешних маршрутов.