Довольно грустно видеть очевидную нейро-кальку с моей статьи (+ добавление воды). Напомню, что исходная статья хоть и заблокирована РКН, но доступна через отличные от российских ip адреса.
Возможно, у вас был HTTP/1.1 в режиме keep-alive (т.е. одно TCP соединение) или же HTTP/2 (т.е. тоже одно TCP соединение). Чтобы убедиться в обратном, надо смотреть на фактический трафик, напр., через Wireshark.
использовал случайный несуществующий домен
Как при этом обстояли дела с проверкой https сертификата в браузере? Есть и другие сложности с тестированием из песочницы.
выводы в разделе "Субъективная оценка" базируются только на основе результатов тестирования посредством uTLS
Нужно уточнить, что это может помочь при "сибирской блокировке" в вариации с учитыванием фингерпринта браузера, но не для других случаев (их довольно много). А так любопытная находка, спасибо.
Впрочем, попробую обойтись экспериментом мысленного характера: В настоящее время фингерпринты примерно всех современных браузеров содержат ALPN с заявленной поддержкой как HTTP/1.1 так и HTTP/2, а также в полях/расширениях сообщения указывают поддержку TLS 1.2 и 1.3. При этом, цензор не дожидается ServerHello (т.е. не знает, какие версии предпочел сервер).
Таким образом, если мы попытаемся на клиенте эти параметры поменять, то поломаем фингерпринт и ограничений (описываемых в статье) не будет исходно. В противном случае будут, согласно алгоритму.
Дело в том, что в арсенале РКН достаточно много способов ограничений — их внедрение зависит, среди прочего, от региона, провайдера (в т.ч. мобильный это или домашний), точки назначения трафика (на различных уровнях: от L3 и выше по OSI) и к тому же меняется с течением времени. Описываемый в статье "метод" — лишь один из многих, очевидно.
Выше, надо думать, подразумевается некий лимит на один веб-ресурс (хост) в браузере. На всю то систему совсем другие лимиты.
На счет кучи подключений "в VLESS" (точнее, в клиенте), один из вариантов: просто пул соединений между клиентом и промежуточным прокси узлом сразу инициализируется на старте ради производительности, ещё до непосредственного обращения к ресурсам в сети. Потом они переиспользуются. Помимо этого, в основных клиентах есть опции аля "mux", равно как и ограничение кол-ва TCP соединений — можно поиграться.
В штатном случае такие приложения как Max стучат о том что у вас есть VPN (т.е. пассивное наблюдение сбоку), и сами по себе могут отказаться работать пока их не выключишь. Но "не должны" в моменте препятствовать работе остальной сети. Таким образом, скорее, клиенты и/или их настройки у вас таки различные на устройствах, раз уж у других работает примерно такой же конфиг и точка входа в Интернет одинакова (это ведь так?).
Если, конечно, нет какой-то дыры в VPN клиенте, которая светит наружу своё API (локально, но с доступом для всех приложений), что иногда случалось ранее и гипотетически могло бы эксплуатироваться. Но подобные трюки пока что не были замечены в потенциальном "виновнике", насколько мне известно.
С точки зрения внешнего наблюдателя нельзя не заметить, что технический арсенал цензора на данный момент впечатляет – даже несмотря на то, что поставленные задачи по ограничениям и блокировкам не решены, а частичные решения имеют заметный сопутствующий ущерб. Ознакомьтесь, хотя бы, с возможностями СКАТ от VAS Experts. Как бы ни хотелось кому-то иначе, как говорится.
Предпочтения операторов не шибко учитываются: они обязаны соблюдать российское законодательство — иначе, среди прочего, лишатся лицензий в области связи. Напр., едва ли среднестатистическому оператору нравится то, что у него установлен комплекс ТСПУ (и финансовые издержки в этой связи), однако, не он это решает, если хочет полноценно работать.
Ага, нечто подобное мы наблюдали в 2018-2020 годах, когда были "ковровые" блокировки Telegram. Более того, то, что описано в текущей статье — тоже самое, большими грубыми мазками идет работа.
У ТСПУ есть ручной байпас на случай отказа (т.е. трафик будет проходить "напрямую") — исключительно гипотетически представим, что этот вариант развития событий реализовался при данной "атаке". Однако, есть нюансы:
В это время, вероятно, вы не сможете нормально пользоваться Интернетом, т.к. ~все мощности будут направлены на "атаку" (примерно как во время скачивания торрентов без ограничений или хуже). При массовом характере такой же эффект может быть и у "соседей" по сети, или вовсе во всем Рунете;
Как только атака завершится (или вскоре после этого), байпас, вероятно, "закроется", и система перейдет в штатный режим работы;
Вы, как абонент, вероятно, будете заблокированы оператором после подобных шалостей.
Таким образом, сильно большого смысла в этом, будто бы, не наблюдается.
Существует ли инструмент, с помощью которого любой пользователь мог бы "отсканировать" свой реальный браузер и загрузить этот отпечаток в uTLS-клиент?
Напр., в xray есть нечто похожее на то, что в хотите — Browser Dialer. Других вариантов для массового пользователя быстро задать кастомный фингерпринт на основе своего браузера там нет, насколько мне известно. Хоть и uTLS, как библиотека для golang, поддерживает тонкую настройку в этом направлении, предварительно "отсканировав" свой отпечаток в ClientHello через любой сниффер вроде Wireshark (а предварительно можно оценить здесь онлайн).
Имеет ли смысл держать на vps свою домашнюю страничку и использовать её в качестве SNI?
Это может помочь, но не является, на мой взгляд, необходимым. Начать можно отсюда.
Что ещё?
Нюансов очень много, в рамках комментариев могу попробовать ответить только на более конкретные вопросы.
Ага, см. upd. от 16.06.2026 в статье.
Довольно грустно видеть очевидную нейро-кальку с моей статьи (+ добавление воды). Напомню, что исходная статья хоть и заблокирована РКН, но доступна через отличные от российских ip адреса.
Опубликовал пример тестового стенда на основе Google Chrome в статье.
Можете в личку прислать тестируемый IP?
Возможно, у вас был HTTP/1.1 в режиме keep-alive (т.е. одно TCP соединение) или же HTTP/2 (т.е. тоже одно TCP соединение). Чтобы убедиться в обратном, надо смотреть на фактический трафик, напр., через Wireshark.
Как при этом обстояли дела с проверкой https сертификата в браузере? Есть и другие сложности с тестированием из песочницы.
Не только.
Нужно уточнить, что это может помочь при "сибирской блокировке" в вариации с учитыванием фингерпринта браузера, но не для других случаев (их довольно много). А так любопытная находка, спасибо.
Впрочем, попробую обойтись экспериментом мысленного характера:
В настоящее время фингерпринты примерно всех современных браузеров содержат ALPN с заявленной поддержкой как HTTP/1.1 так и HTTP/2, а также в полях/расширениях сообщения указывают поддержку TLS 1.2 и 1.3. При этом, цензор не дожидается ServerHello (т.е. не знает, какие версии предпочел сервер).
Таким образом, если мы попытаемся на клиенте эти параметры поменять, то поломаем фингерпринт и ограничений (описываемых в статье) не будет исходно. В противном случае будут, согласно алгоритму.
В статье неявно подразумевается HTTP/1.1 с TLS 1.3. Постараюсь поэкспериментировать с другими версиями и добавить подробности в статью.
Дело в том, что в арсенале РКН достаточно много способов ограничений — их внедрение зависит, среди прочего, от региона, провайдера (в т.ч. мобильный это или домашний), точки назначения трафика (на различных уровнях: от L3 и выше по OSI) и к тому же меняется с течением времени. Описываемый в статье "метод" — лишь один из многих, очевидно.
Выше, надо думать, подразумевается некий лимит на один веб-ресурс (хост) в браузере. На всю то систему совсем другие лимиты.
На счет кучи подключений "в VLESS" (точнее, в клиенте), один из вариантов: просто пул соединений между клиентом и промежуточным прокси узлом сразу инициализируется на старте ради производительности, ещё до непосредственного обращения к ресурсам в сети. Потом они переиспользуются. Помимо этого, в основных клиентах есть опции аля "mux", равно как и ограничение кол-ва TCP соединений — можно поиграться.
Ну, я бы посмотрел что происходит на уровне сети через Wireshark и/или более дотошно сравнил конфигурации клиентов. Там может быть много чего...
В штатном случае такие приложения как Max стучат о том что у вас есть VPN (т.е. пассивное наблюдение сбоку), и сами по себе могут отказаться работать пока их не выключишь. Но "не должны" в моменте препятствовать работе остальной сети. Таким образом, скорее, клиенты и/или их настройки у вас таки различные на устройствах, раз уж у других работает примерно такой же конфиг и точка входа в Интернет одинакова (это ведь так?).
Если, конечно, нет какой-то дыры в VPN клиенте, которая светит наружу своё API (локально, но с доступом для всех приложений), что иногда случалось ранее и гипотетически могло бы эксплуатироваться. Но подобные трюки пока что не были замечены в потенциальном "виновнике", насколько мне известно.
С точки зрения внешнего наблюдателя нельзя не заметить, что технический арсенал цензора на данный момент впечатляет – даже несмотря на то, что поставленные задачи по ограничениям и блокировкам не решены, а частичные решения имеют заметный сопутствующий ущерб. Ознакомьтесь, хотя бы, с возможностями СКАТ от VAS Experts. Как бы ни хотелось кому-то иначе, как говорится.
Предпочтения операторов не шибко учитываются: они обязаны соблюдать российское законодательство — иначе, среди прочего, лишатся лицензий в области связи. Напр., едва ли среднестатистическому оператору нравится то, что у него установлен комплекс ТСПУ (и финансовые издержки в этой связи), однако, не он это решает, если хочет полноценно работать.
Ага, нечто подобное мы наблюдали в 2018-2020 годах, когда были "ковровые" блокировки Telegram. Более того, то, что описано в текущей статье — тоже самое, большими грубыми мазками идет работа.
В свою очередь, не сразу понял, где же опечатка, спасибо :)
У ТСПУ есть ручной байпас на случай отказа (т.е. трафик будет проходить "напрямую") — исключительно гипотетически представим, что этот вариант развития событий реализовался при данной "атаке". Однако, есть нюансы:
В это время, вероятно, вы не сможете нормально пользоваться Интернетом, т.к. ~все мощности будут направлены на "атаку" (примерно как во время скачивания торрентов без ограничений или хуже). При массовом характере такой же эффект может быть и у "соседей" по сети, или вовсе во всем Рунете;
Как только атака завершится (или вскоре после этого), байпас, вероятно, "закроется", и система перейдет в штатный режим работы;
Вы, как абонент, вероятно, будете заблокированы оператором после подобных шалостей.
Таким образом, сильно большого смысла в этом, будто бы, не наблюдается.
Напр., в xray есть нечто похожее на то, что в хотите — Browser Dialer. Других вариантов для массового пользователя быстро задать кастомный фингерпринт на основе своего браузера там нет, насколько мне известно. Хоть и uTLS, как библиотека для golang, поддерживает тонкую настройку в этом направлении, предварительно "отсканировав" свой отпечаток в ClientHello через любой сниффер вроде Wireshark (а предварительно можно оценить здесь онлайн).
Это может помочь, но не является, на мой взгляд, необходимым. Начать можно отсюда.
Нюансов очень много, в рамках комментариев могу попробовать ответить только на более конкретные вопросы.
Вы можете проверить это (и любой другой веб-сайт) с помощью dpi-ch, указав примерно такую конфигурацию:
У себя я ограничений Github не наблюдаю:
* Впрочем, Github есть в разделе "Popular Web Services" при штатной конфигурации — так что можно вообще ничего не менять и посмотреть там.
В теории, нечто похожее может помочь в противодействии DPI системам. Утилиты вроде zapret примерно так и работают (но не ограничиваясь этим).