На текущий момент 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/
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’ом, результаты прикладываю:
- Марьино.нет, соединения нет
ws_quicksy_srv_rst.pcapng (11,3 КБ) - 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. Подробности бесполезны, детали блокировки меняются быстрей сообщений на форуме.