кто-нибудь может подкинуть идею в чём дело или что протестить?
.
понятно что на разных провах могут быть разные dpi и следовательно стратегии и т.д.
но это касаемо “плохих” сайтов, а речь про “хороший” bspb.ru
по не понятной мне причине на основном провайдере он перестал работать с запретом. а именно если в стратегии любой из 4х вариант сегментации вкупе с fake
не открывается по таймауту и хоть тресни. а если сегментацию из стратегии убрать, то открывается
хотя казалось бы… проблемы могут быть от неправильных фуллингов, а не от сегментации
но мало того, на другом прове (правда и комп другой) этотже bspb.ru прекрасно работает и с fake,split т.е. сегментация перестаёт ломать соединение
какая-то неясная нелепость
“радует” лишь то что те блоченные сайты которым требовалась сегментация вдобавок к fake можно таки открыть если “чистый” fake репитить 4+ раза
я как то упоминал syndata?
она то может и ломает но у меня нет её
для 443 --dpi-desync=fake --dpi-desync-repeats=5 --dpi-desync-fooling=badseq,badsum и если вместо рипитов любую сегментацию после fake, идёт таймаут у банка
но что сранно тока на домашнем прове. и только недавно ~месяц. а до того не крашило+прям щас не крашит на другом прове
Подскажите, обходятся ли блокировки портов выше 1024 запретом?
Подключение на порт выше 1024 телнетом для проверки проходит, но если попытаться из браузера по HTTP, то пусто (с VPN работает). Порт 80 на том же домене работает без обхода. Использую NFQWS. Пробовал добавить в работающее правило нужный порт --filter-tcp=443,2222 --dpi-desync=fake,disorder2 --dpi-desync-fooling=badsum <HOSTLIST>
Не помогло.
Прогнал blockcheck для нужного порта в режиме HTTP (изменил порт в скрипте; да, нужен только HTTP).
Выдал рабочие nfqws --methodeol и nfqws --dpi-desync=multisplit --dpi-desync-split-pos=method+2
Добавил в конфиг --new --filter-tcp=2222 --hostlist=/opt/zapret/ipset/service.txt --methodeol
но ничего не изменилось.
UPD: уточню: на роутере, где запущен zapret, blockcheck после добавления правила говорит, что доступ есть без обхода, т.е. дурение работает. Но в браузере не открывается.
UPD2: поставил на роутере на паузу blockcheck когда он написал AVAILABLE. Проверил на роутере через links - действительно, открывается. Так что стратегии точно работают. Как будто бы при запросах с других ПК не работает дурение. Подозреваю, что связано с портом.
Надо наверное курлом тыкать с -vvv и NFQWS c --debug, браузер что-нибудь закеширует и будет гадание на кофейной гуще. Дамп трафика снять и увидеть, что в ответ на GET на нестандартный порт коробка быстренько шлет RST, не дожидаясь сервера. А вообще, странный кейс, это какая-то телеметрия/мониторинг видимо, типа умного дома. А кто на сервере слушает 2222 порт? Если nginx, то может проще добавить в конфиг эндпойнт /monitor и редирект на 2222 уже внутри? И ходить не http://server:2222, a http://server:80/monitor. Да и certbot прикручивается не так сложно, тем более тем кто с гентой развлекается.
А links может просто игнорировать ошибку, не умея ее обработать, к примеру. Как например он открывает vk, игнорируя Bad Browser. Но это просто догадки.
Я с виндового компа и тыкаю курлом, в том числе. Тишина. Прямо из blockcheck команду скопировал.
Сервис не мой, ничего изменить нельзя. Либо дурение, либо впн )
Ну должно же оно одинаково работать что во время работы blockcheck на роутере, что при запросе с ПК из локальной сети через роутер?
Дебаг помог. Как я и подозревал:
desync profile search for tcp target=1.1.1.1:2222 l7proto=http hostname='my.service.com:2222'
* hostlist check for profile 7
[/opt/zapret/ipset/service.txt] include hostlist check for my.service.com:2222 : negative
hostlist check for service.com:2222 : negative
hostlist check for com:2222 : negative
desync profile 0 matches
packet: id=15 pass unmodified
Ему, оказывается, порт надо в хостлисте указывать! Вот не думал что в именах хостов порт нужен, и что, тем более, он корректно распознается. Заработало.
А в теории, можно было бы крутить фингерпринты у начального пакета ClientHello? Понятно, что очень затратно на реализацию - но возможно ли вообще? В соседней теме как раз обсуждали то, что срабатывания на Edge и Safari несколько другие, по сравнению с Chrome и Firefox. Как и у Curl другой.
Не, так-то может даже хорошо - можно одному хосту на разные порты разные стратегии делать (не знаю, нужно ли это кому). Просто не ждешь, что host.com, host.com:80 и host.com:433 - это 3 разных.
И если всем прописать свои стратегии, то http://host.com и https://host.com пойдут по первой, а https://host.com:433 по третьей (если для 80 и 433 это работает так же, как в моем примере с 2222).
Есть вопрос.
Я не специалист, рассказываю своими словами.
Проблема - на сборке zapret, не суть какой, не запускается клиент игры, отбой по авторизации. Именно основной клиент, лаунчер и античит авторизуются нормально. При использовании WARP клиент запускается, но через 10-20 минут начинаются проблемы с потерей пакетов.
Клиент получает авторизацию с сервака в AWС c порта 8000 (они там всегда разные, но порт авторизации всегда один)
Собсна, суть. Без WARP с этого порта приходит пакет в клиент. Первый 1480 байт, потом несколько по 1440 байт. Клиент получает отлуп по авторизации.
С WARP всё иначе. Клиент сразу получает пакет объёмом примерно килобайт в 25 и объём постоянно продолжает расти. Клиент получает авторизацию, игра запустилась. И далее на этом порту постоянно прилетают пакеты, видимо поддержка авторизации.
Мои соображения по поводу всего этого: Видимо, так работает ТСПУ, когда пропускает часть пакета данных, а потом обрывает соединение.
Собсна, вопрос
С этим можно что-то сделать через zapret? Потому что через WARP игра всё равно не работает толком.