Ну судя по тому, что я обнаружил выше, как-то сложно соотнести блокировку к какой-то сигнатуре в виде кучи нулей и рандомных английских букв.
Посмотрите последние сообщения в теме Блокировка шифра в сторону Cloudflare на ТСПУ - #32 by 0ka
Тоже ловили сигнатурой одно, а поймали другое…
В той теме блокировка происходила хотя бы на основе каких-то полезных данных в пакете, а тут соединение блокируется даже без какой либо смысловой и полезной нагрузки.
На сервере:
ncat -klu 7777 -v --sh-exec "echo -n 'Aaaaaaaaaa/aaaaaaaaa/aaaaaaaaa'"
На клиенте:
nping --udp --data "0a0d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" -c 5 -g 23712 -p 7777 X.X.X.X
2-3 пакета и ТСПУ блокирует соединение.
Я не настоящий сварщик, но уверен, что ТСПУ “все равно”, есть в пакете полезная нагрузка или нет. Оно срабатыает либо по спискам адресов, либо по сигнатурам. В вашем случае, видимо, срабатывает сигнатура. Делать сложный анализ пакетов в массовом пордке - дорого, в терминах нагрузки на процессор, поэтому делают анализ максимально простым. В вашем слуае - сделали правило типа “если в запросе первые байты 0x0a0d, а в ответе 7 и 17 байты - буквы ‘а’ - заблокировать”. И в 99.9% случаев это срабатывает - блокируется только вредный, преступый, террористический трафик.
Выходов два - писать в Спортлото, чтобы поправили сигнатуру, или поправить протокол.
Если переделывать протокол - я бы предложил его зашифровать, без фанатизма - просто ради того, чтобы не было повторяющихся частей, за которые может зацепиться это или какое-то следующее правило.
(Пишу это в основном для того, чтобы, если неправ, меня поправили настоящие сварщики.)
Там срабатывает на любые буквы вообще, возможно используется регулярка, не дорого ли для процессора делать регулярку в этом случае?
Ну зная, как “работают” разработчики этой игры, не думаю что они возьмут и на “ура” сделают это самое шифрование.
Возможно, содержимое не учитывают совсем или всё чуть сложнее. Блокировка воспроизводится для небольших датаграмм с рандомной нагрузкой. Исходящие размером 55-74 байт, входящие 20-100 байт. Схема: запрос-ответ. После 2-3 ответов следует блокировка.
Если отправлять только нули с размерами 55-74 байт со стороны клиента, 20-100 байт со стороны сервера, то блокировка не происходит.
Тут скорее всего всё в разы сложнее.
Блокировка воспроизводится даже вот так, без рандомных данных:
Сервер:
ncat -klu 7777 -v --sh-exec "echo -n '1110000000000000000000000000000000000000' | xxd -r -p"
Клиент:
nping --udp --data "11100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" -c 5 -g 23742 -p 7777 X.X.X.X
Наблюдение: Множество ТСПУ где сейчас блокируют (блокировали) XMPP пересекается с множеством ТСПУ блокирующих UDP пакеты из этой темы. Притом обе блокировки встречаются достаточно редко, примерно как ТСПУ в байпасе.
Из этого сообщения у меня команда 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 выдаёт fail
EDIT: Прошу прощения, допустила ошибку при тестировании. Подтверждаю - у меня наблюдается и блокировка VPN, и блокировка XMPP, и блокировка по примерам из данной темы.
Еще, мне кажется что дело не в каком-то “множество ТСПУ”. У меня есть наблюдения, позволяющие полагать, что дело не в конкретных ТСПУ, а в неких черных списках. Предполагаю, что есть некие черные списки, в которые заносятся IP-адреса как источника (пользователей интернета), так и назначения (серверов в интернете). Заносятся они туда видимо по выявлении некой запрещенной активности, и по факту занесения туда коннекты от/к ним подвергаются более глубокому анализу.
Например, у меня сейчас наблюдается блокировка XMPP в сторону вышеупомянутого quicksy.im. Но в сторону моего личного сервера, коннекты к которому я некоторое время назад завернула в VPN и ТСПУ их не видит, блокировки сейчас нет, даже если выключить VPN.
При этом quicksy.im блочится с моего проводного провайдера, но работает через мобильную связь. Тут важно, что у меня статический IP у провайдера уже несколько лет.
Еще пример, я несколько лет активно пользуюсь OpenVPN, и с прошлой осени постоянно попадаю на блокировки. Сейчас наблюдаю блокировку перманентно уже на протяжении месяца. В то время как условно мои соседи с тем же провайдером - у них все работает, и они удивляются и утверждают, что никаких блокировок нет. Тут тоже важно, что у меня статический IP у провайдера уже несколько лет.
Мой коллега по работе попал под блокировку корпоративного (!) OpenVPN внутри (!) РФ , долго мучался, но стоило ему сменить IP у провайдера - все стало ок.
У меня не блокируется OpenVPN и WireGuard.
Я взял абсолютно случайную VDS в аренду из рандомной локации, на ней так же воспроизводятся блокировки по UDP из данной темы.
Смена BRAS или адреса может изменить маршрут и как следствие ТСПУ, зависит от топологии сети оператора. Обойти черные списки сменой адреса, не меняя сетевого поведения, можно было бы лишь кратковременно. В противном случае это лишает их смысла, там же не ручная работа. Существование кратковременных списков адресов-источников для отдельных правил задокументировано.
Ну я просто не знаю, как еще объяснить то, что у меня наблюдаются ВСЕ возможные блокировки, кроме того, что мой IP “взяли на карандаш”. Причем, у меня два разных проводных провайдера в Dual WAN конфигурации, на обоих статический IP, и на обоих идентичное поведение в плане блокировок
Да, еще хочу отметить, про тестирование блокировки игры. Есть некий временной лаг до начала блокировки. Сначала я сделала 2 теста отправкой по 25 пакетов - и все успешно прошло, никаких блокировок (из чего я первоначально сделала неверный вывод что у меня этой блокировки нет). Через некоторое время я повторила тесты, и тут уже все последующие соединения начали блокироваться после 2-3 пакета.
Такого не замечал, я замечал лишь только другой лаг, что соединение может заблокироваться после 3-4 пакетов на первый раз, а последующие разы будут 2-3 пакета.
По описанию прям похоже на “липкие блокировки” из Китая начиная с 2018 эдак года. Там на примере SS и мимикрии под HTTPS решили, что блекхолить трафик глупо и опасно(сервер меняется за пару минут при готовых скриптах автоматизации, а сетевая связанность остаётся поломанной) начав привязывать блок к источнику трафика и экспоненциально увеличивать время блока. Тот же SS при обнаружении для юзера блокировался сначала на пару минут, потом десятков, потом часов и тд. При этом другой юзер того же провайдера с тем же маршрутом трафика мог спокойно подключаться(первое время конечно, потом та же схема с детектом и баном на время)
Если кому-то будет интересно проверить работу блокировки непосредственно прямо в игре:
- Скачиваем игру из Steam - SCP: Secret Laboratory on Steam, она бесплатная
- В списке серверов находим сервер Runic Library ENIGMA и подключаемся к нему, или же по прямому подключению -
185.9.145.157:7780
Остальные сервера Runic Library идут с применением nfqws, для Enigm’ы я сделал исключение.
P.S. Некоторые крупные проекты уже применили nfqws.
Чуть поисследовал фильтр. Он, прежде всего, заточен на обнаружение пакетов определённых размеров. От клиента ожидается от 51 до 90 байт (цифры не точные), а от сервера — от 20 до 30 (тоже не точные).
Также во внимание принимается pacing пакетов. Первые два байта, судя по всему, должны быть без первого бита у двух первых байт, чтобы блокировка срабатывала.
У себя в регионе заметил, что фильтр будто бы смягчили, перестало блокироваться бессмысленное содержимое, теперь блокировка воспроизводится только вот этим:
На сервера в игре теперь нормально впускает.