Учитывая статистический подход к анализу трафика, где кучу параметров у TLS/TCP анализируется - будто хорошей идеей становится гонять трафик на высоких UDP портах, который вообще ни на что не похож абсолютно. Потому что одна ошибка в маскировке (неправильный SNI, fingerprint и прочее) буквально сразу триггер для DPI и после VLESS серверов с условным махом на 8443 порту начинается naive proxy и прочая дичь. Кроме того, не забываем, что VLESS априрори для обхода блокировок используется, чего не скажешь о древних openvpn/l2tp+ipsec, которые классика для корпоративных туннелей, которые после недавно сломанного эквайринга побаиваются трогать. Wireguard с трудом сюда еще проходит. В общем я о том, что небольшое количество понятного трафика классических L2-L3 туннелей могут стерпеть, чем кривую маскировку. Так что все эти шаблонные настройки для VLESS ток упрощают работу по тому, чтобы найти и вычислить и не можешь нормально замаскироваться - просто не будь похожим не на что, hyseria2 + salamander/awg2.0 в помощь.
В целом, самый лучший домен для маскировки, если своего нет - любой не заблокированный сайт, у которого кучу CDN и есть местные сервера практически в каждой стране.
В вайтлистовой зоне будет работать хоть MTproto, хоть WG или даже openvpn Но только если у сервера откуда-то белый IP. Жаль что все разгоняют дезинфу и не понимают, что БС (как минимум на йоте/мегафоне) работают на L3-L4, а не L7 и DPI никакого там нет, все решается операторским маршрутизатором с небольшим списков разрешенных префиксов. Оттуда и всякие max/vk в нидерландской подсетке
Ток 1го вместе с MTproto отвалился не wireguard, а shadowsocks на том же сервере. Хотя hysteria2 я бы поставил, ибо говорят, что работает быстрее. А как VLESS советуют настраивать обычно в интернете - самый лучший способ отправить подсети хостеров в бан (откуда 8443 порт взяли, и что за max.ru на зарубежной AS?)
В статье сказано, что он и src адрес клиента вместе с RST инжектит. Можно только аномальному TTL определять, но я не знаю, как можно реализовать эффективный алгоритм, который не будет сжирать все ресурсы сервера.
Скорее всего сейчас сезон охоты на TCP протоколы, в итоге режут все то, что хоть как-то отличается от нормального TLS трафика. Из каждого утюга говорят, что надо vless ставить, а потом делают фатальные ошибки, вроде не 443 порта и домена, который ну никак не может в Нидерландах/Финляндии быть)) В итоге сижу с WG, на него ноль жалоб. В крайнем случае хватает клиент с обфускацией handshake пакетов поставить. Учитывая всю ситуацию, выкорчевал все от 3x-ui с сервера, xray и позакрывал порты. Просто мне рассказывали историю, как чувак поднял у 62yun vless, в итоге на следующий день бан IP (даже SSH не работает) при двух пользователях.
В теории можно, RST от DPI можно отличить от здоровых (TTL, время прилета), но по факту может получится такое, что будет кучу зависших соединений и придется руками чистить (а если забудешь почистить, то уже хостер может сервер тормознуть, ибо в ToS есть лимит на количество соединений). Я помню через conntrack глянул, ранее было по 50-80 соединений вечером, когда все сидят. А когда мне написали, что с прокси что-то не так, увидел 1500+. Пересоздал прокси, думал слили в паблик. Но когда с одного клиента набрал 120, понял откуда 1,5к было. Вообще странно, что при фильтре на установленные соединения столько выпадает, когда вроде как RST был отправлен и надо прекращать. Наверное алгоритм у прокси чем-то на brutal у hysteria похож (что в свою сторону лишнее палево), но в случае TCP это уже работает больше, как SYN флуд для самого сервера.
Просмотр TCP dump дал понять, что ТСПУ массово высылают TCP RST от имени клиента. Говорят что блокируют по fingerprint клиента telegram, только вот на втором сервере из той же AS перестал работать outline (shadowsocks) с такими же симптомами (вроде как соединение есть, но по факту не работает и в дампе RST. При этом различные UDP протоколы работают так, будто ничего не происходит. Ох зря я это написал, сейчас в минусах утопят
Потому, что если ты разворачиваешь TCP протокол на сервере, то соизволь его настроить так, чтобы у тебя ответ был нормальный, при сканировании (либо хотяб не отвечать как xray). Тот же wireguard молчит, если просто попробовать постучаться на его порт. Каких вредных советов я только не видел, прописать в SNI левой AS какой-нибудь ру домен. А маскировочный сайт на сервере... Единственное руководство на ютубе - там лепят сайт на example.com на 443 порту (как надо), а потом закачиваем влессом на 8443 порту с sni ру сайта. В целом, тут сайт не нужен, потому что смысл маскировочного сайта: при попытке сходить на SNI без ключа xray ты получишь сайт. А еще TCP соединение можно прибить, если отправить в обе стороны TCP RST, минимальная нагрузка для DPI (особенно когда все выбирают 443 порт или 8443, а не случайный UDPшный)
А есть возможность развернуть AWG 2.0 на сервере в дополнение к существующему ванильному WG? Так понимаю, это все будет работать просто на уровне разных интерфейсов, типа wg0/wg1/etc
Как бы меня не бесил оригинальный клиент телеграма, но с такими новостями вообще никакие сторонние использовать желания нет. После ios обновления при использовании любых обходов (на роутере, прокси внутри и буквы на телефоне) чаты прогружаются секунд 10-15, телефон при этом на 8 gen 1
За три года меня ничего не просили сделать, это первое. Правилами хостинга запрещены только публичные впн, к которым может подключится кто угодно. АЕЗА в свою очередь главный источник сообщений о мертвом wireguard, там все настолько плохо, что даже внутри страны нет коннекта. Подозреваю что вся аеза просто на карандаше у тспу из-за огромного количества квн сервисов на их серверах там ранее.
Остальные протоколы давно неработоспособны: WG валится на первых 92 байт уже года 2 как
А что я не так делаю, что WG года три уже стабильно работает на одном сервере? Только один месяц были проблемы на домру, а в остальном все гладко и сейчас интервал rekey стал стабильно 2 минуты, а раньше раз в 20 секунд было.
Ко мне попадалось уже два графических китайских планшета с Type c, использовал 2.0 кабель baseus с маркером на 100вт. Ни один из планшетов не работал (и не важно какой из разъемов type c на ноутбуке)
Белые списки делаются только так, набор разрешенных префиксов подсетей.
Учитывая статистический подход к анализу трафика, где кучу параметров у TLS/TCP анализируется - будто хорошей идеей становится гонять трафик на высоких UDP портах, который вообще ни на что не похож абсолютно.
Потому что одна ошибка в маскировке (неправильный SNI, fingerprint и прочее) буквально сразу триггер для DPI и после VLESS серверов с условным махом на 8443 порту начинается naive proxy и прочая дичь.
Кроме того, не забываем, что VLESS априрори для обхода блокировок используется, чего не скажешь о древних openvpn/l2tp+ipsec, которые классика для корпоративных туннелей, которые после недавно сломанного эквайринга побаиваются трогать. Wireguard с трудом сюда еще проходит. В общем я о том, что небольшое количество понятного трафика классических L2-L3 туннелей могут стерпеть, чем кривую маскировку.
Так что все эти шаблонные настройки для VLESS ток упрощают работу по тому, чтобы найти и вычислить и не можешь нормально замаскироваться - просто не будь похожим не на что, hyseria2 + salamander/awg2.0 в помощь.
В целом, самый лучший домен для маскировки, если своего нет - любой не заблокированный сайт, у которого кучу CDN и есть местные сервера практически в каждой стране.
В вайтлистовой зоне будет работать хоть MTproto, хоть WG или даже openvpn
Но только если у сервера откуда-то белый IP.
Жаль что все разгоняют дезинфу и не понимают, что БС (как минимум на йоте/мегафоне) работают на L3-L4, а не L7 и DPI никакого там нет, все решается операторским маршрутизатором с небольшим списков разрешенных префиксов.
Оттуда и всякие max/vk в нидерландской подсетке
Как и wireguard, ага
Ток 1го вместе с MTproto отвалился не wireguard, а shadowsocks на том же сервере. Хотя hysteria2 я бы поставил, ибо говорят, что работает быстрее.
А как VLESS советуют настраивать обычно в интернете - самый лучший способ отправить подсети хостеров в бан (откуда 8443 порт взяли, и что за max.ru на зарубежной AS?)
В статье сказано, что он и src адрес клиента вместе с RST инжектит. Можно только аномальному TTL определять, но я не знаю, как можно реализовать эффективный алгоритм, который не будет сжирать все ресурсы сервера.
Скорее всего сейчас сезон охоты на TCP протоколы, в итоге режут все то, что хоть как-то отличается от нормального TLS трафика.
Из каждого утюга говорят, что надо vless ставить, а потом делают фатальные ошибки, вроде не 443 порта и домена, который ну никак не может в Нидерландах/Финляндии быть))
В итоге сижу с WG, на него ноль жалоб. В крайнем случае хватает клиент с обфускацией handshake пакетов поставить. Учитывая всю ситуацию, выкорчевал все от 3x-ui с сервера, xray и позакрывал порты. Просто мне рассказывали историю, как чувак поднял у 62yun vless, в итоге на следующий день бан IP (даже SSH не работает) при двух пользователях.
В теории можно, RST от DPI можно отличить от здоровых (TTL, время прилета), но по факту может получится такое, что будет кучу зависших соединений и придется руками чистить (а если забудешь почистить, то уже хостер может сервер тормознуть, ибо в ToS есть лимит на количество соединений). Я помню через conntrack глянул, ранее было по 50-80 соединений вечером, когда все сидят. А когда мне написали, что с прокси что-то не так, увидел 1500+. Пересоздал прокси, думал слили в паблик. Но когда с одного клиента набрал 120, понял откуда 1,5к было. Вообще странно, что при фильтре на установленные соединения столько выпадает, когда вроде как RST был отправлен и надо прекращать.
Наверное алгоритм у прокси чем-то на brutal у hysteria похож (что в свою сторону лишнее палево), но в случае TCP это уже работает больше, как SYN флуд для самого сервера.
Просмотр TCP dump дал понять, что ТСПУ массово высылают TCP RST от имени клиента. Говорят что блокируют по fingerprint клиента telegram, только вот на втором сервере из той же AS перестал работать outline (shadowsocks) с такими же симптомами (вроде как соединение есть, но по факту не работает и в дампе RST.
При этом различные UDP протоколы работают так, будто ничего не происходит.
Ох зря я это написал, сейчас в минусах утопятСамое простое для уничтожения - TCP с одинаковыми fingerprint из гайдов, которые еще и левый домен в sni пишут
Потому, что если ты разворачиваешь TCP протокол на сервере, то соизволь его настроить так, чтобы у тебя ответ был нормальный, при сканировании (либо хотяб не отвечать как xray). Тот же wireguard молчит, если просто попробовать постучаться на его порт.
Каких вредных советов я только не видел, прописать в SNI левой AS какой-нибудь ру домен. А маскировочный сайт на сервере... Единственное руководство на ютубе - там лепят сайт на example.com на 443 порту (как надо), а потом закачиваем влессом на 8443 порту с sni ру сайта. В целом, тут сайт не нужен, потому что смысл маскировочного сайта: при попытке сходить на SNI без ключа xray ты получишь сайт.
А еще TCP соединение можно прибить, если отправить в обе стороны TCP RST, минимальная нагрузка для DPI (особенно когда все выбирают 443 порт или 8443, а не случайный UDPшный)
А есть возможность развернуть AWG 2.0 на сервере в дополнение к существующему ванильному WG?
Так понимаю, это все будет работать просто на уровне разных интерфейсов, типа wg0/wg1/etc
Как бы меня не бесил оригинальный клиент телеграма, но с такими новостями вообще никакие сторонние использовать желания нет.
После ios обновления при использовании любых обходов (на роутере, прокси внутри и буквы на телефоне) чаты прогружаются секунд 10-15, телефон при этом на 8 gen 1
А есть ли сейчас какие-нибудь доступные способы проверки, через какой клиент сидит твой собеседник? Или вообще никак?
За три года меня ничего не просили сделать, это первое. Правилами хостинга запрещены только публичные впн, к которым может подключится кто угодно.
АЕЗА в свою очередь главный источник сообщений о мертвом wireguard, там все настолько плохо, что даже внутри страны нет коннекта. Подозреваю что вся аеза просто на карандаше у тспу из-за огромного количества квн сервисов на их серверах там ранее.
И в чем дружба с ркн по вашему заключается?
Оба сайта без раздельного туннелирования не открылись просто, но при этом UDP из диапазона 40000-45000 и AS42532 не блокируется.
Почему-то у меня ничего не режется и внутри, и в наружу.
А что я не так делаю, что WG года три уже стабильно работает на одном сервере? Только один месяц были проблемы на домру, а в остальном все гладко и сейчас интервал rekey стал стабильно 2 минуты, а раньше раз в 20 секунд было.
Ко мне попадалось уже два графических китайских планшета с Type c, использовал 2.0 кабель baseus с маркером на 100вт. Ни один из планшетов не работал (и не важно какой из разъемов type c на ноутбуке)