А морда лица не треснет: купить VPS для того, чтобы иметь нормальный Internet с заморочками? И не факт, что и это окошко не прикроют в ближайшее время? И никто при этом не отменяет оплату услуг провайдера.
С ностальгией вспоминаю звуки хендшейка модема 14400/V42Bis. Тогда никто ничего не блокировал.
И чем тебе это поможет?) ТСПУ и сорм видят сни, а у РТ например сервачки днс намного быстрее, чем тот же дох 1111 или тем более 8-ки, можно найти и те , что отдают фб с инстой если поискать, фигня это все короче.
А локальный кеширующий stub резолвер с serving stale ещё быстрее.
Не, я чекал с адгвардом, быстрее чем у прова моих днс нету в природе.
В 1992-ом году? Что блокировали?
WG с локальными dns провайлера?
В 1993 у меня уже была BBS и нода в FIDONet. Ваш пост про 1997 год не катит. И еще потому, что в эти годы я делал это всё в Риге.
да хоть что, но с учетом блокировок динамик на тспу например DO из-за связи с DHT пирами мне проще все пускать через warp, днс рт на моей памяти не резолвят btdig и dnsleak, тут без doh никуда, это то , что я заметил.
Альтернатива - не иметь его вообще.
Если это кому-то подходит - они будут только рады
Убил целый день на подбор TTL для фейковых пакетов, так и не осилил.
По трассировке до места назначения 16 узлов (хопов):
Трассировка маршрута к rezka.ag [82.221.104.145]
1 <1 мс <1 мс <1 мс 192.168.1.1
2 1 ms 1 ms 1 ms 10.110.4.1
3 1 ms 2 ms 1 ms 100.64.200.93
4 1 ms 1 ms 1 ms 100.64.200.109
5 1 ms 1 ms 1 ms My.I.S.P
6 6 ms 6 ms 6 ms ae14-212.RT.ES.VOZ.retn.ru [139.45.244.217]
7 42 ms 42 ms 42 ms ae1-1.rt.irx.vie.at.retn.net [87.245.232.2]
8 58 ms 58 ms 58 ms ae11-61.cr3-vie2.ip4.gtt.net [213.39.66.201]
9 58 ms 55 ms 56 ms ae9.cr6-fra2.ip4.gtt.net [141.136.110.41]
10 * * * Превышен интервал ожидания для запроса.
11 * * * Превышен интервал ожидания для запроса.
12 135 ms 134 ms 118 ms 212.221.99.186
13 120 ms 126 ms 134 ms 10.142.3.251
14 156 ms 156 ms 143 ms 10.142.36.104
15 157 ms 154 ms 137 ms 82.221.168.229
16 157 ms 156 ms 145 ms 10.120.255.212
17 148 ms 156 ms 148 ms casper.is [82.221.104.145]
Логично предположить, что TTL для фейков должен быть где-нибудь до 8 хопа, где начинается иностранная магистраль. Без ограничений фейки с задачей справляются, есть четкий признак работы: Hello Retry Request, Change Cipher Spec и затем RST. Сервер отвечает, но сходит с ума от потока мусора и сбрасывает соедиение.
Но блин, ни 14, ни 24 TTL просто не работают! То есть от меня идет куча ретрансмитов, а от сервера практически ничего, тишина и редкие ACK, но они приходят и без вмешательства winws. Заодно выяснил на практике, что большинство фулингов также не работают (как минимум со стандартными параметрами), об этом точно писали раньше в разных темах.
Что я делаю не так?
upd: аргументы winws.
--wf-raw-part=@"windivert_part.rezka.txt" ^
--filter-tcp=443 ^
--dpi-desync=fake ^
--dpi-desync-fake-tls-mod=none
---
outbound and ip and
tcp.DstPort=443 and
(ip.DstAddr=82.221.104.145)
Низкий TTL начали блокировать ещё с октября. Подбирайте страту без TTL
Резка открывается хостфейксплитом (любой хост, только не из чёрного списка) с ttl=5. Резка в чёрном списке. Если коробка видит rezka, то блокирует всё соединение. Задача не подсунуть фейк с белым сни, а сокрыть настоящий. Простая отправка фейка не скрывает настоящий clienthello, который после фейка следует.
Вижу везде упоминание про работающие стратегии для CDN и хостингов для лечения дропа после 16-20кб, пытался собрать что-то похожее:
-filter-tcp=443 --ipset=“/opt/zapret/ipset/cdn_ipranges.txt” --dpi-desync=hostfakesplit --dpi-desync-fooling=ts --dpi-desync-fake-tls=“/opt/zapret/files/fake/tls_clienthello_mail_ru.bin” --dpi-desync-ttl=5
Здесь fake-tls от e.mail.ru, 17-й из YTBystro (17 из YtDisBystro/Bin at main · Storik4pro/YtDisBystro · GitHub )
Прочитал уже кучу тем, и вроде везде все у всех получается, но конкретики найти не могу… Подскажите пожалуйста пример стратегии, которая хоть у кого-то работает на z1/z2? Хотя бы в личку
И нужно ли обязательно искать / дампать хендшейк от сайта с белым SNI для каждого диапазона IP отдельно или есть относительно универсальные? И каким образом лучше всего находить белые SNI по диапазонам?
Тут каждому своё, мне например помогает огромный overlap, что странно - с дампом stun.
–dpi-desync=split2 –dpi-desync-split-pos=1 –dpi-desync-split-seqovl=740 –dpi-desync-split-seqovl-pattern=/opt/zapret/files/fake/stun.bin
Да, такой поток лишних данных не круто, но когда другое не работает, то что поделать.
Судя по всему, так и есть, но мне нужно было провести дополнительные тесты, чтобы понять логику работы ТСПУ.
Это верно. Но в моем случае фейк с достаточно высоким ttl (от 32) вполне себе пробивает дорогу к серверу. Это говорит о том, что одним из триггеров для DPI является именно низкое время жизни пакета, но далеко не единственным.
Я делаю этот вывод потому, что пробовал слать мусор в сторону VK с таким предположением: если фильтр видит подозрительный пакет, то следующие не анализирует и просто сбрасывает соединение. Но VK работает, если ограничивать TTL и ломается, если фейки до него доходят.
Значит, фильтр не настолько примитивен и действительно смотрит на следующие за подозрительным пакеты, среди которых и CH. Я пробовал его скрывать с помощью multisplit(pos=2/midsld) и multidisorder(pos=2/midsld), но безуспешно.
Самое поразительное здесь то, что чистый multidisorder(pos=2) работает.
Из чего делаю вывод, что использование мусора в целях обхода фильтруется намного агрессивнее.
Сайты порой сами по себе “универсальные”.
site.org на одном хостинге, www.site.org на другом, а картинки и видео загружаются с cdn.site.org на третьем.
Никто не будет постоянно сидеть и проверять на каком хостинге сайт сегодня и перекидывать из одного белого списка в другой.
Но брать всё же лучше фейк от сайта на блокируемом хостинге, а не от российского сайта который никогда зарубежные хостинги использовать не будет.
Чтобы проверить SNI нужна рабочая стратегия.
Чтобы найти рабочую стратегию нужен SNI.
В некоторых случаях, чтобы проверить SNI, достаточно через curl его подложить, если сервер настроен для работы только одного сайта (независимо от SNI выдаёт одно и то же). Но увы, не универсально, сперва такой сервер надо найти, а на нём найти большой файл для дёрганья и замера блока 16к
ты это сам придумал или скопипастил где?
самое странное что это жуткое васянство в самом деле помогает для tls1.3 на 443tcp
а вот для 1.2 уже нет . блоченые не открывает. но хоть неблоченые не ломает
а если ещё точнее не открывает блоченые на 443tcp +tls1.2, если порт не 443 до помогает
это я всё к тому, что хочу понять ты сам то понимаешь суть это стратегии? судя по seqovl=740 не очень то…
но с другой стороны а вдруг… не пытался в виде
--dpi-desync-fake-tls=[+ofs]@<filename>
этот bin юзать? у меня както не вышло… но надежду прикрутить этот способ к tls1.2+443tcp пока не утратил. может у тебя както получалось?
Ой, а вы премией поделитесь за фикс стратегии, тщ майор? Так то человек может и с ИИ делает, но иногда находки у него прямо скажем достойные басен Крылова, если вы понимаете о чём я :Ж)
Я уже давно вышел из молодежного возраста и плохо разбираюсь в этих ваших компуктерах и слэнгах. Но достаточно, чтобы мне в голову лезли всякие глупые вопросы.
Хочу добитьэту тему и вот вам новые вопросы.
Допустим, нет своего VPS. Нету и точка. Можно ли установить на комп локально какой-нибудь Unbound или что-то похожее и настроить его как рекурсивный резолвер, чтобы уже он обращался к корневым DNS вместо провайдерского резолвера? В Network Manager прописываем DNS 127.0.0.1 и пользуемся.
И если ответ положительный, то можно ли поменять порт для DNS с 53 на какой-нибудь другой, в надежде что нас не заметят или даже использовать шифрование?