blockcheck via libcurl build with custom cfilter

[EnergoStalin]

В теории помощью connection filters в libcurl возможно кросплатформенно распаралелить тестинг вставив условный cf-zapret между условными cf-ssl и cf-socket где уже будет находится буффер готовый для модификации на лету без таблиц маршрутизаций и nfq в частности.

Или проще говоря модифицировать то что сам курл отправляет в кастомном коннекшен фильтре.

Сразу в голову приходит что скорее всего всякие ipfrag работать не будут хотя тоже спорно смотря на сколько глубоко внедриться фильтры позволяют. В ближайшие пару дней попробую копнуть глубже и выяснить возможно ли приложив адекватные усилия пропатчить libcurl сохранив вменяемую поддрежку протоколов так что бы можно было прям в нём модифицировать tcp/udp пакеты на достаточно низком уровне.

А пока хотелось бы услышать мнение более сведующих в теме людей.

Для референса cfilter

• api
• usage
• docs

[HentayHentay]

libcurl станет узким местом. При обновлении curl или libcurl продеться каждый раз завозить патчи

Да и в силу многообразия операционных систем, может отсутствовать та или иная возможность к применению патча

[EnergoStalin]

С отлаженным CI и минималистичными патчами обновится не должно быть проблемой. Vencord же как то живёт. При должном наличии энузиазма на пару дней максимум релиз опоздает что не так критично для узконаправленной утилиты тем более что cfilter api выглядит стабильным и широко используется в самом libcurl.

[bol-van]

С блокчеком планируется распараллеливание теста множества доменов на 1 стратегии.
Это не так сложно сделать.

Усложнять блокчек какими-то сложными зависимостями не планируется

Текущий блокчек основывается на действиях реальных tpws и nfqws, а не на собственном конструировании измененных запросов. Такой подход не покроет и малой доли всех методов дурения, реализуемых zapret

[EnergoStalin]

Если я правильно понимаю zapret не спускается на L2 уровень а это значит что надо только завести готовую реализацию UDP/TCP протокола поверх libcurl оборачивая соединение по RAW сокету вручную в него перед отправкой отдавая буффер на дурение.

На винде однако придётся всё же обернуть ещё во что то что бы пакет не считался TCP разворачивая его в windrivert коллбэке.

На мак и bsd я даже не смотрел пока но они же unix right?

Кстати пока читал мне в голову пришла более здравая мысль. Раскидать по виртуальным интерфейсам вызывая курл с --interface флагом накинув уже на них фильтры. Где на 1 интерфейс 1 инстанс запрета с разными флагами. Как раз windrivert слушает на уровне network который поддерживается ifIdx фильтром. Так что я бы взял этот вариант на вооружение.

[bol-van]

завести готовую реализацию UDP/TCP протокола

А может весь linux перепишем заново под libcurl? Круто же будет выглядить. curlix
Это монстрообразная задача, чудовищная по обьему усилий. UDP еще довольно несложно, но вот tcp переписать - дело тяжелое.

Вы вообще не в ту сторону смотрите. Никто так не делает. Зачем переделывать то, что уже десятками лет отточено ?
Я же описал возможный вариант распараллеливания. Раскидать их по UID, и на каждый UID свое правило tables, свой инстанс nfqws. Это работает на всех *nix, но не на винде

[EnergoStalin]

ZaAstraCurl Linux

А может весь linux перепишем заново под libcurl? Круто же будет выглядить.

Ну тут уделал. Жаль такими амбициями не обладаю.

Если уж и пытатся как то продолжать плясать через RAW сокеты без своего TCP/UDP то придётся свой протокол городить на RAW сокетах который спрячет в себя реальный пункт назначения пакета и будет выступать как прокси на RAW сокетах. пересобирая его по кусочкам с заменой destination ip хедера. Но я так делать не планирую.

Windows

но не на винде

Мне казалось что мы обозначили что проблема только в винде. Перечитал понял что нет. Обозначаю "проблема только в винде".

Под Unix оно и удобно и понятно там уйма способов. За поддержку виртуальных интерфейсов на всех *nix конечно не ручаюсь этим тоже драйвер заниматься должен которого может и не быть. Но если выбирать унифицированный подход то этот должно работать везде при наличии драйвера.

Для винды подход через создание виртуальных интерфейсов похоже что единственный и самый логичный. Сразу бросается в глаза вариант с HyperV но он не у всех есть и только от Home Pro тира на сколько я помню его можно включить. Так что я бы ещё посмотрел варианты.

В случае с интерфейсным распаралеливанием должно хватить windrivert ifIdx фильтра. И --interface флага curl.

Поддержка нескольких ОС

Вообще у меня есть сомнения на счёт необходимости кросплатформенно тестить поскольку единственное что будет отличатся от системы к системе это реализация L2-3 нетворк стека ну и немного TCP пейлоад который в большинстве случаев зашифрован TLS и не проверяется. Так что может есть смысл сфокусироватся на удобном решении для *nix в первую очередь не смотря на винду.

Мне эксклюзивное решение под линукс подойдёт. Я думал ты хочешь себе поддержку распаралеливания стратегий на винде. Неправильно тебя понял?

[bol-van]

Я в эти дебри, описанные выше, не полезу. Это гиблое дело.
Чудовищные усилия при непонятном результате.
Мне проще сказать ставьте виртуалку с linux, если хотите побыстрее

[EnergoStalin]

Для винды и так по сути только goodcheck существует в качестве тестера не считая bat скриптов. Который я очень хочу завезти на линукс.

Если резюмировать всё что потребуется непосредственно от winws то это будет "опция установки windrivert фильтра по указанному интерфейсу". Остальное прикручивается тривиально за исключением самого создания интерфейса что я вынес бы за рамки этого репозитория.

Как то неловко на самом деле получилось в итоге всё сошлось на там на чём и предыдущий тред. Нужна отдельная быстрая утилита для пользовательских тестов.