Ну в целом, я согласен. Но вот клиент flclash действительно может отбрасывать пакеты от приложений не входящие в белые списки. Возможно, что какие-то udp-подключения или короткие tcp-сессии будут проскакивать, но вроде как пока лучше все равно ничего нет.
Не совсем понимаю претензии к автору. Он честно признался, что за пару дней подпивасно накодил прогу в качестве proof of concept. Он не позиционировал её как самое защищённое решение на свете, а просто показал, что исправление так сильно всех напугавшей уязвимости, в целом, несложное.
В этом-то и проблема, что маршрутизация для приложений в большинстве клиентов для vless не работает. Точнее не работает фильтрация "разрешенных приложений".
Сайты типа ipinfo - уж больно явно являются сервисами проверки. Кажется, что такие известные домены можно заблокировать в приложении. Но вот пример с chatgpt на самом деле иллюстрирует гораздо бОльшую проблему: все домены работающие через cloudflare имеют у себя эндпоинт /cdn-cgi/trace а их не заблокировать без блокировки домена. Да и утопия это - писать правила для блокировки всех доменов работающих через cloudflare
Протестировал - к сожалению, такая же штука, как и у большинства клиентов: выбор приложения для прохода через прокси не запрещает другим слать через tun0 запросы
Или имеется в виду, что надо делать типа "черный список" - то есть исключать приложения из прокси? Ну тогда получается весь служебный трафик будет через vps идти. Зачем? Имхо проще же заворачивать через прокси отдельные приложения, а по умолчанию все пускать напрямую, нет?
А кто-то ещё верит, что белые списки нужны для борьбы с беспилотниками? Если б это было целью, то глушили бы GPS-Глонасс. А если кто-то верит, что беспилотнику нужно обязательно в интернет для "корректировки для захода на цель" - так пусть посмотрит в своём мобильнике как распознавание лица и улыбки в приложении камеры работает без всякого интернета. И это неизвестное заранее лицо и неизвестная заранее улыбка. То есть даже для такого распознавания вполне хватает смартфона. В то время как беспилотнику надо, как правило, навестись на заранее известный объект. Уж с этим-то любой смартфон играючи может справиться. Ну и на кой пёс, скажите мне, тогда белые списки нужны?
Виноват, описка - демультиплексирование, конечно, имелось в виду. В общем, интересно может ли динамически или статично, с помощью настроек, менять управление количеством соединений. Это же тоже достаточно важный паттерн отслеживания трафика.
А что по скорости? Накладные расходы выглядят солидно - есть какие-то тесты скорости в спокойных условиях и в условиях постоянного переключения масок? Как часто в теории могут переключаться маски? Есть ли мультиплексирование и, наоборот, объединение всех соединений в одно?
Пользуюсь qwen cli. Доволен как слон. Как-нибудь попробую и opencode.
А вот что opencode будет делать, если локальная модель будет прям ОЧЕНЬ долго отвечать? Есть какие-то настройки для таймаута ожидания ответа локальной llm?
Ну, справедливости ради, надо признать, что Макс пока слаб технически - невозможность создавать ботов всем, невозможность добавлять ботов в каналы... Как относиться к тем, кто его допиливает - вопрос сложный.
А вот это мы сейчас обстоятельнейшим образом потестим!
Ну в целом, я согласен. Но вот клиент flclash действительно может отбрасывать пакеты от приложений не входящие в белые списки. Возможно, что какие-то udp-подключения или короткие tcp-сессии будут проскакивать, но вроде как пока лучше все равно ничего нет.
Не совсем понимаю претензии к автору. Он честно признался, что за пару дней подпивасно накодил прогу в качестве proof of concept. Он не позиционировал её как самое защищённое решение на свете, а просто показал, что исправление так сильно всех напугавшей уязвимости, в целом, несложное.
Вообще, работающую блокировку по приложению я только у flclash нашел. Но там конфиги все переписывать надо
В этом-то и проблема, что маршрутизация для приложений в большинстве клиентов для vless не работает. Точнее не работает фильтрация "разрешенных приложений".
Сайты типа ipinfo - уж больно явно являются сервисами проверки. Кажется, что такие известные домены можно заблокировать в приложении. Но вот пример с chatgpt на самом деле иллюстрирует гораздо бОльшую проблему: все домены работающие через cloudflare имеют у себя эндпоинт /cdn-cgi/trace а их не заблокировать без блокировки домена. Да и утопия это - писать правила для блокировки всех доменов работающих через cloudflare
Протестировал - к сожалению, такая же штука, как и у большинства клиентов: выбор приложения для прохода через прокси не запрещает другим слать через tun0 запросы
Виноват, всё нашёл. Тестирую.
Или имеется в виду, что надо делать типа "черный список" - то есть исключать приложения из прокси? Ну тогда получается весь служебный трафик будет через vps идти. Зачем? Имхо проще же заворачивать через прокси отдельные приложения, а по умолчанию все пускать напрямую, нет?
Смысл в том, чтобы приложение не могло отправить запрос в туннель, а отправляла бы его через обычный интернет
Ну вот на обычных клиентах, типа v2rayNG, из termux (если он даже не в списке проксируемых) получается, что вполне себе запрос отправляется легко.
А как побороли возможность любому приложению отправить запрос через tun? Например,
curl https://chatgpt.com/cdn‑cgi/trace ‑interface tun0
что выдает?
А кто-то ещё верит, что белые списки нужны для борьбы с беспилотниками? Если б это было целью, то глушили бы GPS-Глонасс. А если кто-то верит, что беспилотнику нужно обязательно в интернет для "корректировки для захода на цель" - так пусть посмотрит в своём мобильнике как распознавание лица и улыбки в приложении камеры работает без всякого интернета. И это неизвестное заранее лицо и неизвестная заранее улыбка. То есть даже для такого распознавания вполне хватает смартфона. В то время как беспилотнику надо, как правило, навестись на заранее известный объект. Уж с этим-то любой смартфон играючи может справиться. Ну и на кой пёс, скажите мне, тогда белые списки нужны?
Виноват, описка - демультиплексирование, конечно, имелось в виду. В общем, интересно может ли динамически или статично, с помощью настроек, менять управление количеством соединений. Это же тоже достаточно важный паттерн отслеживания трафика.
А что по скорости? Накладные расходы выглядят солидно - есть какие-то тесты скорости в спокойных условиях и в условиях постоянного переключения масок? Как часто в теории могут переключаться маски? Есть ли мультиплексирование и, наоборот, объединение всех соединений в одно?
Это я знаю, мне, наоборот, надо, чтобы оно не прерывалось, пока на старой слабой машине будет по 2 часа генерироваться ответ на любой запрос
Пользуюсь qwen cli - для моих скромных целей вполне хватает бесплатного тарифа.
Пользуюсь qwen cli. Доволен как слон. Как-нибудь попробую и opencode.
А вот что opencode будет делать, если локальная модель будет прям ОЧЕНЬ долго отвечать? Есть какие-то настройки для таймаута ожидания ответа локальной llm?
Ну, справедливости ради, надо признать, что Макс пока слаб технически - невозможность создавать ботов всем, невозможность добавлять ботов в каналы... Как относиться к тем, кто его допиливает - вопрос сложный.
п.3: формально - обхода ТСПУ нет. Пакеты как шли через ТСПУ так и идут - никто ТСПУ не обходит. ТСПУ сам пропускает через себя эти пакеты.
Только работа p2p, насколько я понимаю, требует большого количества нод. Если их нет - два клиента за NATами друг с другом не сконнектятся.