https://pastein.ru/t/Haq
Загрузка данных
Исследование архитектуры и реализаций MTProto-прокси для высоконагруженных коммерческих систем в условиях глубокого анализа трафика (Май 2026 года)В условиях непрерывной эскалации методов сетевой цензуры и повсеместного внедрения Технических средств противодействия угрозам (ТСПУ) на сетях магистральных операторов связи в Российской Федерации к маю 2026 года, классические протоколы туннелирования и проксирования подвергаются агрессивной деградации и блокировкам. Системы глубокого анализа пакетов (Deep Packet Inspection, DPI) нового поколения используют комплексный подход, включающий сигнатурный анализ, поведенческую эвристику, активное зондирование (active probing) серверов и семантическую фильтрацию по полю Server Name Indication (SNI) в рамках установления криптографических сессий. В связи с этим коммерческая эксплуатация прокси-сервисов для мессенджера Telegram требует внедрения изощренных архитектурных решений, обеспечивающих не только математически надежную криптографическую маскировку транзитного трафика, но и высокую отказоустойчивость, строгую изоляцию пользователей на уровне конфигурации и возможность динамического управления параметрами без разрыва уже установленных сессий (hot reload).Данное исследование представляет собой исчерпывающий концептуальный и технический анализ подходов к построению инфраструктуры коммерческого Telegram-бота для продажи доступа к MTProto-прокси. Заданный контекст предполагает обслуживание клиентской базы объемом от 200 до 500 и более активных пользователей на единственном вычислительном узле с выделенным IPv4-адресом и портом (144.31.251.236:1443) под управлением операционной системы Debian. Жесткие эксплуатационные требования диктуют необходимость генерации уникальных секретов для каждого отдельного пользователя на базе единого прокси-демона с обязательной маскировкой трафика по протоколу Fake TLS под легитимный домен amazonws.com. Инфраструктура биллинга, управления жизненным циклом подписок и генерации конфигураций базируется на современном стеке, включающем язык программирования Python 3.11, асинхронный фреймворк aiogram и встроенную систему управления базами данных SQLite. В рамках данного отчета проводится глубокое исследование и сравнительный анализ ведущих программных реализаций прокси-серверов (на языках Erlang, Go, C и Zig), архитектурных паттернов TCP-мультиплексирования на базе балансировщика HAProxy, криптографических методов генерации совместимых секретов в среде Python, систем мониторинга соединений с детализацией по отдельным секретам, а также профилирования производительности сетевого стека под высокой конкурентной нагрузкой.Эволюция протокола MTProto и механизмы обхода DPI в 2026 годуДля понимания архитектурных требований к современному прокси-серверу необходимо проанализировать эволюцию самого протокола MTProto и методы, применяемые цензорами для его подавления. Исторически первые версии MTProto-прокси использовали базовые методы криптографической обфускации, такие как Abridged или Intermediate транспорты, а также специализированные dd-секреты. Данные секреты инициировали режим, в котором клиент и сервер искусственно рандомизировали размеры передаваемых TCP-пакетов, добавляя паддинг для того, чтобы предотвратить обнаружение протокола по сигнатурам длин характерных пакетов. Однако современные комплексы ТСПУ, обладая значительными вычислительными мощностями для анализа состояний потоков (stateful inspection), научились выявлять высокую математическую энтропию зашифрованного потока, не соответствующего известным профилям легитимного веб-трафика, и классифицировать такие соединения как аномальные.В ответ на эти вызовы индустрия обхода блокировок стандартизировала протокол Fake TLS, который инкапсулирует полезную нагрузку мессенджера Telegram в структуру, визуально и поведенчески идентичную сессии TLS версии 1.3 поверх протокола HTTP/2. Функционирование механизма Fake TLS начинается с того, что клиентское приложение отправляет первоначальный пакет ClientHello, содержащий открытое поле SNI (Server Name Indication) целевого домена маскировки, в заданном сценарии — amazonws.com. Прокси-сервер принимает данный пакет, извлекает из него криптографический секрет, проверяет его валидность и, в случае криптографического успеха, устанавливает подключение к официальным дата-центрам (DC) Telegram, выступая в роли транзитного узла.Критически важным аспектом является поведение сервера при получении невалидного запроса. Если секрет неверен, отсутствует, или подключение инициировано сканером цензора (так называемым активным зондом, например, системой Revisor), прокси-система не должна просто сбрасывать соединение, так как закрытый порт или нестандартная ошибка немедленно выдадут истинное предназначение узла. Вместо этого современные реализации используют технологию Domain Fronting или маршрутизацию на локальный веб-сервер (режим Zero-RTT) для прозрачной имитации поведения реального балансировщика или веб-сервера Amazon. Это заставляет систему DPI поверить в то, что по данному IP-адресу действительно располагается легитимный корпоративный ресурс, что нивелирует угрозу активного зондирования и последующей блокировки по IP.Для коммерческого сервиса, рассчитанного на обслуживание сотен пользователей, критически важно обеспечить строгую логическую изоляцию клиентов друг от друга на уровне конфигурации. Компрометация публичного IP-адреса и порта может привести к блокировке всего сервиса, что означает катастрофические финансовые и репутационные потери. Использование единого разделяемого секрета для всех клиентов недопустимо: при публикации такого секрета в публичном пространстве (утечка) к узлу подключатся тысячи неавторизованных пользователей, что приведет к исчерпанию пула файловых дескрипторов операционной системы и отказу в обслуживании (Denial of Service) для легитимных подписчиков. Следовательно, каждый клиент должен получать уникальный криптографический токен, привязанный к его внутреннему идентификатору в биллинговой системе. Данный подход позволяет биллинговой системе на базе Python точечно и атомарно отключать неплательщиков путем удаления их индивидуального секрета из конфигурации демона в оперативной памяти, не оказывая деструктивного воздействия на соединения остальной клиентской базы.Архитектурный и концептуальный анализ реализаций MTProto-демоновВыбор оптимального вычислительного ядра (демона) для обработки сетевых соединений определяет общую стабильность, масштабируемость и гибкость всей системы продажи прокси. Индустрия предлагает несколько фундаментально различающихся подходов к реализации MTProto-сервера. В рамках данного отчета мы подвергнем глубокому анализу четыре основные реализации: официальную эталонную версию на языке C, высококонкурентную модель на языке Erlang, современные микросервисные подходы на Go и новейшие низкоуровневые реализации на языке Zig, оценивая их архитектурные особенности, механизмы поддержки множества секретов и встроенные возможности динамической перезагрузки конфигурации.Эталонная реализация на языке C (Официальный MTProxy)Оригинальная реализация программного обеспечения, известная как TelegramMessenger/MTProxy и написанная на системном языке программирования C, долгое время являлась стандартом де-факто для развертывания публичных узлов. С точки зрения архитектуры, данная программа использует классическую многопоточную модель обработки событий, опираясь на системные вызовы epoll ядра Linux, и требует ручного управления запуском нескольких рабочих процессов (workers) в зависимости от доступного количества аппаратных ядер процессора для параллелизации вычислений.Поддержка множества секретов в данной реализации существует, однако она реализована на рудиментарном уровне. Архитектура допускает указание множественных криптографических ключей исключительно через аргументы командной строки при инициализации процесса, что выглядит как последовательность флагов вида -S <secret1> -S <secret2> -S <secret3>. Для коммерческого бота с целевой аудиторией в 500 и более пользователей этот метод признается архитектурно непригодным. Оператору потребуется формирование гигантской строки запуска, выходящей за рамки ограничений оболочки ОС, или использование сложных и хрупких сценариев systemd для построчного парсинга конфигурационных файлов перед стартом процесса. Управление соединениями в C-реализации отличается высокой пропускной способностью; процесс способен эффективно обслуживать до 12 000 активных пользователей на виртуальном сервере с 4 процессорными ядрами благодаря минимальным накладным расходам на уровне машинного кода.Тем не менее, фундаментальным и неустранимым недостатком официальной реализации является полное отсутствие механизма Hot Reload (горячей перезагрузки конфигурации). Любое изменение параметров, будь то добавление нового подписчика или отзыв скомпрометированного секрета, требует жесткого терминирования процесса и его последующего перезапуска (например, через команду systemctl restart mtproto-proxy или пересоздание Docker-контейнера). Процесс реинициализации занимает порядка семи секунд, в течение которых сервер отклоняет все входящие соединения, и приводит к немедленному обрыву всех активных сессий уже подключенных пользователей. В контексте платного коммерческого сервиса регулярные сбросы подключений (которые при 500 пользователях могут происходить каждые несколько минут по мере покупки или истечения подписок) вызовут массовое недовольство клиентов и шквал обращений в службу технической поддержки, что делает официальную реализацию на C абсолютно непригодной для современной эксплуатации в сценариях с частой ротацией пользовательской базы.Высококонкурентная реализация на языке Erlang (seriyps/mtproto_proxy)Альтернативный подход представлен реализацией seriyps/mtproto_proxy, которая является одной из самых зрелых, архитектурно совершенных и масштабируемых систем для высоконагруженных транзитных узлов. Использование виртуальной машины BEAM, лежащей в основе среды выполнения Erlang/OTP, обеспечивает исключительную изоляцию процессов на основе математической модели акторов, гарантируя высочайшую отказоустойчивость. Согласно нагрузочным тестам, данный демон способен обрабатывать до 90 000 одновременных соединений на стандартном облачном сервере с 4 ядрами и 8 ГБ оперативной памяти при устойчивой пропускной способности в 1 Гбит/с.Ключевым преимуществом Erlang-версии является нативная поддержка мультиплексирования сессий: прокси-сервер алгоритмически заворачивает огромное множество входящих клиентских подключений в небольшое, строго контролируемое число TCP-каналов, идущих непосредственно до серверов Telegram. Это радикально снижает сетевые задержки (ping), оптимизирует маршрутизацию и минимизирует расход файловых дескрипторов на уровне операционной системы.С точки зрения управления доступом и множественными секретами, Erlang-реализация поддерживает запуск множества независимых обработчиков на разных портах. Однако в жестких рамках нашего сценария (единый IP-адрес 144.31.251.236 и единственный порт 1443) система предлагает уникальную криптографическую концепцию «Per-SNI derived secrets» (производные секреты на базе домена SNI). При активации данного режима в конфигурации ({per_sni_secrets, on}) базовый секрет сервера смешивается с приватной серверной солью (например, {per_sni_secret_salt, <<"mtproto-proxy-per-sni-v1">>}) и уникальным SNI-доменом пользователя посредством криптографической хеш-функции: SHA256(salt | hex(base_secret) | sni_domain)[0:16]. Благодаря этой трансляции пользователи не могут извлечь корневой базовый секрет из своих tg://-ссылок. Возникает, однако, архитектурное противоречие с исходными требованиями: наш контекст предполагает использование строго одного домена маскировки amazonws.com для всех пользователей (чтобы мимикрировать под единый сервис), но с разными уникальными секретами. В парадигме Erlang-реализации производные секреты требуют, чтобы каждый пользователь имел свой уникальный SNI-домен (например, user1.amazonws.com, user2.amazonws.com), что усложняет конфигурацию и управление так называемыми белыми списками (whitelists) разрешенных доменов. В классическом режиме, когда всем выдается один FakeTLS-домен, Erlang-сервер предполагает использование одного секрета на порт, что делает управление 500 индивидуальными секретами на одном порту практически нереализуемым без переписывания исходного кода демона.Что касается механизма Hot Reload, Erlang демонстрирует свое абсолютное превосходство. Файл конфигурации sys.config можно обновлять на лету с помощью утилиты командной строки, инициирующей вызов mtp_proxy rpcterms mtproto_proxy_app reload_config. Соединения пользователей при этом не разрываются. Более того, конфигурация политик безопасности может изменяться атомарно путем инъекции Erlang-выражений напрямую в работающую виртуальную машину: mtp_proxy eval 'mtp_policy_table:add(personal_domains, tls_domain, "amazonws.com").'. Несмотря на эти феноменальные возможности, существенным недостатком реализации является высокий порог входа в специфичную экосистему Erlang/OTP и сложность синтаксиса файлов sys.config, что, по опыту разработчиков, часто приводит к фатальным ошибкам парсинга при автоматизированной генерации файлов со стороны Python-бота.Микросервисная реализация на языке Go (mtg и форк dolonet/mtg-multi)Проект 9seconds/mtg, написанный на языке Go, создавался как ответ на избыточную сложность Erlang-версии. Оригинальный дизайн следовал принципу строгого минимализма и намеренного отказа от управления пользователями, поддерживая концептуально только один секрет на один инстанс прокси-сервера. Однако требования рынка привели к появлению специализированного форка dolonet/mtg-multi, который полностью решает проблему изоляции клиентов, внедряя продвинутую подсистему управления аккаунтами, сбора статистики и контроля лимитов пропускной способности.В архитектуре mtg-multi управление множественными секретами осуществляется через интуитивно понятный и легко парсируемый формат файлов конфигурации TOML. В глобальной области видимости конфигурационного файла выделяется секция [secrets], где каждому пользователю (или идентификатору в биллинговой системе) назначается уникальный шестнадцатеричный FakeTLS-токен. Важнейшим преимуществом является то, что все эти токены могут абсолютно легитимно использовать один и тот же hostname для маскировки (в нашем случае — amazonws.com). Язык Go, обладая мощными встроенными механизмами работы с хэш-таблицами (maps), валидирует входящее соединение за время O(1), сопоставляя криптографическую подпись с загруженным в память пулом ключей.Защита от перегрузок (Throttling) в mtg-multi заслуживает отдельного внимания, так как она критически важна для предотвращения оверселлинга. Демон интегрирует проактивный алгоритм честного распределения ресурсов (fair-share throttling). Фоновая горутина каждые несколько секунд (интервал задается параметром check-interval) анализирует состояние сетевых сокетов и пересчитывает лимиты соединений для всех пользователей. Клиенты с низким потреблением (совершающие базовый обмен текстовыми сообщениями) беспрепятственно сохраняют свои сессии, в то время как оставшийся бюджет пула соединений делится строго поровну между интенсивными потребителями (например, пользователями, скачивающими тяжелые видеофайлы). Принципиально важно, что новые соединения от пользователей, превысивших свой динамический лимит, отклоняются на этапе хэндшейка, но уже установленные активные сессии не уничтожаются, обеспечивая плавную деградацию сервиса без обрывов.Кроме того, система обладает мощным механизмом анти-цензуры: она полностью поддерживает Domain Fronting и специализированную функцию Doppelganger. Если система DPI или активный зонд пытается просканировать сервер невалидным запросом, прокси не просто перенаправляет запрос на целевой домен, но и мимикрирует под оригинальный сайт на уровне поведения, отдавая ответы, побайтово идентичные ответам реального ресурса. Обновление TOML-конфигурации (Hot Reload) осуществляется отправкой POSIX-сигнала без остановки основного сетевого слушателя, что позволяет Python-скрипту добавлять и удалять клиентов в режиме реального времени.Низкоуровневая реализация на языке Zig (sleep3r/mtproto.zig)Новейшим достижением в области разработки прокси-серверов на рубеже 2024–2026 годов является высокопроизводительный демон, написанный на современном компилируемом языке Zig. Архитектура данного решения (sleep3r/mtproto.zig) строится вокруг парадигмы максимальной эффективности, исключающей использование сборщика мусора (Garbage Collector, GC) и динамической аллокации памяти в процессе штатной работы. За счет предварительного выделения памяти под пулы соединений и буферы при старте, демон полностью нивелирует скачки задержек (latency spikes), характерные для реализаций на языках с автоматическим управлением памятью (таких как Go). Использование механизмов вычислений на этапе компиляции (Comptime) позволяет разрешать сложнейшие протокольные преобразования до формирования бинарного файла, в результате чего размер исполняемого файла составляет микроскопические 177 КБ, скорость загрузки не превышает 10 миллисекунд, а потребление оперативной памяти на холостом ходу держится на отметке менее 1 МБ.Методы обхода комплексов ТСПУ (DPI evasion), заложенные в ядро Zig-демона, являются наиболее передовыми и агрессивными из всех представленных. Система реализует динамическое изменение размеров TLS-записей (Dynamic Record Sizing, DRS), варьируя размер пакетов от 1369 до 16384 байт, чтобы с математической точностью имитировать сетевые паттерны популярных веб-браузеров Chrome и Firefox. Встроенная фрагментация на уровне транспортного протокола (правило TCPMSS=88) разбивает первичный пакет TLS ClientHello на шесть отдельных TCP-сегментов, успешно разрушая логику систем реассемблирования ТСПУ, пытающихся собрать пакет воедино для сигнатурного анализа. Дополнительно применяется десинхронизация TCP с использованием утилиты nfqws, отправляющая ложные пакеты с ограниченным временем жизни (TTL-limited splits) для запутывания анализаторов состояния цензора.С точки зрения управления пользователями, Zig-реализация обеспечивает нативную поддержку мультиаккаунтов с высочайшей степенью изоляции. В конфигурационном файле config.toml присутствует секция [access.users], где логин каждого клиента строго сопоставляется с его индивидуальным 32-символьным шестнадцатеричным секретом. Для нужд администрирования или предоставления премиальных услуг предусмотрен блок [access.direct_users], который пускает трафик избранных пользователей напрямую в дата-центры Telegram, минуя режим трансляции MiddleProxy, что минимизирует пинг. Однако документация подчеркивает критический архитектурный нюанс: отключение MiddleProxy для обычных (не-Premium) аккаунтов Telegram приведет к невозможности загрузки медиафайлов (фото, видео, историй), так как без ретрансляции метаданных через MiddleProxy серверы Telegram классифицируют такие медиа-запросы как недоступные.Автоматизация жизненного цикла сервера и управление Hot Reload обеспечиваются встроенной нативной утилитой mtbuddy. Для применения обновленного списка секретов биллинговому боту достаточно перезаписать файл config.toml и инициировать отправку сигнала SIGHUP (например, через системный вызов systemctl reload mtproto-proxy). Перезагрузка параметров происходит бесшовно; при этом в настройках можно тонко регулировать тайм-ауты плавного завершения устаревших сессий (параметр graceful_shutdown_timeout_sec), что гарантирует отсутствие обрывов у легитимных клиентов.Архитектурная характеристикаC (Официальный MTProxy)Erlang (seriyps)Go (mtg-multi)Zig (mtproto.zig)Управление памятьюРучное (malloc/free)Виртуальная машина (BEAM)Сборщик мусора (GC)Преаллокация (отсутствие GC)Базовое потребление ОЗУНизкоеВысокое (от 100 МБ)Среднее (зависит от нагрузки)Ультра-низкое (< 1 МБ)Поддержка Hot ReloadОтсутствует (сброс сессий)Идеальная (инъекции кода RPC)Полная (перезагрузка TOML)Полная (SIGHUP валидация)Изоляция секретов пользователейАргументы командной строки CLIХеширование Per-SNI / WhitelistsНативная таблица в файле TOMLНативная таблица в файле TOMLУстойчивость к активным зондам ТСПУБазовый редиректОтличная (Domain Fronting)Отличная (Функция Doppelganger)Исключительная (Zero-RTT Nginx)Система мониторинга и сбора метрикЛокальный порт статистикиЭкспортеры метрик / PrometheusREST API (JSON) эндпоинт /statsPrometheus /metrics / Web ДашбордАнализируя представленные данные, можно утверждать, что для стека на базе Debian Linux и Python 3.11 оптимальным выбором инфраструктурного ядра по состоянию на май 2026 года является реализация на языке Zig (sleep3r/mtproto.zig) или специализированный форк на Go (dolonet/mtg-multi). Zig демонстрирует неоспоримое технологическое превосходство в части встроенных низкоуровневых механизмов обхода ТСПУ на сетевом уровне (фрагментация TCPMSS, десинхронизация), тогда как Go-форк предлагает непревзойденную систему балансировки пропускной способности (алгоритмы fair-share throttling) и удобный REST API для интеграции с биллингом. В дальнейшем повествовании мы будем рассматривать архитектуру, позволяющую бесшовно внедрить любую из этих двух современных платформ.Проектирование топологии: L4-маршрутизация и HAProxyТехническое задание накладывает строгие ограничения на сетевую топологию: инфраструктура располагает единственным публичным IPv4-адресом 144.31.251.236 и единственным доступным для клиентов портом 1443. В реалиях глубокого пакетного инспектирования и активного поиска аномалий со стороны цензоров, просто запустить прокси-демон на публичном порту — значит подвергнуть узел неминуемой блокировке. Сканеры систем цензуры осуществляют так называемое активное зондирование (active probing), подключаясь к подозрительным портам с использованием легитимных или модифицированных TLS-клиентов. Если сервер на порту 1443 не ответит корректным сертификатом для домена amazonws.com или вернет нестандартную сетевую ошибку, алгоритмы машинного обучения ТСПУ классифицируют IP-адрес как узел обхода блокировок и заблокируют его на магистральном уровне.Следовательно, на границе сети (на порту 1443) должен располагаться высокопроизводительный мультиплексор и маршрутизатор 4-го уровня модели OSI (транспортный уровень L4), способный с филигранной точностью отличать маскированный трафик Telegram (содержащий специфические структуры данных) от обычных проверочных HTTPS-соединений сканеров. И делать это он должен без расшифровки самого протокола TLS, так как приватный криптографический ключ от настоящего домена amazonws.com на нашем сервере отсутствует.Программный балансировщик нагрузки HAProxy признан индустриальным стандартом для решения подобных задач маршрутизации. Он обладает встроенными механизмами извлечения метаданных из незашифрованного стартового пакета ClientHello в процессе установления TLS-рукопожатия (конкретно, поля Server Name Indication, SNI), что позволяет прозрачно направлять TCP-поток к соответствующему локальному процессу.Логическая архитектура защищенного узла принимает следующий многоуровневый вид:HAProxy (Фронтенд): Процесс привязывается к внешнему сетевому интерфейсу и прослушивает сокет 144.31.251.236:1443 в режиме сырого TCP.Инспекция и защита от сканирования: Правила контроля доступа (ACL) внутри HAProxy приостанавливают проброс соединения на несколько миллисекунд (tcp-request inspect-delay 5s), ожидая формирования пакета ClientHello. Проверяется наличие сигнатуры TLS-рукопожатия (req_ssl_hello_type 1) и соответствие запрашиваемого домена строке amazonws.com.Маршрутизация к MTProto-демону (Бэкенд 1): Если первичные проверки пройдены, TCP-поток направляется локальному MTProto-демону (например, Zig-серверу, слушающему петлевой интерфейс 127.0.0.1:8443).Маршрутизация к веб-серверу (Бэкенд 2 / Fallback): В случае, если сканер обращается по IP-адресу без указания SNI, передает неверный домен, или инициирует обычный HTTP-запрос (без шифрования), HAProxy перенаправляет трафик на локальный инстанс NGINX. Этот веб-сервер настроен как так называемая "заглушка" (dummy server) или обратный прокси, который ретранслирует реальный контент легитимного сайта, окончательно убеждая сканер цензора в том, что он взаимодействует с обычным корпоративным веб-узлом.Одной из критических проблем маршрутизации на транспортном уровне L4 является потеря информации об исходном IP-адресе клиента. Когда HAProxy перенаправляет пакет локальному MTProto-демону, демон видит входящее соединение от 127.0.0.1, что делает невозможным применение анти-флуд механизмов, ведение аудита безопасности и функционирование лимитов скорости по подсетям (например, rate_limit_per_subnet в Zig). Для элегантного решения этой проблемы взаимодействие между HAProxy и MTProto-демоном должно осуществляться по стандартизированному протоколу PROXY protocol v2. Данный протокол предписывает балансировщику добавлять небольшой бинарный заголовок перед началом передачи полезной нагрузки TCP-сессии; этот заголовок содержит исходный IP-адрес и порт клиента. Современные реализации прокси-серверов на языках Erlang, Go и Zig нативно поддерживают декодирование заголовков PROXY-протокола, восстанавливая истинный IP-адрес клиента во внутренней бизнес-логике.Эталонный пример конфигурации haproxy.cfg, реализующий описанную архитектурную парадигму:Фрагмент кодаglobal
log /dev/log local0
maxconn 100000
defaults
log global
mode tcp
option tcplog
timeout connect 5s
timeout client 120s
timeout server 120s
frontend proxy_frontend
bind 144.31.251.236:1443
mode tcp
# Ожидание формирования TLS ClientHello для проведения инспекции
tcp-request inspect-delay 5s
# Принятие соединения только при наличии валидного начала TLS-сессии
tcp-request content accept if { req_ssl_hello_type 1 }
# Определение строгих правил ACL по совпадению домена SNI
acl is_fake_tls req_ssl_sni -i amazonws.com
# Детерминированная маршрутизация
use_backend mtproto_daemon if is_fake_tls
default_backend nginx_fallback
backend mtproto_daemon
mode tcp
# Передача реального IP клиента через бинарный заголовок PROXY protocol v2
server local_mtg 127.0.0.1:8443 send-proxy-v2
backend nginx_fallback
mode tcp
# Маршрутизация паразитных сканеров на защитный веб-сервер
server local_nginx 127.0.0.1:8080
Данный архитектурный паттерн обеспечивает максимальную структурную устойчивость к эвристическим атакам цензоров, поскольку любая посторонняя нелегитимная активность получает стандартизированный ответ HTTP-сервера без малейшего раскрытия криптографических сигнатур MTProto-протокола.Интеграция с Python 3.11: Асинхронный биллинг и генерация конфигурацийРазработка системы управления биллинговым ботом на базе современного интерпретатора Python версии 3.11 и асинхронного фреймворка aiogram требует математически точного соблюдения криптографических форматов экосистемы Telegram для генерации конфигурационных файлов. В рамках заданного технологического стека генерация ключей, их привязка к пользователям и сохранение состояний в локальную СУБД SQLite должны быть строго транзакционными операциями, устойчивыми к сбоям.Криптографическая генерация совместимых секретов Fake TLSСекрет, который конечному пользователю необходимо ввести в клиентское приложение Telegram, в случае использования транспорта FakeTLS представляет собой не монолитный ключ, а композитную структуру из трех логических компонентов, скомпилированных в единую шестнадцатеричную (HEX) строку :Протокольный префикс (1 байт): Для инициации режима Fake TLS спецификация требует использования константного префикса ee. Этот байт выступает в роли флага, указывающего криптографическому движку клиента Telegram на необходимость глубокой маскировки всего последующего трафика под стандартный зашифрованный HTTPS-поток данных.Базовый криптографический секрет (16 байт): Криптографически стойкая случайная последовательность данных, гарантирующая математическую уникальность сессии и защиту от несанкционированного доступа. В шестнадцатеричном строковом представлении этот компонент занимает ровно 32 символа.SNI-домен для обфускации (N байт): Целевой домен (в нашем случае константа amazonws.com), закодированный в HEX-формат, который клиентское приложение будет использовать для формирования поля SNI в фальшивом пакете ClientHello.Стандартная библиотека языка Python предоставляет все необходимые высокоуровневые модули (secrets, binascii) для безопасной генерации таких композитных секретов, которые будут корректно восприняты как официальными клиентами Telegram, так и бэкенд прокси-демонами (такими как mtg-multi на Go или mtproto.zig на Zig).Pythonimport secrets
import binascii
from typing import Tuple
def generate_fake_tls_secret(domain: str = "amazonws.com") -> Tuple[str, str]:
"""
Алгоритм генерации композитного FakeTLS секрета для авторизации нового пользователя.
В соответствии со стандартами транспортного уровня MTProto, результирующий секрет имеет формат:
Константный префикс 'ee' + 16 байт криптографической энтропии (32 HEX-символа) + HEX-представление домена.
Возвращает кортеж: (Полный клиентский секрет, Базовый 32-символьный секрет демона)
"""
prefix = "ee"
# Генерация 16 байт (128 бит) энтропии с использованием криптографически стойкого ГПСЧ ОС, возврат в формате HEX
base_secret = secrets.token_hex(16)
# Трансляция строки целевого домена в шестнадцатеричный формат (UTF-8 -> HEX)
hex_domain = binascii.hexlify(domain.encode('utf-8')).decode('utf-8')
# Формирование результирующего композитного секрета для передачи клиенту
full_client_secret = f"{prefix}{base_secret}{hex_domain}"
return full_client_secret, base_secret
# Пример вызова функции бизнес-логикой бота:
# client_secret, core_secret = generate_fake_tls_secret()
# client_secret -> 'ee3b9c...616d617a6f6e77732e636f6d'
Важное архитектурное уточнение, влияющее на структуру базы данных: в некоторых реализациях демонов (например, в Go-версии mtg-multi) в конфигурационный TOML-файл прописывается полная строка клиентского секрета (включая префикс ee и закодированный домен). В других же современных реализациях (таких как mtproto.zig) парсер конфигурации ожидает получить исключительно 32-символьный базовый криптографический секрет (чистые 16 байт), тогда как префикс и строка домена автоматически обрабатываются внутренней логикой демона на лету. Во избежание конфликтов совместимости, биллинговому боту необходимо сохранять оба вычисленных значения в реляционную базу данных.Транзакционная модель данных в SQLite и управление состояниямиДля обслуживания клиентской базы в 500 пользователей встроенной легковесной СУБД SQLite более чем достаточно, однако классический режим работы SQLite сопряжен с блокировками базы на запись, что фатально в асинхронной среде. Критически важным условием является включение режима журналирования Write-Ahead Logging (WAL) на уровне прагм базы данных (PRAGMA journal_mode=WAL;). Режим WAL позволяет читающим потокам не блокировать пишущие, что обеспечивает бесперебойный конкурентный доступ со стороны множества асинхронных хендлеров фреймворка aiogram (при использовании библиотек-адаптеров вроде aiosqlite).Оптимальная схема реляционной таблицы proxy_users для управления жизненным циклом подписок выглядит следующим образом:Поле в таблице SQLiteТип данныхОписание и назначениеuser_idINTEGER PRIMARY KEYУникальный идентификатор пользователя в экосистеме Telegram.base_secretVARCHAR(32)Базовый 128-битный криптографический ключ (используется для Zig-демонов).full_secretVARCHAR(255)Композитная строка секрета для формирования диплинков tg://proxy?server...statusVARCHAR(20)Индикатор состояния конечного автомата подписки (active, expired, banned).expires_atDATETIMEТочная временная метка (timestamp) истечения оплаченного биллингового периода.data_usage_mbINTEGERНакопительный счетчик объема потребленного трафика (мегабайты) для предотвращения флуда.Интеграция с асинхронным циклом событий asyncio подразумевает создание фонового процесса-планировщика (например, с использованием паттернов библиотеки apscheduler). Данный процесс должен с периодичностью в одну минуту осуществлять SELECT-запрос к базе данных, выявляя записи, у которых значение expires_at меньше текущего системного времени. Обнаружив истекшие подписки, система транзакционно изменяет их статус на expired, после чего инициирует процедуру динамической пересборки файла конфигурации прокси-демона (config.toml для Go или Zig версий) на основе актуальных записей со статусом active. Завершающим этапом цикла является атомарная перезапись файла и отправка POSIX-сигнала операционной системе (обычно SIGHUP через модуль os.kill или вызов системной утилиты через subprocess.run), что приводит к мгновенному применению новых политик доступа (Hot Reload) без остановки обслуживания активных клиентов.Управление производительностью и глубокий мониторинг под нагрузкойОдной из самых серьезных и трудноразрешимых проблем при коммерческой эксплуатации прокси-инфраструктуры является явление оверселлинга (overselling) и неконтролируемой передачи криптографических секретов третьим лицам. Если недобросовестный пользователь публикует свой индивидуальный ключ в публичном Telegram-канале с многотысячной аудиторией, количество активных TCP-сессий, аутентифицирующихся по данному секрету, лавинообразно возрастает. Это приводит к стремительному исчерпанию пула файловых дескрипторов (file descriptors) операционной системы Linux, переполнению очередей сокетов и катастрофической деградации пропускной способности всего узла. В связи с этим система мониторинга соединений с детализацией по конкретным секретам является не опцией, а фундаментом безопасности.Инструментарий сбора телеметрии и статистикиРешения для сбора телеметрических данных архитектурно различаются в зависимости от выбранного прокси-демона:Мониторинг в реализации Go (mtg-multi):
Разработчики форка интегрировали в ядро прокси-сервера легковесный REST API сервер (по умолчанию привязывающийся к внутреннему интерфейсу 127.0.0.1:9090). HTTP-запрос к эндпоинту GET /stats возвращает структурированный JSON-документ, содержащий детализированную статистическую информацию по каждому активному логину или секрету.
Структура ответа включает базовые метрики времени работы (uptime_seconds), глобального числа соединений (total_connections), а также критически важный ассоциативный массив users, где для каждого отдельного идентификатора пользователя в реальном времени отображаются: текущее количество открытых сессий (connections), совокупный объем входящего трафика (bytes_in), объем исходящего трафика (bytes_out) и временная метка последней активности (last_seen).Наличие такого API позволяет Python-боту инициировать асинхронные HTTP-запросы (с помощью библиотеки aiohttp), агрегировать данные о потреблении трафика в СУБД SQLite и автоматически переводить статус пользователей в состояние banned, если их счетчик connections устойчиво превышает аномальные значения (например, более 15 одновременных TCP-подключений с разных IP). Дополнительная проактивная защита на уровне самого демона гарантируется конфигурационным параметром [throttle] max-connections.Мониторинг в реализации Zig (sleep3r/mtproto.zig):
Высокопроизводительный сервер предлагает два нативных механизма интроспекции. Первый представляет собой легковесный встроенный веб-дашборд, доступный на порту 61208 (по умолчанию прослушивает только петлевой интерфейс 127.0.0.1). Дашборд предоставляет администратору визуальный контроль за сетевыми потоками, потреблением ресурсов CPU и памяти, а также статусом резервных пулов туннелей. Второй механизм, являющийся стандартом де-факто для программного межсервисного взаимодействия — встроенный экспортёр метрик в формате Prometheus (по умолчанию запускается на порту 9400, отдавая данные по эндпоинту /metrics).Парсинг вывода Prometheus со стороны микросервисов на Python позволяет биллинговой логике получать точные данные по общему количеству активных соединений (с контролем аппаратного лимита, определяемого переменной max_connections, который для 500 пользователей должен быть установлен не ниже значения 4096) , а также отслеживать состояние резервных маршрутов (failover routing pools), если для обхода блокировок уровня дата-центров Telegram применяется агрегация внешних каналов через WireGuard или AmneziaWG.Анализ производительности ядра ОС под конкурентной нагрузкойМасштабирование программного комплекса до 500 активных коммерческих пользователей на одном физическом или виртуальном сервере требует глубокого понимания особенностей сетевого протокола Telegram. Каждое клиентское приложение Telegram при запуске и выходе из фонового режима немедленно инициирует от 3 до 8 одновременных TCP-соединений. Они необходимы для распараллеливания задач: подгрузки медиафайлов, отправки текстовых сообщений, получения push-уведомлений и обновления метаданных сессии. Соответственно, клиентская база в 500 человек может генерировать перманентный пул объемом от 3000 до 4000 активных подключений.Для операционной системы Debian это диктует абсолютную необходимость тонкого тюнинга параметров сетевой подсистемы ядра sysctl и лимитов пользовательского пространства ulimit:Модификация параметра ядра fs.file-max = 100000 (увеличение максимального числа глобально открытых дескрипторов файлов и сокетов).Установка параметра LimitNOFILE=65535 в systemd unit-файлах как MTProto-демона, так и балансировщика HAProxy для предотвращения ошибок вида "Too many open files".Глубокая оптимизация TCP/IP стека: уменьшение таймаутов удержания полузакрытых соединений (net.ipv4.tcp_fin_timeout = 15), расширение очередей net.core.somaxconn, а также обязательное включение алгоритма контроля перегрузки BBR (net.ipv4.tcp_congestion_control = bbr) для максимизации скорости отдачи тяжелого медиа-контента даже на каналах с высокими потерями пакетов.Рассматривая профиль потребления оперативной памяти (RAM) и циклов процессорного времени (CPU) в контексте 4000 одновременных TCP-сессий, можно выделить следующие паттерны:Реализация прокси-сервераПрогнозируемое потребление ОЗУ (4000 сессий)Поведение системы под пиковой сетевой нагрузкойC (Official)150 - 200 МБЗначительное количество контекстных переключений (context-switches) ядра при операциях ввода-вывода; возможна фрагментация памяти.Erlang (seriyps)100 - 300 МБ (Динамически)Мягкая деградация благодаря внутреннему планировщику BEAM; изолированный сбор мусора по процессам.Go (mtg-multi)50 - 150 МБВозможны кратковременные задержки (Stop-the-World) при работе глобального сборщика мусора (GC) во время массовых переподключений.Zig (mtproto.zig)15 - 30 МБАбсолютная предсказуемость; преаллокация буферов устраняет задержки. Нулевая фрагментация памяти.Критическим архитектурным параметром при конфигурации высокопроизводительного mtproto.zig для коммерческого профиля с не-Premium пользователями является безусловная активация настройки [general] use_middle_proxy = true. Транспортный слой MiddleProxy (ME) жизненно необходим для автоматического и прозрачного обновления метаданных; без него загрузка фотографий, видео и историй (Stories) на аккаунтах без платной подписки Telegram перестанет функционировать должным образом, вызывая ошибки тайм-аутов. Размер внутреннего транзитного буфера для видеопотока можно дополнительно тюнинговать через параметр конфигурации middleproxy_buffer_kb (рекомендуются значения 1024 или 2048 килобайт для исключения переполнения).Заключительный синтез и архитектурные рекомендацииПроектирование, конфигурация и развертывание коммерческой системы MTProto-прокси для мессенджера Telegram на май 2026 года в условиях перманентного и проактивного противодействия со стороны систем глубокого инспектирования трафика (DPI/ТСПУ) — это многогранная инженерная и криптографическая задача, бескомпромиссно требующая выхода за рамки стандартных готовых конфигураций и применения эвристических методов защиты.На основании проведенного исчерпывающего кросс-платформенного анализа можно констатировать следующие фундаментальные выводы:Выбор программного вычислительного ядра: Использование классической официальной C-реализации признается полностью несовместимым с бизнес-требованиями динамического управления подписками из-за полного отсутствия механизмов Hot Reload. Системным инженерам целесообразно использовать современную платформу на языке Zig (sleep3r/mtproto.zig) для достижения ультра-низкого потребления аппаратных ресурсов и глубокой маскировки на уровне TCP-заголовков (nfqws desync, TCPMSS фрагментация, Zero-RTT), либо специализированный форк на языке Go (dolonet/mtg-multi) при необходимости жесткого квотирования пропускной способности с помощью интегрированных fair-share алгоритмов. Обе системы нативно поддерживают управление секретами через файлы TOML.Топология транспортного уровня: Для строгого соблюдения ограничения работы на одном публичном IP (144.31.251.236) и порту (1443) категорически необходим промежуточный L4-мультиплексор (HAProxy), осуществляющий прозрачный SNI-роутинг и трансляцию адресов через PROXY protocol v2. Данный слой инфраструктуры полностью берет на себя защиту от активного зондирования ТСПУ, отсеивая паразитные сканирующие запросы на резервный веб-сервер NGINX и надежно маскируя следы присутствия MTProto-сети в дата-центре.Криптография и биллинг: Стек технологий Python 3.11 обладает достаточным и высокоскоростным инструментарием для безопасной генерации легитимных секретов протокола FakeTLS (осуществляя строгую конкатенацию маркера ee, 16 байт энтропии и HEX-кодированного домена amazonws.com). Интеграция с СУБД SQLite в отказоустойчивом режиме WAL и фреймворком aiogram позволяет выстроить надежный асинхронный пайплайн биллинга, не подверженный взаимным блокировкам потоков.Управление емкостью пула: Сетевое профилирование однозначно показывает, что 500 активных коммерческих клиентов неизбежно генерируют нагрузку около 4000 постоянных TCP-сокетов. Мониторинг потребления посредством экспорта метрик Prometheus или встроенных REST API-эндпоинтов (/stats) критически важен для оперативного выявления нарушителей лицензионного соглашения, публикующих личные ключи в открытых источниках, а также для поддержания общего уровня QoS (качества обслуживания) пула.Синтез и математически точная интеграция описанных выше механизмов — от низкоуровневой L4-маршрутизации и динамической генерации TOML-конфигураций, до бесшовной SIGHUP-перезагрузки ядра и асинхронного агрегирования метрик в Python — формирует архитектурно безупречный, отказоустойчивый коммерческий шлюз. Такая инфраструктура способна эффективно нивелировать современные комплексные угрозы блокировок и обеспечивать непрерывность критически важного сервиса обмена сообщениями для конечных абонентов.