Перейти к основному содержимому

Устранение неполадок

Все строки лога, относящиеся к Telegram, помечены тегом [tg-bridge], а строки, принадлежащие одному клиенту, несут ещё и счётчик соединения: [tg-bridge c=1f].

Строкам рукопожатия нужен debug-уровень

proxy fake-TLS handshake OK и proxy fake-TLS failed пишутся на уровне debug. На уровне по умолчанию работающий прокси показывает только строку ретрансляции, а отклонённый клиент - вообще ничего.

Telegram висит на «Подключение»​

Рабочая сессия пишет по одной строке на клиента на уровне info:

[tg-bridge c=3] proxy relay [phone] 192.168.1.50:51234 <-> DC2 via ws:kws2.web.telegram.org

Если строки нет вовсе, соединение не доходит до b4. На хосте, чей файрвол отбрасывает входящие соединения, снаружи ничего не доходит, пока для порта прокси не включён переключатель Доступ из интернета, а роутеру или модему перед хостом нужен ещё и проброс порта. Окно «Поделиться ссылкой» в режиме Интернет предупреждает о причинах, которые может обнаружить, а в разделе Что переключатель открыть не может перечислены те, которые никакое правило на хосте с b4 не исправит.

Если строка ретрансляции есть, а Telegram всё равно ждёт, проблема выше по маршруту. Проверить соединение обращается к дата-центру 2 настроенными транспортами.

Telegram сообщает, что прокси настроен неверно, и выключает его​

[tg-bridge c=7] upstream answered -444 (invalid DC) for a DC 2 session: the route does not
end at the data center the client asked for, cutting it and ranking the route down

Сессия дошла до дата-центра, отличного от запрошенного клиентом, а оба клиента Telegram отвечают на единственный -444 отключением прокси. Клиент повторяет свой дата-центр внутри зашифрованного поля, которое b4 не может ни прочитать, ни исправить, поэтому виноват маршрут, а не настройка.

В WebSocket-мосте дата-центр часто определяется по адресу соединения, а не со слов клиента, как описано в разделе В какой дата-центр идёт сессия. Тогда -444 означает, что адрес отнесён не к тому дата-центру, и маршрут не понижается: следующие сессии на этот адрес идут в другой дата-центр той же площадки, а если его нет, мимо маршрутов к дата-центрам.

b4 гасит этот код, понижает маршрут в приоритете и даёт клиенту переподключиться по другому, поэтому единичный случай проходит сам. Череда таких строк для одного дата-центра означает, что все доступные для него маршруты заканчиваются не там, и лечится это добавлением ещё одного: домена Cloudflare Worker или своего WebSocket-домена.

Не загружаются медиа, стикеры или реакции​

Собственный WebSocket-узел Telegram обслуживает только дата-центры 2 и 4. Медиа зарубежных каналов приходит из 1, медиа несёт и 203, поэтому обоим нужен маршрут через Cloudflare. Закрывают их Домен Cloudflare Worker или оставленный включённым CF-резерв.

Клиент отклонён​

[tg-bridge c=4] proxy fake-TLS failed from 192.168.1.50:51234: HMAC verification failed for all secrets

Секрет в Telegram не совпадает ни с одним включённым секретом в b4. Секрет, запись которого выключена, даёт ту же строку.

[tg-bridge c=4] proxy fake-TLS failed from 192.168.1.50:51234: timestamp out of range: diff=214s

Часы клиента и хоста с b4 расходятся больше чем на две минуты. NTP нужен обоим.

Конфигурация, в которой выключены все секреты, пишет при старте secrets: 0 и закрывает каждое соединение сразу после приёма.

Верхняя сторона замолчала посреди сессии​

[tg-bridge c=9] upstream silent for 8s with 512 B awaiting an answer, cutting the relay

Маршрут принял две записи или больше и не ответил ни на одну: со второй прошло восемь секунд, с последней - три. Одиночная запись, на которую ответ не нужен, например подтверждение в простаивающей сессии, не считается. Считается и сессия, которую Telegram закрыл в течение шести секунд после запроса, пока маршрут молчал восемь. Так ведёт себя Cloudflare Worker, и b4 понижает его в приоритете на десять минут после двух таких сессий за пять минут.

Не удаётся подключиться​

[tg-bridge c=2] proxy dial DC 2 failed: dial tcp 149.154.167.51:443: i/o timeout
  • При прямом TCP без релея адреса дата-центров заблокированы по IP. Обходят это режимы Авто и Только WebSocket либо DC Relay.
  • При заданном DC Relay socat не запущен на VPS, порт не открыт в его файрволе или адрес релея неверен. Прямой TCP проверяет без релея и разделяет эти случаи.

Предупреждения на карточке Telegram через WebSocket​

Карточка в разделе Настройки, Telegram показывает Работает, когда правило перенаправления установлено, слушатель моста запущен и выше правила перенаправления нет правила другой программы, проверяющего локальные сокеты. Иначе она показывает Не работает, а подсказка на статусе называет, чего не хватает: слушателя, правила файрвола, которое направляет трафик Telegram в мост, или называет правило другой программы, стоящее выше. Причину называют предупреждения над блоком состояния. Первые четыре условия ниже не дают мосту ничего перенаправлять, остальные оставляют его работающим. Прочее содержимое карточки описано в справочнике по полям.

Нет поддержки TPROXY​

Предупреждение начинается словами «В этом ядре нет поддержки TPROXY». Мост работает через TPROXY, которому нужны модули ядра tproxy и socket. Без них b4 пишет в лог, что файрвол их не поддерживает, не устанавливает для переключателя правило перенаправления и оставляет Telegram на обычном пути, а карточка показывает Не работает. Предупреждение называет пакеты с недостающими модулями, а если пакеты неизвестны - сами модули; в OpenWrt это kmod-nft-tproxy и kmod-nft-socket, полный список - в разделе Маршрутизация, требования. Проверить снова повторяет проверку ядра после их установки и затем устанавливает правило. Тот же результат есть в окне Информация о системе в разделе Настройки, Система, Сервис, в разделе Возможности ядра: строка Прозрачный прокси (TPROXY) показывает, доступен он или нет.

Настройка файрвола отключена​

В разделе Настройки, Основные, Файрвол включено Пропустить настройку IPTables/NFTables; в конфигурации это system.tables.skip_setup, его же включает флаг --skip-tables. Тогда b4 при запуске не устанавливает никаких правил файрвола, в том числе правило перенаправления в мост, и после перезапуска ни одно соединение Telegram до слушающего сокета не доходит, что бы ни показывал переключатель. Сохранение настроек устанавливает правила маршрутизации до следующего перезапуска.

Слушающий сокет не запустился​

Предупреждение гласит «Слушатель моста на порту 13443 завершился с ошибкой» и приводит ошибку. Порт занять не удалось, например потому, что его уже слушает другой процесс. Порт фиксированный. b4 повторяет попытки и устанавливает правила перенаправления только после того, как сокет поднялся, поэтому до этого соединения Telegram идут обычным путём, а не в закрытый порт. Какой процесс держит порт, показывает netstat -ltnp на роутере, если сборка поддерживает -p.

Если не открылся только сокет IPv6, карточка вместо этого показывает замечание, что IPv4 идёт через мост, а Telegram по IPv6 идёт обычным путём. Замечание появляется только при включённой поддержке IPv6. Сокет IPv6 пробуется снова только при перезапуске слушающего сокета, например после перезапуска b4.

Правило другой программы стоит выше моста​

Статус показывает Не работает, а подсказка называет правило, например DIVERT. Другая программа поставила в mangle PREROUTING выше правила моста правило, которое принимает любой пакет к локальному прозрачному сокету; XrayUI добавляет такое при каждом запуске xray. Оно забирает пакеты соединений, которые перенаправил мост, поэтому их рукопожатие не завершается. При следующей проверке файрвола b4 возвращает своё правило выше и пишет в лог предупреждение с именем правила, а Проверить снова делает то же сразу. Пока мониторинг файрвола выключен, то есть интервал мониторинга равен 0 или в разделе Настройки, Основные, Файрвол включено Пропустить настройку IPTables/NFTables, проверок нет, и порядок восстанавливают только Проверить снова или сохранение настроек. Механизм описан в разделе b4 вместе с Xray или XrayUI.

Bridge netfilter включён для сетевого моста​

Предупреждение начинается со слов «Bridge netfilter включён для» и называет сетевые мосты. Когда net.bridge.bridge-nf-call-iptables равен 1 (на OpenWrt его выставляет пакет dockerd), соединения устройств за этими мостами не доходят до слушателя и зависают, а соединения самого роутера ретранслируются. Статус при этом остаётся Работает, потому что правило и слушатель на месте. Причина, способ выключения и его влияние на Docker описаны в разделе Bridge netfilter, а настройку, которую нужно изменить, называет строка Bridge netfilter раздела Firewall в окне Информация о системе (Настройки, Система, Сервис).

Не удалось скачать список адресов​

Предупреждение приводит ошибку скачивания и называет источник списка, который используется сейчас. Не ответили ни core.telegram.org, ни одно из зеркал b4. Используемый список остаётся, из какого бы источника он ни был взят, а встроенный список входит в него всегда. Следующая попытка идёт через 30 секунд, а после каждой новой неудачи пауза удваивается, но не больше часа; после успеха список обновляется раз в сутки. Обновить адреса повторяет попытку сразу.

b4 работает в режиме TUN​

С движком TUN мост не проверялся. Переключатель включить можно, а доходят ли соединения Telegram до слушающего сокета, видно по счётчику сессий на карточке и на странице Трафик, по имени сета Telegram bridge и метке Мост Telegram.

Есть сеты в режиме маршрутизации «Telegram через WebSocket»​

Предупреждение перечисляет эти сеты со ссылками на их редактор, выключенные помечены выключен. Пока переключатель включён, сет в режиме Telegram через WebSocket (встроенный) ничего не добавляет: переключатель и так направляет адреса Telegram со всех устройств в тот же мост. Сет, ограниченный устройствами или интерфейсами, по-прежнему первым забирает свои устройства, и они попадают в тот же мост. Кроме того, такой сет, если он не ограничен включающим списком исходных устройств, продолжает выводить собственные соединения моста к адресам Telegram из обработки DPI, чего один переключатель не делает; см. Обработка DPI.

Счётчики под состоянием моста​

Строка под блоком состояния появляется, когда хотя бы один из счётчиков больше нуля.

  • Передано без разбора считает соединения, которые не были MTProto, в том числе HTTPS к веб-хостам Telegram, и сессии MTProto, которые b4 не смог сопоставить с дата-центром. Они уходят в Cloudflare Worker или напрямую, поэтому растущий счётчик сам по себе не неисправность.
  • Ошибок подключения к дата-центру считает сессии MTProto, для которых не подключился ни один маршрут. В логе при этом есть bridge dial DC <n> failed на уровне error, не чаще раза за интервал для одного дата-центра. Причины из раздела Не удаётся подключиться подходят и здесь, кроме DC Relay, который мост не использует.
  • Закрыто без рукопожатия считает соединения, которые закрылись или молчали всё Ожидание рукопожатия в мосте, так и не прислав первый байт. Telegram открывает соединения к дата-центру заранее, ещё не имея данных для отправки, поэтому часть таких соединений ожидаема, а более короткое ожидание даёт их больше.

Часть трафика Telegram идёт мимо моста​

  • Голосовые звонки идут по UDP, а UDP мост не принимает.
  • QUIC не отклоняется, поэтому клиент, предпочитающий QUIC к адресу Telegram, обходит мост молча.
  • IPv6-диапазоны перенаправляются, только пока в разделе Настройки, Основные, Движок пакетов включена поддержка IPv6.
  • Устройства, исключённые фильтрацией устройств, остаются на обычном пути.
  • Сет, ограниченный устройствами или исходными интерфейсами, который совпадает с адресами Telegram, обрабатывает свои устройства раньше переключателя.
  • Адрес вне используемого списка не перенаправляется. Карточка показывает, сколько диапазонов используется и откуда они взяты.

Сет блокировки останавливает мост​

Сет блокировки, не ограниченный исходными интерфейсами или включающим списком исходных устройств, цели которого покрывают адреса Telegram, по-прежнему блокирует соединения самого роутера к ним, а собственные исходящие соединения моста - это соединения роутера. Сессии через мост тогда не могут подключиться ни к одному адресу, который покрывает сет блокировки.

Сет в режиме «Telegram через WebSocket» ничего не перенаправляет​

У режима сета то же требование к TPROXY, что и у переключателя, см. Нет поддержки TPROXY.

Сопоставление тоже должно происходить: сету нужна GeoIP-категория telegram и настроенная база GeoIP, а сет, в котором категория указана при пустом пути к базе, отклоняется при сохранении, а не работает вхолостую. Сет, ограниченный исходными интерфейсами или устройствами, не захватывает соединения самого роутера, в том числе Telegram Desktop на роутере.

Устройства за сетевым мостом висят, а Telegram на самом роутере работает​

При включённом bridge netfilter соединения, которые входят через сетевой мост вроде br-lan, не доходят до слушателя b4. Telegram на устройствах за ним висит на «Подключение», и строк [tg-bridge] для них в логе нет, тогда как соединения самого роутера, в том числе те, что SOCKS5-сервер b4 открывает для своих клиентов, ретранслируются как обычно. Сеты в режиме «Вышестоящий прокси SOCKS5» затронуты точно так же. Причина и настройки, которые её убирают, описаны в разделе Bridge netfilter.

На хосте WEB-прокси открывается страница-заглушка​

Этой страницей релей отвечает на всё, что не распознал, и ни один из таких случаев не логируется: несовпавший хост, отсутствующий или неверный токен, истёкший тикет, обычный GET вместо WebSocket-апгрейда или достигнутый предел каналов.

Подтверждение приходит из лога:

[tg-bridge] web carrier up from 203.0.113.9 (secret=desktop)
[tg-bridge] web proxy new stream 1 from 203.0.113.9

Если ни одной такой строки не появляется, стоит пройти по предварительным условиям: MTProto-прокси должен быть включён, его слушающий сокет - подняться, веб-сервер - работать или порт релея - быть задан, хост - доходить до b4 по доверенному TLS на 443 с сохранённым заголовком Host, а ссылка - быть из окна «Поделиться ссылкой», а не собранной вручную.