У вас случайно там нет стратегии БЕЗ хостлиста/ипсета? Если есть, попробуйте ее убрать либо добавить хостлист/ипсет
Всё сложно, физически intel, но ещё плюсом vmware-bridge. Это вм, я её тестирую на разном железе. На более быстром - DLINK физический.
Нет, так или иначе либо строгий список ipset, либо hostlist
Не понятно, я отключал самую жирную, по моему мнению стратегию с тысячами хостов, пресловутый blacklist-russia.txt, ну как отключал - заносил в лист единственный домен для облегчения работы, но нет, это тоже не привело к росту быстродействия.
В отладке браузера видно, что тяжёлый трафик прёт именно с поддоменов yandex.net. А железо там такое - CPU core2 quad-6600, 2,4 ghz. на вм отданы два ядра из 4х. На втором варианте ВМ xeon E5/2600 12 ядер на эту же вм, комп HP Z420 Workstation. Как уже говорил, второй вариант конечно выдаёт всё шустрее, но тенденция та же.
exclude буду тестировать, обязательно.
У меня собственно вопрос то был в том, как фильтры взаимно обрабатывают поступающие пакеты - по мажоритарному принципу или по конвейерному, т.е. 1. срабатывает совпадение на первом, остальные не рассматриваются вовсе или 2. Любое совпадение обрабатывается соответ. фильтром. т.е. все наборы фильтров проверяются всегда. И я пришёл к выводу, что видимо, всё таки второе.
в доке описано. профиль выбирается только 1 сверху вниз
проц грузит перехват а не десинх
на уровне пакета с clienthello (ведь считается что запрет только его и ищет\меняет) уже видна разница с каким именно сертификатом ты этот пакет шлёшь? или даже не разница а чёткое знание? ведь какбудто браузер в нём видно однозначно(но это неточно)
Неа, сертификаты проверяются на клиентской стороне. Т.е. сертификат будет в ответе от сервера. Но если не веришь, посмотри запрос в инструментах разработчика в браузере или в шарке)
Сертификат передается только той стороной, которую должна другая сторона авторизовать.
Если сервер должен авторизовать клиента на уровне TLS, значит передается сертификат клиента.
Но это редкий случай, обычно связанный с авторизацией на каких-то секурных порталах или в корпоративных сетях. А вот сервер авторизуется клиентом всегда. Клиент не знает каким CA подписан сертификат сервера до тех пор, пока он его не передаст
ок. понял. спс.
ну хотя бы на этом этапе простой блок не грозит
а то явно хватит “ума” чебуродам ввести БС на tls лишь с ихним скам-сертом
В tls 1.3 они не могут посмотреть сертификат сервера, а в 1.2 они уже давно это делают.
Они уже как-то пытались запрещать TLS 1.3 на группе IP некоторых CDN.
Но это что касается пассивного просмотра.
Они могут подсмотреть SNI и попробовать обратиться сами с таким же SNI. Отложенный джоб, при фейле - команда на блок IP, допустим, или на блок SNI. В Китае давно активный пробинг сделан
Раз вспомнил о Китае хотел спросить .а есть ли данные насколько эффективен запрет 1 или 2 в Китае? Спасибо
Не слышал, чтобы им кто-то пользовался в Китае.
По крайней мере со мной оттуда никто не связывался
--dpi-desync=fake прибили. Может временно, может нет.
что прям любые?
позвольте не поверить…
на другом провайдере небаненые открывает и с этой стратегией а баненые и раньше не открывало
Насчёт любые или нет не знаю, но у меня все стратегии которые содержали --dpi-desync=fake поотваливались, как текущая страта работающая полгода, так и тройка запасных. Просто не открываются сайты. Всё остальные стратегии как работали так и работают.
какой фулинг используется? если какой нибудь badseq то его на провайдерах с современным тспу еще год назад заблочили (без доп.манипуляций не работает)
у меня fake --dpi-desync-fooling=ts например отвалился сегодня на двух провайдерах
md5sig был на одной, ts на другой. Обе отвалились.
у меня не воспроизводится. и во фловсиловском конфиге тоже. максимум что заметил - это то что фейк 4пда/стун не работает оттуда