Подключение к tilde.team:5222 со STARTTLS из AS8369 (Интерсвязь is74).
xmpp_tilde.team_5222_starttls_block_Intersvyaz.pcapng (6.4 KB)
Подключение к OVH Германия (сервер АнтиЗапрета 51.38.124.100), настроенный на перенаправление трафика к xmpp.jp:5222
xmpp_ovhde_5222_starttls_block_Intersvyaz.pcapng (2.7 KB)
Как минимум, регионы GRA и WAW OVH подобной фильтрации не подвергаются.
Всё, на моих каналах перестали блокировать 2023-10-15T15:05:00Z
Опять началось 2023-10-15T15:11:00Z
Буквально час назад началась блокировка на Ростелеком (Онлайм) Москва.
Причем, как и в случае с VPN, фильтрации подвергается только IPv4. На IPv6 блокировок нет.
В этих дампах нет SNI в ClientHello. Может это не нравится ?
типа jabber.ru православный, а другие непонятно какие нарушают закон о мессенджерах ?
Тестят.
На 3 spb провайдерах и теле2 блокировки нет.
Не забываем, что у жаббера есть старый вариант без starttls. На tilde.team порт 5223 отвечает, можно попробовать через него без starttls
MTS HOME(MGTS) GPON москва
openssl s_client -host tilde.team -port 5222 -servername tilde.team -starttls xmpp < /dev/null &>/dev/null && echo ok || echo fail
fail
На текущий момент 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
Неужели это всё из-за торговли? Осторожнее надо быть обычным пользователям с непопулярными мессенджерами. Я бы даже тестить боялся теперь этот jabber.
https://notes.valdikss.org.ru/jabber.ru-mitm/
Доброго всем, извиняюсь за некропостинг, но по теме.
Держу семейный мини-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’ом, результаты прикладываю:
Подскажите пожалуйста, это вообще что, блокировка? И что дальше делать, пинать/менять провайдера, или кого ещё, или перевозить сервер куда-нибудь на 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. Подробности бесполезны, детали блокировки меняются быстрей сообщений на форуме.