В случае с VPN или хитросделанными прокси типа VLESS провайдер или кто-то другой должны видеть только IP-адресс сервера и некий шифрованный трафик. Так что понять какой сайт посещал пользователь в общем случае невозможно. А что насчет других средств? Например, широко используемых расширений для браузеров, прокси Антизапрета и т.д. Можно ли установить факт использования заблокированных ресурсрв в этом случае?
Любые, в которых трафик не шифруется.
Например, OpenVPN с выключенным шифрованием (cipher none). Или SOCKS.
Без озвучивания протокола сказать невозможно.
Разве такие не блокируются сразу-же? DPI же увидит, что идут обращения к заблокированным ресурсам через такой прокси.
Для этого DPI должен быть настроен разбирать содержимое.
Провайдеры этим не занимаются, поскольку не обязаны. На ТСПУ SOCKS не вскрывается и не блокируется (о причинах рассуждали в новогоднем стриме Неугомонного Фила)
OpenVPN просто блокируется, без разбора того, включено там шифрование или нет. Тем более, что мало кто его использует без шифрования.
Там HTTPS-прокси, шифрование.
Каким алгоритмом кстати?
На ТСПУ SOCKS не вскрывается и не блокируется
На йоте инста и fb блочатся в нешифрованных браузерных vpn расширениях. В wireshark проскакивает домен. Но только эти два сайта. Возможно, dns резолвится не через прокси или sni/поля connect ищут в туннелях.
Попробуйте поэкспериментировать с этим, включив DoH в браузере. Тогда станет ясно, дело в DNS или нет.
Если точнее, я смотрел не в wireshark, а через:
sudo tcpdump -n -i enp1s0 -A|grep instagram
Проскакивали записи. vpn расширение 100% ничего не шифровало само, т.к. контент HTTP сайтов был виден. Думаю, это был sni/connect заголовок instagram, т.к. пользуюсь dnscrypt давно.
Только эти два сайта йота блочит в туннелях. Но также только им йотовский резолвер возвращает 127.0.0.1. Так что dns не исключается.
По сути, это прокси, к VPN они никакого отношения не имеют.
Если там HTTP-прокси без шифрования, то неудивительно. Если HTTPS-прокси, то SNI фейсбука извне увидеть невозможно, потому что получается HTTPS внутри HTTPS.
DNS-запросы всегда нужно делать через прокси. Всегда полагать, что обычный нешифроанный DNS перехватывается и ответы подменяются.
Если интересно, расширение было https://hide.me/en/software/chrome-vpn
На планшете с инстой и fb тоже больше траблов. Подозреваю хромобраузеры dns не через туннель резолвят.
У hide me используются обычные (HTTP) прокси, без шифрования.
Те, что позволяют трафику утекать. Вам стоит сместить фокус внимания с протоколов на детали их имплементаций.
-
WebRTC, QUIC (UDP) трафик проходит мимо http, socks прокси в браузере и ОС в принципе. Браузеры (а именно лиса) также пускают запросы мимо прокси, но это касается только обращений к собственному серверу.
-
В Android в данный момент существует баг, приводящий к DNS утечке. Этот баг устранён на уровне eBPF в двух AOSP ОСках, а также в приложениях двух первоклассных VPN провайдеров, которые, к сожалению, блокируются. Впрочем, в ближайшее время появится обновление приложения стороннего разработчика с поддержкой Амнезии, в котором также имеется фикс утечки.
-
По моему опыту, NekoBox на Linux, Windows во всех вариациях конфигурации, которые должны предотвратить утечки, ведёт трафик мимо.
DNS утечки можно устранить установкой DoT/DoH-only сервера по типу Mullvad DNS внутри приложения и глобально в случае с Android, чтобы у системы не было возможности сброситься до незашифрованного обмена. В десктопных ОС также можно использовать eBPF/nftables. По возможности избегайте васянокода, отдавая предпочтение sing-box или клиентам от разработчиков протоколов. В условиях наших блокировок достаточно использовать AmneziaWG (который форк Wireguard клиента, не их собственное приложение), поскольку там сложно испоганить кодовую базу до утечек как в NekoBox.
нет, quic в хроме отключается при использовании прокси
ну и опять же нет, утечек нет если указать в системе сторонний днс (не от роутера) и включить strict route в некобоксе
там написано some apis, у себя через браузер brave и мертвый конфиг в amneziaWG утечек не увидел, но из-за удаленного тест файла по ссылке нормально поспамить запросами не получилось
Мне запомнилось, что принудительное включение QUIC когда-то приводило к утечке.
Ну т.е есть.
Firefox, TUN/System Proxy, strict route приводил к утечке при моем тестировании осенью 24. При этом использование Chromium браузеров не приводило к утечкам. У меня нет оснований доверять разработчику этого поделия. Как я потом узнал, SagerNet давно говорил о низком качестве костылей вокруг своего проекта.
Бесмысленное старание, ведь утечки по факту есть, но да ладно.
смотри wireshark и таблицу маршрутизации
Клиент неспособен туннелировать DNS трафик к правильному серверу из коробки, и требуются изменения параметров операционной системы. Нельзя отрицать существование утечек, поясняя, что это возможно исправить, изменив настройки системы. Мне также интересно, насколько удобно менять DNS сервер каждый раз при переключении между конфигами/отключаясь от клиента. Не говоря уже о том, что пользователь должен был быть эксплицитно уведомлен о последствиях неумения кодить. Это серьезный случай нарушения доверия к разработчику с моей точки зрения.
Мы забыли про zapret, GoodbyeDPI и им подобные. Имя хоста в запросе присутствует в явном виде в SNI. А сервера для технологии ECH тоже заблокированы.