Comments 56
Спасибо бро
Сделал себе openvpn на сервере в РФ, и через него смотрю ютуб в основном, ну и потом решил что и с телеграм поможет - однако нет, не работает. Поставил там же мтпрокси - оп, через него как часы работало. А с недавнего времени стало вот как тут описано - то работает, то что-то думает на этапе подключения к прокси. Сейчас включил и впн и через прокси - и вроде бы сразу работает. Посмотрим, как пойдëт дальше.
openvpn вымершая технология в реалиях современной рф. Лучше использовать что-то из vless,vmess, hysteria
Как и wireguard, ага
Ток 1го вместе с MTproto отвалился не wireguard, а shadowsocks на том же сервере. Хотя hysteria2 я бы поставил, ибо говорят, что работает быстрее.
А как VLESS советуют настраивать обычно в интернете - самый лучший способ отправить подсети хостеров в бан (откуда 8443 порт взяли, и что за max.ru на зарубежной AS?)
как показыват практика, в некоторых регионах OpenVPN опять стал работать. Видимо мощностей ТСПУ не хватает, чтобы блокировать всё сразу.
А можете объяснить, пожалуйста, как российский сервер помогает смотреть ютуб, если он тоже в России? В чём причина того, что он работает? Не первый раз о подобном слышу.
Для меня самое печальное, что на мобильном интернете не работает. Только белые списки, причем даже те не в полном объеме.
Тру стори: связь с близким человеком оборвалась в самый неподходящий момент, что с большой долей вероятности уже повлекло за собой серьезные негативные последствия, и никто за это не ответит. Основные каналы связи оказались недоступны, возможности своевременно наладить запасные не было по разным причинам. Знал бы, что все сложится настолько неудачно, тот же СКАМ установил бы заранее на отдельное устройство, но окно возможностей уже закрылось. Как они там говорили? "Будем разрывать социальные связи."
Берегите себя и своих близких, ребят, дальше 100% будет становиться ещё труднее. Пока видится так, что все размышления в духе: "это временно, вот гайки закрутят, а потом новых назначат, которые приоткрутят" — это все мантры и отрицание надвигающейся действительности.
просто если гайки будут закручиваться и далее "по площадям" - то скоро в стране будет нечего есть, и тогда проблема блокировок интернета сама собой решится из-за того, что внимание будут занимать более приземлённые факторы ... в концлагере нет интернета, но никого это уже не волнует вообще
Все эти мантры про "потом гайки открутят" это самообман. Технологии контроля, единожды внедренные, никогда не убираются. Инфраструктура ТСПУ будет только расширяться и умнеть
А обычный звонок сделать не судьба?
Как это выглядит для пользователя
а как будто в виде странного «окна допуска»: несколько подключений проходят, потом идут отказы. У кого-то прокси «держится»
Что видно в логах Ключевая зацепка - логи.
Ключевое слово – нейросеть
После ClientHello соединение «глохнет»
🤮🤮🤮
Это важная деталь.
Ох, блъ, очень важная деталь, всё!
Чисто брейншторма ради: а нельзя ли чисто технически сделать TCP-over-many-TCP? Т.е. к примеру между хостом и сервером устанавливается не 1, а сразу несколько TCP соединений, на разных портах. Через каждое из которых передается только некоторая часть полезной нагрузки. Соответственно на обоих концах эти данные разбиваются по сессиям и собираются заново, по некоторому псевдослучайному алгоритму. Тогда для внешнего наблюдателя это будет выглядеть как несколько сессий с неизвестынми сигнатурами.
По-моему вы только что изобрели TOR (луковичную маршрутизацию)
Именно так)
Не вижу никакой луковичности в этих идеях.
Нет. TOR работает совсем по другому.
в TOR многослойность, а я говорю о (де)мультиплексировании потоков. Упрощенно - каждый четный байт полезной нагрузки ТСР отправляется на порт 8443, а каждый нечетный на 8444. Приложение на стороне сервера слушает оба порта, и получая данные, собирает исходную последовательность. Немного погуглив, понял, что подобная идея лежит в основе Multipath TCP (MPTCP)
Частично похоже на XHTTP с разделением потоков (а если поколдовать над конфигом XRay, то в теории даже можно сделать то что описали вы)
MTProxy через I2P работают прекрасно
VLESS+Reality работал, работает
Разработчики телеграма в курсе о проблеме?
один из участников сделал патч Telegram Desktop, минимально изменил параметры ClientHello и пересобрал клиент
Если в каком-то клиенте telegram для мобильных реализуют настройку параметров ClientHello - было бы интересно проверить.
Видел issue на это, но вроде в десктоп клиент.
А вообще имхо продуктивнее двигаться в сторону неотличимости от HTTPS. Сейчас ТСПУ в некоторых местах уже задыхаются и периодически переключаются в bypass, а с усложнением их правил фильтрации это будет происходить все чаще и чаще. Это может привести к смене парадигмы фильтрации на "блокировать все неизвестные протоколы". Тут уже не помогут самописные ClientHello или, скажем, сгенерированные параметры для AmneziaWG, только максимальная маскировка под легитимные протоколы.
а есть какой-то простой способ вычислить адрес ТСПУ, откуда RST прилетают? ну кроме как записать за день трафик и фильтровать по ттль и непрогрузкам?
В статье сказано, что он и src адрес клиента вместе с RST инжектит. Можно только аномальному TTL определять, но я не знаю, как можно реализовать эффективный алгоритм, который не будет сжирать все ресурсы сервера.
я как раз на клиенте хочу попробовать половить эти RST и заблочить. посмотреть что выйдет. как будто они однозначно определяются и таблица соединений не должна быть забита
Так-то не сложно: тестовое соединение на неправильный порт сервера и получение настоящего RST для обнаржуения TTL. Дальше фильтрация всех RST с меньшим значением TTL. Делается через firewall. Ресурсов есть не будет совсем.
Но работать будет плохо и можно и проще. Весь фильтруемый трафик у вас междунродный, а сейчас для всей страны он идёт буквально через несколько узлов. А ТСПУ стоит у провайдера. Поэтому для зарубежных адресов нужно отбрасывать все RST с TTL меньше чем до пограничного сервера. Это деает тривиальным правилом на nftables. То же правило может проверять, является ли адрес иностранным.
Но это временно. У них наязчивая идея поставить ТСПУ на пограничные сервера. В некоторых местах даже уже стоит. Но пока не хватает производительности везде и всё фильтровать.
Но и в этом случае TTL будет меньше чем у заграничного трафика.
Расположение ТСПУ, кстати, отлично вычисляется по трейсу пингов на разных протоколах. ТСПУ виден либо как кольцо в маршруте, либо по большому скачку задержки на нём . Кроме того у ТСПУ задержка и маршрут зависят от протокола - для TCP probes оно сильно чем для ICMP.
Но вообще говоря, баловство это всё.
То есть фикс для телеги будет выглядеть примерно как "перед хендшейком потрясти и передать в случайном порядке все, что только можно передавать в случайном порядке"? Если да, то что-то долго фиксят.
Там реализация ClientHello статична и не похожа на реальные браузеры. Плюс, как выяснилось, в коде была ошибка с неверным айди расширения, для ML-модели тспу такой кривой хендшейк считай красная тряпка. Как только сигнатуру внесли в базу, прокси по всей стране легли одновременно
Рано или поздно РКН задавит массой..
Вышла новая версия Telegram Desktop 6.7.2, в ней опять заработал MTProxy. Ждем фикс для Telegram Android.
Жду, когда сына поступит и выучится на кибербеза и откроет папе дырочку)
У него и сейчас всё работает)
У меня у одного стойкое ощущение, что статья написана нейронкой по типу ChatGPT?
Конец удобства? Почему MTProxy начал ломаться