MTProto Proxy на TeleMT (Production Guide)

Установка и настройка telemt: практический гайд

~~Для кого:~~ системные администраторы и DevOps-инженеры, которые хотят поднять собственный MTProxy-совместимый прокси для Telegram с поддержкой TLS-fronting.
~~Версия на момент написания:~~ ~~3.3.27 / 3.3.28~~
~~ОС:~~ ~~Debian 12 / Ubuntu 22.04+ (x86_64 или arm64)~~

Содержание

~~Что такое telemt и зачем он нужен~~ ~~Архитектура и ключевые понятия~~ ~~Подготовка сервера~~ ~~Установка бинарника~~ ~~Конфигурация~~ ~~Systemd unit~~ ~~Фаервол~~ ~~Запуск и проверка~~ ~~Получение ссылок через API~~ ~~Работа с несколькими TLS-доменами~~ ~~Типичные ошибки и их диагностика~~ ~~Ограничения и известные баги~~

1. Что такое telemt и зачем он нужен

telemt — это современная альтернатива mtg и официальному MTProxy, написанная с упором на устойчивость к DPI и гибкость конфигурации. Ключевые особенности:

Поддержка TLS-fronting: исходящий трафик выглядит как обычный HTTPS-запрос к легитимному домену. Встроенный HTTP API для получения ссылок и управления пользователями. Метрики (Prometheus-совместимые) на отдельном порту. Поддержка нескольких SNI-доменов одновременно для генерации множества tg:// ссылок. Нативный бинарник — без зависимостей, без рантаймов.

2. Архитектура и ключевые понятия

Перед настройкой важно понять несколько концептов — иначе легко получить нерабочую конфигурацию.

public_host vs tls_domain

Это разные вещи с разными функциями:

Параметр

Что делает

Куда смотрит

public_host

Имя сервера в генерируемых

tg://

ссылках

Ваш домен / IP

tls_domain

SNI-домен для fake TLS handshake (fronting)

Внешний HTTPS-сайт, не ваш

Критическая ошибка-ловушка: если поставить один и тот же домен в public_host и tls_domain, а этот домен указывает на тот же сервер, где работает telemt, — возникает петля самофронтинга. Прокси будет пытаться проксировать сам себя вместо внешнего upstream-хоста.

Схема работы TLS-fronting

Клиент → [443/tcp] → telemt
                         ↓
             TLS SNI = www.example-cdn.com   ← это tls_domain
                         ↓
             Upstream: реальный HTTPS сайт (не ваш сервер)

Клиент видит трафик, направленный на легитимный HTTPS-домен. Интерпретация снаружи: «пользователь ходит на www.example-cdn.com».

3. Подготовка сервера

Требования

Чистый VPS/DS с публичным IP Открытый порт (рекомендуется 7443/tcp, также подходит 443/tcp) root или возможность работы через sudo Ваш домен должен иметь A-запись, указывающую на IP сервера

Установка зависимостей

apt-get update && apt-get install -y wget curl jq openssl ufw

Проверка DNS

Убедитесь, что домен резолвится в нужный IP:

dig +short A proxy.example.com
# Ожидаемый вывод: 203.0.113.10   (ваш IP)

4. Установка бинарника

telemt распространяется как статически скомпилированный бинарник — никаких зависимостей от интерпретаторов или рантаймов.

cd /tmp

# Скачиваем и распаковываем последний релиз (автоопределение архитектуры и libc)
wget -qO- "https://github.com/telemt/telemt/releases/latest/download/telemt-$(uname -m)-linux-$(ldd --version 2>&1 | grep -iq musl && echo musl || echo gnu).tar.gz" | tar -xz

# Устанавливаем в /bin
install -m 0755 telemt /bin/telemt

# Проверяем
/bin/telemt --version

Версия: на момент написания стабильная ветка — 3.3.27/3.3.28. Для продакшн-узла нет смысла бежать за самым свежим релизом в первый день выхода. Проверяйте страницу релизов.

5. Конфигурация

Создаём директории и секрет

mkdir -p /etc/telemt /opt/telemt

# Генерируем случайный секрет (32 hex-символа)
SECRET_MAIN="$(openssl rand -hex 16)"
echo "Ваш секрет: $SECRET_MAIN"
# Сохраните это значение — оно понадобится при написании конфига

Полный конфиг `/etc/telemt/telemt.toml`

cat > /etc/telemt/telemt.toml <<'EOF'
[general]
use_middle_proxy = true

[general.links]
show = "*"
public_host = "proxy.example.com"   # ← ваш домен для ссылок
public_port = 7443

[general.modes]
classic = false
secure = false
tls = true

[server]
port = 7443
metrics_port = 9090
metrics_whitelist = ["127.0.0.1/32", "::1/128"]

[server.api]
enabled = true
listen = "127.0.0.1:9091"
whitelist = ["127.0.0.1/32"]

[[server.listeners]]
ip = "0.0.0.0"

[censorship]
tls_domain = "www.microsoft.com"    # ← внешний HTTPS-сайт, НЕ ваш домен
mask = true
tls_emulation = true
tls_front_dir = "/opt/telemt/tlsfront"

[access.users]
main = "ВСТАВЬТЕ_СЮДА_СЕКРЕТ"
EOF

После этого вставьте реальный секрет:

sed -i "s/ВСТАВЬТЕ_СЮДА_СЕКРЕТ/$SECRET_MAIN/" /etc/telemt/telemt.toml

Пояснения к параметрам

Параметр

Значение

Зачем

public_host

proxy.example.com

Домен в

tg://

ссылках — ваш

public_port

7443

Порт в ссылках — совпадает с

server.port

7443

Реальный порт прослушивания

tls_domain

www.microsoft.com

Fake SNI —

чужой

внешний HTTPS-сайт

server.api.listen

127.0.0.1:9091

API только на loopback — не светим наружу

metrics_port

9090

Метрики тоже только для

127.0.0.1

mask

true

Включить traffic masking

tls_emulation

true

Эмулировать TLS handshake целевого домена

Выбор tls_domain

Правило простое и важнее конкретного имени:

домен должен быть реальным HTTPS-сайтом он не должен указывать на ваш IP должен быть доступен из сетей клиентов должен выглядеть поведенчески правдоподобно для геолокации вашего сервера

Хорошие кандидаты для старта (протестируйте по одному):

tls_domain = "www.microsoft.com"
# или
tls_domain = "www.apple.com"
# или
tls_domain = "www.bing.com"

6. Systemd unit

# Создаём системного пользователя
useradd -d /opt/telemt -m -r -U telemt 2>/dev/null || true
chown -R telemt:telemt /etc/telemt /opt/telemt

# Unit-файл
cat > /etc/systemd/system/telemt.service <<'EOF'
[Unit]
Description=telemt MTProxy
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=telemt
Group=telemt
WorkingDirectory=/opt/telemt
ExecStart=/bin/telemt /etc/telemt/telemt.toml
Restart=on-failure
RestartSec=5

# Без этого получите "Too many open files" при нагрузке
LimitNOFILE=65536

# Нужен для прослушивания портов < 1024 (если используете 443)
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now telemt

Почему LimitNOFILE=65536? При большом количестве одновременных подключений Linux исчерпывает лимит открытых файловых дескрипторов. telemt предупреждает об этом в документации — это не украшательство, а обязательный параметр для продакшна.

7. Фаервол

# Открываем порт прокси
ufw allow 7443/tcp

# API (9091) и метрики (9090) наружу НЕ открываем — они на loopback
# Если ранее открывали 443, закрываем
# ufw delete allow 443/tcp

# Проверяем
ufw status verbose

Что не открывать наружу: порты 9091 (API) и 9090 (метрики). Оба сервиса по умолчанию слушают только 127.0.0.1 — не меняйте это без необходимости.

8. Запуск и проверка

Статус сервиса

systemctl status telemt --no-pager -l
journalctl -u telemt -n 100 --no-pager

Проверка портов

# Прокси слушает снаружи
ss -ltnp | grep ':7443 '

# API только на loopback
ss -ltnp | grep ':9091 '

# Метрики только на loopback
ss -ltnp | grep ':9090 '

Ожидаемый вывод для прокси-порта:

LISTEN  0  128  0.0.0.0:7443  0.0.0.0:*  users:(("telemt",...))

Проверка DNS

dig +short A proxy.example.com
# Должен вернуть IP вашего сервера

9. Получение ссылок через API

telemt генерирует tg:// ссылки через локальный HTTP API. Для каждой комбинации public_host + tls_domain создаётся отдельная ссылка.

curl -s http://127.0.0.1:9091/v1/users | jq

Пример вывода:

{
  "users": {
    "main": {
      "links": {
        "tls": [
          "tg://proxy?server=proxy.example.com&port=7443&secret=ee..."
        ]
      }
    }
  }
}

Ссылку вида tg://proxy?server=proxy.example.com&port=7443&secret=ee... можно передавать пользователям напрямую или публиковать в Telegram-канале.

10. Работа с несколькими TLS-доменами

Если хотите сравнить стабильность разных SNI-доменов, telemt поддерживает параметр tls_domains (массив).

Конфиг с несколькими доменами

[censorship]
tls_domain = "www.microsoft.com"
tls_domains = ["www.apple.com", "www.bing.com"]
mask = true
tls_emulation = true
tls_front_dir = "/opt/telemt/tlsfront"

API вернёт несколько ссылок — по одной на каждый домен. Они будут отличаться значением secret= (в нём закодирован SNI-домен).

11. Типичные ошибки и их диагностика

telemt не запускается

journalctl -u telemt -n 50 --no-pager

Частые причины:

Порт занят. Проверьте: ss -ltnp | grep ':7443 ' Ошибка в TOML. Проверьте синтаксис конфига вручную. Нет прав на порт < 1024. Если используете 443 без CAP_NET_BIND_SERVICE.

API не отвечает

curl -v http://127.0.0.1:9091/v1/users

Проверьте, что в конфиге:

[server.api]
enabled = true
listen = "127.0.0.1:9091"

И что сервис запущен: systemctl is-active telemt

Ссылки не работают у клиентов

Проверьте, что proxy.example.com резолвится в IP сервера. Проверьте, что порт 7443 открыт снаружи: ufw status verbose Проверьте, что public_host и public_port в конфиге совпадают с тем, что в ссылке. Убедитесь, что tls_domain — это внешний домен, не ваш.

Ошибка "Too many open files"

В systemd unit обязателен параметр:

LimitNOFILE=65536

После добавления: systemctl daemon-reload && systemctl restart telemt

Самофронтинг (петля)

Симптом: telemt запускается, но соединения зависают или сразу рвутся.

Причина: tls_domain указывает на тот же IP, что и ваш сервер.

Решение: замените tls_domain на настоящий внешний HTTPS-сайт.

Проверка:

# tls_domain из конфига
dig +short A www.microsoft.com

# IP вашего сервера
curl -s ifconfig.me

# Они НЕ должны совпадать

12. Ограничения и известные баги

Проблемы с iOS-клиентами

У части пользователей официального Telegram-клиента на iPhone наблюдались проблемы с отправкой фотографий через telemt, тогда как через mtg фото уходили нормально. Если у вас много iOS-клиентов — держите mtg как запасной вариант.

Нет привязки ссылки к конкретному SNI

API возвращает массив tls ссылок, но не указывает явно, какая ссылка соответствует какому tls_domain. Определить это можно только экспериментально или по порядку в массиве (совпадает с порядком в конфиге).

API не размечает ссылки по домену

Если вам критично знать соответствие «ссылка → SNI», пока это нужно отслеживать вручную — документация по API не даёт такой маркировки.

Итог: минимальная рабочая схема

Клиент → proxy.example.com:7443 → telemt
                                       ↓ fake TLS SNI: www.microsoft.com
                                   upstream HTTPS

proxy.example.com — только public_host (имя в ссылках) www.microsoft.com — только tls_domain (fake fronting, не ваш) API на 127.0.0.1:9091 — не светить наружу Метрики на 127.0.0.1:9090 — тоже только локально LimitNOFILE=65536 в systemd — обязательно

Гайд написан на основе официальной документации telemt: CONFIG_PARAMS, QUICK_START_GUIDE, API, FAQ.

MTProto Proxy на TeleMT (Production Guide)

Установка и настройка telemt: практический гайд

Содержание

1. Что такое telemt и зачем он нужен

2. Архитектура и ключевые понятия

public_host vs tls_domain

Схема работы TLS-fronting

3. Подготовка сервера

Требования

Установка зависимостей

Проверка DNS

4. Установка бинарника

5. Конфигурация

Создаём директории и секрет

Полный конфиг /etc/telemt/telemt.toml

Пояснения к параметрам

Выбор tls_domain

6. Systemd unit

7. Фаервол

8. Запуск и проверка

Статус сервиса

Проверка портов

Проверка DNS

9. Получение ссылок через API

10. Работа с несколькими TLS-доменами

Конфиг с несколькими доменами

Рекомендуемая стратегия

11. Типичные ошибки и их диагностика

telemt не запускается

API не отвечает

Ссылки не работают у клиентов

Ошибка "Too many open files"

Самофронтинг (петля)

12. Ограничения и известные баги

Проблемы с iOS-клиентами

Нет привязки ссылки к конкретному SNI

API не размечает ссылки по домену

Итог: минимальная рабочая схема

Полный конфиг `/etc/telemt/telemt.toml`