Comments 12
Спасибо, очень годная статья. Надеюсь проработает подольше.
да, кстати, у кого есть ИИ-агент типа opencode - его можно поставить на сервер (или просто сказать "ходи на сервер через ssh user@domain..."), и сказать ему прочитать эту статью (прям ссылку дать), составить план работ, использовать в качестве домена-приманки "домен-провайдера.ru", после настройки протестировать работу существующих виртуальных хостов и домена-приманки через mtproxy, найти в system логах tg-ссылку и поправить в ней порт — и через минуту у вас всё будет работать. Он ещё и сам всё протестирует — вам останется только ссылку скопировать и отправить друзьям
именно так! Использовал https://argv.cloud/blog/2025/ai-remote-ops/
Настроил домашний минисервер на доступ к другим серверам для контроля и администрирования.
да, мой opencode наудивление очень круто выполняет всю работу по администрированию linux серверов — прям идеально. И всё перепроверит, сделает бэкапы на всякий случай — короче прям без нареканий. Главное сначала в режиме планирования всё обсудить на берегу, он задаст уточняющие вопросы, распишет план работ — и погнали.
А кто-нибудь ковырялся с wireshark, насколько хендшейк телеги через такой прокси отличается от обычного захода на сайт?
я навайбил мини скрипт который ловит подключение от браузера и от ТГ-клиента и сравнивает их хендшейк. Разница есть, да.
Waiting on port 20098 for first connection...
Client A from xxx:57588
tls_version: 0x0303
sni: my-site.one
alpn: h2, http/1.1
cipher_suites_count: 16
cipher_suites: 0x5a5a, 0x1301, 0x1302, 0x1303, 0xc02b, 0xc02f, 0xc02c, 0xc030, 0xcca9, 0xcca8, 0xc013, 0xc014, 0x009c, 0x009d, 0x002f, 0x0035
extensions: 0x2a2a, 0xff01, 0x000b, 0xfe0d, 0x000a, 0x0023, 0x002d, 0x000d, 0x0017, 0x44cd, 0x001b, 0x0005, 0x002b, 0x0010, 0x0033, 0x0012, 0x0000, 0x0a0a
Waiting on port 20099 for first connection...
Client B from xxx:57599
tls_version: 0x0303
sni: www.hetzner.com
alpn: h2, http/1.1
cipher_suites_count: 21
cipher_suites: 0x8a8a, 0x1301, 0x1302, 0x1303, 0xc02c, 0xc02b, 0xcca9, 0xc030, 0xc02f, 0xcca8, 0xc00a, 0xc009, 0xc014, 0xc013, 0x009d, 0x009c, 0x0035, 0x002f, 0xc008, 0xc012, 0x000a
extensions: 0xfafa, 0x0000, 0x0017, 0xff01, 0x000a, 0x000b, 0x0010, 0x0005, 0x000d, 0x0012, 0x0033, 0x002d, 0x002b, 0x001b, 0x4a4a, 0x0015
Differences
sni: my-site.one vs www.hetzner.com
cipher_suites: different
only_in_a: 0x5a5a
only_in_b: 0x000a, 0x8a8a, 0xc008, 0xc009, 0xc00a, 0xc012
extensions: different
only_in_a: 0x0023, 0x0a0a, 0x2a2a, 0x44cd, 0xfe0d
only_in_b: 0x0015, 0x4a4a, 0xfafa
А не случится так, что РКН, отловив трафик прокси, не заблокирует по IP вообще весь ваш сервер вместе со всеми сайтами?
Ничего не понятно, Но ужасно интересно.
Есть более устойчивая версия MTProxy к DPI https://github.com/telemt/telemt
судя по описанию — ровно такой же функционал маскировки как у alexbers/mtprotoproxy через длинный secret с префиксом ee. Может я что-то пропустил?
Проблема на самом деле не в проксях, а в телеграм-клиентах, которые отправляют ssl-handshake заметно отличающийся от браузерного. Я уже отправил своим друзьям в команде телеграма этот багрепорт, так что может они исправят.
Возможно конечно версия на rust меньше ресурсов ест, но судя по статистике моего сервера — куда уж меньше. У меня сейчас несколько десятков активных клиентов и на двухядерной виртуалке я вообще этот питон-прокси в топе не вижу.
Настройка Telegram MTProxy на 443 порту параллельно с работающим nginx