Инструкция по обходу блокировки Telegram. Как активировать SOCKS 5
В телеграм-канале tnews_ru опубликовали инструкцию по обходу возможной блокировки Telegram — популярного мессенджера, разработанного командой Павла Дурова. В статье описывается способ обхода, который основывается на использовании сетевого протокола SOCKS5. Этот протокол незаметно пересылает пакеты данных от клиента к серверу через прокси-сервер.
SOCKS — сетевой протокол, который позволяет клиент-серверным приложениям прозрачно (незаметно для них) использовать сервисы за межсетевыми экранами (фаерволами). Опция уже доступна в Telegram Desktop и Mac, а мобильные клиенты получат её в ближайшем обновлении.
Совет: включите в настройках опцию автоматического обновления.
Как всё-таки сохранить доступ к Telegram после того, как мессенджер заблокируют в России?
В первую очередь включите SOCKS5 до начала блокировки.
Если вы по каким-то причинам не успеете это сделать, то придётся туго, т.к. из российских Google Play и AppStore, клиенты Telegram, скорее всего, исчезнут. Здесь помогут Vpn и Tor, через которые можно будет скачать Telegram в американских магазинах. Но не обольщайтесь — впереди закон по запрету средств обхода блокировок, принятый в первом чтении в Госдуме РФ.
Совет: в настройках Android разрешите скачивание обновлений не из официального магазина, и скачайте обновление Telegram с сайта мессенджера telegram.org.
Настройка SOCKS 5
Приводим инструкцию на русском языке:
1) Зайдите в настройки настольного Telegram и нажмите «По умолчанию (сейчас:TCP)».
2) Переключите в меню «Тип соединения» на «TCP socks5-прокси»
3) Введите адрес прокси сервера (например, 192.254.68.37), соответствующий порт (1080). Лучше использовать прокси-адреса Америки, Германии, Швеции или Англии. Затем ставите галочку «Использовать IPv6» и сохраняете.
Как найти прокси-сервера?
Просто перейдите по следующим ссылкам:
Только берите сервер для SOCKS5, не перепутайте с HTTP.
Возможна настройка из этого бесплатного списка (socks — sockslist.net).
Теперь по умолчанию ваш Telegram будет соединяться через выбранный прокси-сервер.
Дополнение: Если возникнут проблемы с подключением, нужно настроить брандмауэр Windows — добавить в разрешенные приложения Telegram. Сделать это просто, но у вас должны быть права администратора.
Transports
Enables the delivery of encrypted containers together with the external header (hereinafter, Payload) from client to server and back. Multiple transport protocols are defined:
The URI format for connecting to the websocket and HTTP endpoints is the following:
The TCP transport is implemented simply by sending the payloads generated by the chosen MTProto transport over a plain TCP socket on ports 80, 443, 5222 or other (a different port number may be returned by help.getConfig).
Framing is managed by the chosen MTProto transport protocol.
There are no implicit acknowledgments for the TCP transport: all messages must be acknowledged explicitly. Most frequently, acknowledgments are placed in a container with the next query or response if it is transmitted in short order. For example, this is almost always the case for client messages containing RPC queries: the acknowledgment normally arrives with the RPC response.
Websocket
Implementation of the websocket transport is pretty much the same as with TCP: a websocket connection is established to the chosen MTProto server over port 80 using the specified URI format.
Framing of payloads is still managed by the chosen MTProto transport protocol, not by websocket messages: the length of MTProto payloads is defined by the MTProto transport protocol, not by the length of the single websocket messages. This simply means that all data received and sent through websocket messages is to be treated as a single duplex stream of bytes, just like with TCP.
When using the websocket transport, transport obfuscation is required. Transport errors are transmitted the usual way, as with TCP. The close code of websockets will always be 1000 (normal closure), regardless of the actual exit status. In all cases, the description string will be a decimal encoded real error code (which may be forward/back-padded with whitespaces for constant length) and can be safely ignored.
Websocket over HTTPS
To establish a websocket connection over HTTPS, simply use the TLS URI format. The rest is the same as with plain websockets.
Note: when implementing browser clients, websocket transport is recommended instead of HTTP, thanks to its full-duplex stream logic similar to TCP’s; this removes the need for HTTP long polling and eventual delays while relaying RPC replies.
Implemented over HTTP/1.1 (with keepalive) running over the traditional TCP Port 80. HTTPS can also be used.
Message framing is not managed by MTProto transport protocols; it is instead handled by the HTTP protocol itself. Transport errors are also not transmitted the usual way, instead they are simply returned as normal HTTP status codes.
An HTTP connection is attached to a session (or rather, to session + key identifier) specified in the most recent user query received; normally, the session is the same in all queries, but crafty HTTP proxies may corrupt that. A server may not return a message into an HTTP connection unless it belongs to the same session, and unless it is the server’s turn (an HTTP request had been received from the client to which a response has not been sent yet).
The overall arrangement is as follows. The client opens one or more keepalive HTTP or HTTPS connections to the server. If one or more messages need to be sent, they are made into a payload which is followed by a POST request to the URL/api to which the payload is transmitted as data. In addition, Content-Length , Keepalive , and Host are valid HTTP headers.
Having received the query, the server may either wait a little while (if the query requires a response following a short timeout) or immediately return a dummy response (only acknowledging the receipt of the container). In any case, the response may contain any number of messages. The server may at the same time send out any other messages it might be holding for the session.
In addition, there exists a special long poll RPC query (valid for HTTP connections only) which transmits maximum timeout T. If the server has messages for the session, they are returned immediately; otherwise, a wait state is entered until such time as the server has a message for the client or T seconds have elapsed. If no events occur in the span of T seconds, a dummy response is returned (special message).
If a server needs to send a message to a client, it checks for an HTTP connection that belongs to the required session and is in the “answering an HTTP request” state (including long poll) whereupon the message is added to the response container for the connection and sent to the user. In a typical case, there is some additional wait time (50 milliseconds) against the eventuality that the server will soon have more messages for the session.
If no suitable HTTP connection is available, the messages are placed in the current session’s send queue. However, they find their way there anyway until receipt is explicitly confirmed by the client. For all protocols, the client must return an explicit acknowledgment within a reasonable time (it can be added to a container for the following request).
Important: if the acknowledgment fails to arrive on time, the message can be resent (possibly, in a different container). The parties must autonomously be ready for this and must store the identifiers of the most recent messages received (and ignore such duplicates rather than repeat actions). In order not to have the identifiers stored forever, there exist special garbage collection messages that take advantage of message identifier monotonicity.
If the send queue overflows or if messages stay in the queue for over 10 minutes, the server forgets them. This may happen even faster, if the server is running out of buffer space (for example, because of serious network issues resulting in a large number of connections becoming severed).
HTTPS
To establish a connection over HTTPS, simply use the TLS URI format. The rest is the same as with plain HTTP.
URI format
The URI format that must be used when connecting to the plain websocket and HTTP endpoints is the following:
The w flag is added when CORS headers are required in order to connect from a browser.
The s flag enables the websocket API.
The name placeholder in the domain version specifies the DC ID to connect to:
- pluto => DC 1
- venus => DC 2
- aurora => DC 3
- vesta => DC 4
- flora => DC 5
-1 can be appended to the DC name to raise the maximum limit of simultaneous requests per hostname.
The _test flag, when connecting to the domain version of the URL, specifies that connection to the test DCs must be made, instead.
TLS URI format
When connecting to the HTTPS and WSS endpoints, only the domain name URI can be used over port 443:
See the URI format for an explanation of the placeholders.
Example implementations: tdlib, MadelineProto (client side), MTProxy (server side).
Allowing telegram through firewall: how to find which ports have to be opened?
I’m behind firewall, and I lack information how to find out, which IP/port has to be opened for certain application. In my current case, it is telegram.
I did not find any document «allow these IPs/ports». I found telegram-related IP ranges, but when I used sudo tcpdump -i <iface> -nn -s 0 -v > /tmp/tcpDump and generate some outgoing traffic, I’m not able to find any of these IPs. And that’s pretty much where my «knowledge» ends.
How can I find, what has to be configured on firewall? (sure, I’d like to hear telegram-related answer, but I’m more after how is this resolved generally).
1 Answer 1
I am not very familiar with telegram so this is from the perspective of an administrator doing general troubleshooting for ports.
Most applications usually have documentations what needs to be enabled to allow the application to work. You can usually find a list ports, IPs, FQDN by simply googling, «what ports does use». In your specific example the google results shows the following: https://core.telegram.org/bots/webhooks
A webhook needs an open port on your server. We currently support the following ports: 443, 80, 88 and 8443. Other ports are not supported and will not work. Make sure your bot is running on one of those supported ports, and that the bot is reachable via its public address.
By default that means we’re knocking at your door on port 443
Once you get this port information you usually do a test to see if my device can even reach said listener. My preferred method and I truly believe is one of the easiest way is to try and telnet to the host on that port. It doesn’t matter if they have a telnet server setup or not, you can verify that the destination is valid. So on a window server I’d fire up the command prompt and try telnet 149.154.167.197 443. In all linux distribution you can use the identical command telnet 149.154.167.197 443. If you get a response you can narrow it down that the issue is somewhere on the source or that is not the port you need.
If you are unable to find any documentation or it doesn’t appear to be working you can search your active connections. On windows you can do this by firing up the application and then opening up the command prompt and running the command netstat -a -b . Netstat is a command that displays information about TCP connections on your device. On most linux distribution you can use the much more robust nstat -a from iproute2.
This should solve your issue with finding ports almost every single time. If it does not your last major tool is to download a packet analyzer tool such as ngrep or wireshark and manually analyze traffic from your device. If you know the source/destination you can usually find it pretty quick.
A final note is that before anything if it is going out on the internet. There is a very large chance it will be using port 80 (http) or 443 (https) and should probably be the first guess unless it is using a distinct protocol.
Куда и как ходит Telegram?
Начнём с простого. Telegram-клиенты общаются с Telegram-серверами по собственному протоколу MTProto поверх TCP. Для соединения используются несколько адресов, которые не изменялись годами и продолжают являться основными точками подключения. Возьмём для примера один из адресов европейского региона: 149.154.167.40.
Обычно используется порт 443, но никакого отношения к SSL/TLS это не имеет.
На приведённой схеме видно, из чего состоит каждый пакет. Открытые пакеты используются только при первых коммуникациях с целью обменяться ключами, дальше вся связь зашифрована.
Обратите внимание, что даже в зашифрованных пакетах есть постоянные заголовки: первые 8 байт будут одинаковыми в пределах сессии, так как представляют из себя отпечаток авторизационного ключа. К этому моменту мы скоро вернёмся.
Роскомнадзор, мать его
И тут в игру вступает злое государство и его орган, регулирующий интернет, который начинает блокировку Telegram! В нашем случае это Роскомнадзор, который добавляет в выгрузку для провайдеров все подсети Telegram, в том числе ту, в которой находится наш 149.154.167.40. Провайдеры получают выгрузку и закрывают доступ пользователям к указанным адресам.
Команда Telegram, конечно, не оставила нас в беде. Ребята запустили множество серверов у разных хостинг-провайдеров, которые стали принимать пакеты и переадресовывать их на основные Telegram-сервера, попавшие под блокировку.
Откуда же приложение на вашем телефоне/компьютере узнает адреса этих новых серверов? Используются два метода.
Как доставить новые адреса серверов клиентам?
DC_UPDATE
Это первый способ, которым адреса новых серверов доставляются на устройства пользователей. Подходит он только для мобильных клиентов на iOS и Android, потому что использует Apple Push Notification Service и Google Cloud Messaging соответственно. Команда Telegram отправляет вам на устройства push-уведомления, внутри которых содержится список новых адресов. Приложение Telegram считывает их и начинает использовать эти адреса для связи.
- Помешать затее можно только заблокировав APNS и GCM полностью, что лишит вас всех уведомлений от всех приложений, даже если вы никогда не пользовались Telegram. На это власти не пойдут (?).
- В теории этот способ позволяет отправлять разным группам пользователей разные адреса, что может отсрочить блокировку новых серверов и помочь команде Telegram вычислить шпионов. На практике эта хитрость, насколько я знаю, не используется.
- Подходит только для мобильных устройств, так как на десктопных операционных системах нет единого механизма доставки уведомлений.
- Может работать нестабильно. Если уведомление по каким-то причинам до вас не дошло, приложение Telegram не узнает о новых адресах. Особенно актуально для iOS, где приложения сильно ограничены в фоновой обработке уведомлений. Именно поэтому на iOS такие push видны пользователю и требуют нажатия для активации.
Роскомнадзор выслеживает новые адреса, приходящие в DC_UPDATE и блокирует их.
Domain fronting
Этот способ доставки адресов не так широко известен, а многие вовсе не понимают, как он работает.
Для начала рекомендую прочитать общее описание. Telegram же просто помещает зашифрованный список в TXT-записи своих сервисных доменов и на платформе Azure. Затем клиенты запрашивают эти данные с адресов dns.google.com и tcdnb.azureedge.net/prodv2/config.txt. Техника domain fronting позволяет сделать так, что провайдерские системы фильтрации и блокировок видят это как запросы к google.com и software-download.microsoft.com.
Плюсы domain fronting:
- Для блокировки этого способа придётся заблокировать весь google.com и сервис доставки обновлений Windows. Роскомнадзор на такое пойти не может. Однажды они блокировали google.com, но дали заднюю.
- Может работать и работает на любых платформах, включая десктопные.
obfuscated2: Защита от более продвинутого DPI
Что, если регулирующий интернет орган вроде Роскомнадзора станет чуть умнее? Если ещё не забыли, в начале статьи я упомянула, что даже в зашифрованных пакетах Telegram всегда есть постоянные заголовки. При желании провайдер может отслеживать эти заголовки и блокировать соединения на основании содержимого пакета, а не адресов серверов. Тогда все вышеописанные техники защиты станут бесполезными, подумаете вы, и окажетесь правы. Почти правы.
Telegram ещё как минимум в начале 2017 года реализовал защиту от подобных «лишних глаз», заглядывающих в пакеты.
Несмотря на то, что протокол MTProto открыт и описан на официальном сайте Telegram, официальные же клиенты используют дополнительный слой обфускации, нигде не документированный. Товарищ Tomas Susanka уже максимально подробно описал используемый метод обфускации пакетов, поэтому расписывать всё не буду.
Обфуска́ция или запутывание кода — приведение исходного текста или исполняемого кода программы к виду, сохраняющему её функциональность, но затрудняющему анализ, понимание алгоритмов работы и модификацию при декомпиляции.
Клиент придумывает случайный 32-байтовый ключ и случайный 16-байтовый Initialization Vector, которыми шифрует каждый пакет с помощью AES CTR, а чтобы сервер узнал, как это расшифровать… ключ и IV добавляются в начало пакета перед зашифрованным содержимым.
Вы назовёте это глупостью, ведь какой смысл отправлять зашифрованные пакеты и сразу прикладывать к ним ключ для расшифровки? Конечно, это абсолютно бесполезная защита в логическом смысле, но она имеет большой смысл на практике.
После обфускации все пакеты выглядят как случайный мусор, поэтому для определения, Telegram-трафик это или нет, провайдеру придётся расшифровывать каждый непонятный пакет по методике obfuscated2, прежде чем проводить дальнейшие проверки. Такие действия требуют неоправданное количество вычислительных мощностей, которых у провайдеров попросту нет.
Подключение к Telegram через прокси
Как уже было сказано выше, команда Telegram прикладывает много усилий, чтобы обойти государственные блокировки, но это не всегда работает. Временные сервера быстро блокируются Роскомнадзором и мы снова теряем доступ к мессенджеру.
Дальнейшая борьба с блокировками отдаётся на откуп пользователям. Telegram предоставляет целых два способа подключения через прокси в своих приложениях. Оба способа не предполагают раскрытия ваших переписок и прочих данных держателям прокси-серверов, так как трафик Telegram изначально зашифрован и передаётся через промежуточные звенья в нечитаемом виде.
SOCKS5-прокси
Очень банальный, но действенный способ. Если сможете осилить технический английский, почитайте вот этот RFC-документ.
Клиент Telegram подключается к заданному вами SOCKS5-серверу и уже через него устанавливает соединение с Telegram-серверами. Так как SOCKS5-сервер находится вне страны, которая ввела блокировки, соединения между ним и Telegram устанавливаются успешно.
Простая лазейка будет работать до тех пор, пока сам прокси-сервер не будет отслежен и заблокирован.
- Очень быстро и очень просто.
- Всем известный протокол, серверные реализации которого существуют под все платформы и ОС.
- Протокол очень легко детектируется с помощью DPI, государство может легко в принципе запретить использование SOCKS5 и заблокировать его.
- Логин и пароль для авторизации передаются в открытом виде.
- Если ваше Telegram-приложение получало с помощью ранее описанных методов IP-адреса временных серверов, то при включении SOCKS5-прокси, приложение будет пытаться подключаться именно туда. Так как владельцы прокси, специализирующихся на Telegram, обычно блокируют соединения со всеми адресами, кроме основных подсетей Telegram, у пользователя могут иногда возникнуть проблемы с подключением.
На данный момент в боте @FCK_RKN_bot из-за ограничений и нестабильности бетаверсии MTPROTO-прокси доступен ТОЛЬКО для пользователей приватных прокси. Как только выйдет официальный релиз от Telegram, они станут доступны всем пользователям, как и SOCKS5-прокси.
Чтобы активировать MTPROTO прокси, нужно нажать в боте на кнопку “Получить прокси” => “Получить MTPROTO прокси” => “Включить” в диалоге настройки прокси.
P.S. MTPROTO на данный момент поддерживает ТОЛЬКО последняя версия Telegram для Android и Mac OS. Для остальных платформ обновление еще не вышло. Мы оповестим, как только оно станет доступно.
Чтобы поделиться с друзьями ботом для обхода блокировки телеграм, отправьте им ссылку https://t-do.ru/FCK_RKN_bot
MTPROTO-прокси
Наконец-то мы подошли к тому, чего вы так долго ждали.
Начнём с того, что любой MTPROTO-прокси — самый что ни на есть реверс-прокси. Это значит, что в отличие от SOCKS5, клиент не просит прокси достучаться до какого-то Telegram-сервера. Клиент общается с MTPROTO-прокси так, будто это уже Telegram-сервер.
Официальной документации по MTPROTO-прокси нет до сих пор, хотя в клиентах функциональность реализована давно. Некоторые умельцы написали свои реализации серверов, изучив исходный код клиентов.
MTPROTO-прокси-сервер просто принимает пакеты от клиента и отправляет Telegram-серверу. Обманула, не так просто. Давайте разберёмся.
Во-первых, клиент общается с MTPROTO-прокси только с обфускацией obfuscated2.
Во-вторых, obfuscated2 здесь используется чуть модифицированный. Перед зашифрованной частью всё так же открыто передаются ключ и IV, только вот шифруется сам пакет не этим ключом, а sha256(key+secret). Secret — это тот самый 16-байтовый параметр, который вы заполняете при подключении к MTPROTO-прокси.
Secret нигде не передаётся в процессе связи. Его использует клиент для шифрования пакета и MTPROTO-прокси-сервер для расшифрования.
MTPROTO-прокси-сервер получает от вас пакет, деобфусцирует его ключом sha256(key+secret), затем снова обфусцирует, но уже используя обычный obfuscated2 без дополнительных параметров.
Таким образом получается, что сторонний человек никак не может деобфусцировать и классифицировать трафик между клиентом и MTPROTO-прокси-сервером.