Обсуждение: Блокировка Jabber/XMPP в России

На текущий момент tilde.team XMPP недоступен c Интерсвязь is74 AS8369 и Dom.ru AS50544.

tilde.team:5222 XMPP STARTTLS блокируется на провайдере sknt.ru , только на части подключений (1 из 2 точек работает, другая нет), только по ipv4

при этом

подключение со SNI tilde.team к другому серверу - в порядке
tilde.team:5223 XMPP без STARTTLS в порядке
другие XMPP STARTTLS в порядке
еще 2 провайдера в спб - в порядке

тренируются ?

Ждет два входящих stream. Парсит (как минимум, наличие: id, version, xml:lang, xmlns:stream, from). С одним входящим stream: не заблокирует (stream:features должны прилетать отдельным пакетом). Затем ждет 2 любых исходящих и блокирует сессию (заменяет на RST входящие). Счетчики и направление возможно применяют разные. Блокируемые диапазоны неизвестны, рандом для наблюдателя.

По другой версии ограничено суммарное число сегментов для XMPP сессии. Или более сложное правило, вырождаемое для отдельных случаев в 2 исходящих. Наблюдалось 3, 1 (все заканчивалось на STARTTLS). Возможно дело просто в latency блокировщика.

Все не так.

Рабочие сэмплы.
Client:

stream:stream xmlns:stream=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Server:

stream:stream id=xxxxxxxxxxxxxxxxxxxxxx version=xxxxx xml:lang=xxxxx xmlns:stream=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx from=xxxxxxxxxx

где x – любой символ, кроме space, например x

Послать Client и принять Client не работает. Послать Server и принять Server не работает. Послать Client и принять Server работает.

При этом можно bidirectional. Например, только посылать комбинацию, и далее через N-даты будет блок. Но сэмпл нужно передать дважды: Client+Client, Client+Server, Server+Server.


У Hetzner блокируют XMPP меньше чем у OVH. jabber.ru находится в неблокируемом диапазоне, но вот conversations.im попал.

Неполный список блокируемых

135.181.0.0/16
168.119.0.0/16
188.34.128.0/17
65.108.0.0/16
88.99.0.0/16
78.46.0.0/15
94.130.0.0/16
95.216.0.0/16

https://www.opennet.ru/opennews/art.shtml?num=59965

Неужели это всё из-за торговли? Осторожнее надо быть обычным пользователям с непопулярными мессенджерами. Я бы даже тестить боялся теперь этот jabber.
https://notes.valdikss.org.ru/jabber.ru-mitm/

5 posts were merged into an existing topic: Выбор мессенджера

Доброго всем, извиняюсь за некропостинг, но по теме.
Держу семейный мини-jabber/xmpp сервер дома на одноплатнике и белом IP, так вот пару дней назад перестали проходить исходящие к некоторым xmpp-серверам, замечены аномалии с:
quicksy.im, tigase.org, jabb3r.org, возможно и больше… 5269 startTLS

Спойлер

~$ xmpp-dns -46fstv quicksy.im
xmpp-server xmpp.quicksy.im. 5269
Priority: 1 Weight: 1
IP: 157.90.245.42
Connection: [OK]
StartTLS: [Not OK]
read tcp4 192.168.1.103:36748->157.90.245.42:5269: read: connection reset by peer
~$ xmpp-dns -46fstv tigase.org
xmpp-server xmpp.tigase.tech. 5269
Priority: 20 Weight: 0
IP: 54.191.142.250
Connection: [OK]
StartTLS: [Not OK]
read tcp4 192.168.1.103:44508->54.191.142.250:5269: read: connection reset by peer
IP: 52.32.179.178
Connection: [OK]
StartTLS: [Not OK]
read tcp4 192.168.1.103:34006->52.32.179.178:5269: read: connection reset by peer
IP: 34.208.251.179
Connection: [OK]
StartTLS: [Not OK]
read tcp4 192.168.1.103:32994->34.208.251.179:5269: read: connection reset by peer
pisya@COMP3:~$ xmpp-dns -46fstv jabb3r.org
xmpp-server jabber.hot-chilli.net. 5269
Priority: 0 Weight: 0
IP: 2a01:4f8:242:56ca::2
Connection: [OK]
StartTLS: [OK]
Certificate: [OK]
IP: 49.12.125.53
Connection: [OK]
StartTLS: [Not OK]
read tcp4 192.168.1.103:45244->49.12.125.53:5269: read: connection reset by peer

Провайдер проводной - Maryno.net. Также пробовал по проводному билайну и мобильному теле2 - xmpp-dns тест работает ОК.
Послушал wireshark’ом, результаты прикладываю:

  1. Марьино.нет, соединения нет :frowning:
    ws_quicksy_srv_rst.pcapng (11,3 КБ)
  2. Tele2 мобильный, соединение есть
    ws_quicksy_srv_ok.pcapng (25,6 КБ)

Подскажите пожалуйста, это вообще что, блокировка? И что дальше делать, пинать/менять провайдера, или кого ещё, или перевозить сервер куда-нибудь на VPS?..

Да, похоже на блокировку, вероятно, по какому-то особому признаку. Предполагаю, что по ответу сервера, т.к. изменение домена и параметров в ClientHello не помогает.

openssl s_client -starttls xmpp-server -host xmpp.quicksy.im -port 5269 -xmpphost quicksy.im -servername quicksy.im </dev/null &>/dev/null && echo ok || echo fail

Node ISP AS City test 9 Apr test 10 Apr test 21 Apr
RU-001 ТТК AS8427 Magnitogorsk ok ok ok
RU-002 Интерсвязь is74 AS8369 Yemanzhelinsk ok ok ok
RU-003 МТС AS28832 Chelyabinsk fail fail fail
RU-004 МГТС AS25513 Moscow ok ok ok
RU-005 Dom.ru AS49048 Tver ok ok ok
RU-006 Dom.ru AS50544 Krasnoyarsk fail fail fail
RU-009 Линклайн AS44041 Moscow ok ok fail
RU-010 МГТС AS25513 Moscow ok ok ok
RU-011 ENEVA/OBIT AS8492 Saint Petersburg fail ok fail
RU-012 Beeline/Corbina AS8402 Tula ok ok fail
RU-013 Dom.ru AS50543 Saratov fail fail fail
RU-014 Rostelecom AS12389 Orenburg ok ok ok
RU-018 Evpanet AS43936 Krimea ok ok ok
RU-020 PJSC MegaFon AS31205 Khakasiya ok ok ok
RU-021 ER-Telecom Holding AS56981 Tomsk ok ok ok
RU-022 Sibirskie Seti AS40995 Novokuznetsk ok ok ok
RU-023 Rostelecom AS12389 Perm region ok ok ok
RU-024 Beeline AS34038 Tyumen ok ok ok
RU-025 Rostelecom AS12389 Kemerovo ok ok ok
RU-026 Rostelecom AS12389 Kemerovo fail fail fail
RU-027 Sibirskie Seti AS47433 Kemerovo ok ok ok
RU-028 Beeline AS3216 Kemerovo ok ok fail
RU-029 Rostelecom Mobile AS12389 Kemerovo (Spb SIM) ok ok ok
RU-031 Beeline AS42110 Sochi ok ok ok
RU-032 Sibirskie Seti Ltd. AS34757 Novosibirsk fail fail fail
RU-033 Yota AS31213 Saint Petersburg ok ok ok
RU-035 UBS (ubsnet.ru) AS50042 Sevastopol ok ok ok

Спасибо большое за инфу, пойду думать дальше…

Можно zapret-ом поиграться. nfqws fake, split и wssize и с ограничителем по IP
Если, конечно, они не рубят по IP

Блокировки вернулись, как уже заметили. Правило и блокируемые диапазоны адресов изменились. Активируют счетчик блокировки по исходящему, содержимое входящих не проверяют. Парсер упростился, тригернуть можно строкой:

strea stream stream xmlns

Порядок не важен, проверяют наличие двух stream, одного xmlns и strea (полный stream тоже работает).
Далее считают исходящие с любым содержимым и по небольшому рандому блокируют подключение, подменив входящие RST’ом.

Как и прежде, правило действует выборочно.

На моём ISP (AS39709) на данный момент перестало блокироваться…

Проблема сохраняется, добавил свежий тест.

Правило изменили, добавив проверку на starttls. Подробности бесполезны, детали блокировки меняются быстрей сообщений на форуме.