RKNHardering Help

Legacy счётчики трафика tun0/wg0 под именем qdisc

ID: VPN_QDISC Категория: Маршруты и сетевой стек Статус в RKNHardering 2.10.0: Активная проверка Роль в вердикте: Средняя

Эта страница описывает фактическую реализацию RKNHardering 2.10.0. Здесь отдельно указано, что можно сделать без root, что требует root, а также где способ только уменьшает один сигнал, но не скрывает VPN целиком.

Что проверяется и зачем

Несмотря на имя, detectQdisc() не запрашивает qdisc. Он читает /proc/net/dev, парсит RX/TX bytes/packets и выдаёт vpn_qdisc только для точных tun0 и wg0. Legacy policy считает строку medium review.

Точное условие срабатывания

В /proc/net/dev присутствует tun0 или wg0; объём трафика может быть нулевым.

Что означает результат

Это ещё один procfs interface leak, а не анализ packet scheduler. Для настоящего qdisc в текущем deep pipeline отдельного producer фактически нет.

Как строка влияет на отчёт: Строка не даёт самостоятельный окончательный вердикт, но выставляет needsReview=true и добавляет доказательство средней уверенности.

Ограничения и возможные ложные срабатывания

Название историческое и потенциально вводит в заблуждение. Только два имени, только доступный procfs.

Важно оценивать эту строку вместе с соседними сигналами. Один чистый API не перекрывает Java Binder, libc, raw netlink/syscall, procfs/sysfs, локальные сокеты и серверные признаки одновременно.

Рекомендации для этого вектора

Без root

Самый надёжный non-root способ — не создавать VPN-интерфейс на проверяемом телефоне: вынести туннель на роутер, travel-router, отдельный телефон-шлюз или другой узел сети. Per-app bypass в VpnService меняет маршрут трафика выбранного приложения, но establish() всё равно создаёт системный VPN-интерфейс, поэтому локальная проверка интерфейсов может продолжить срабатывать. Режим локального HTTP/SOCKS-прокси без TUN иногда убирает этот конкретный вектор, но оставляет порты, proxy-настройки и не покрывает приложения, которые игнорируют прокси.

С root

Для лабораторного сокрытия обычно нужен системный Java-слой и один native-бэкенд. У VPNHide это APK + Vector/LSPosed со scope только System Framework и ровно один из kmod, KPM или Zygisk. Для проверки, которая может идти прямым syscall или netlink, предпочтительнее kmod/KPM: userspace-хук Zygisk можно обойти и он оставляет след внутри процесса. Сначала изучите карту покрытия VPNHide и скачивайте сборки только из официального release. VPNHide Next заявляет более широкое покрытие, но сам предупреждает о возможных bootloop и kernel panic; его следует проверять только на тестовом устройстве. Фильтрация /proc/net/dev нужна отдельно от netlink. Upstream VPNHide не заявляет полное покрытие этого файла kernel backend; Next заявляет расширенный proc/qdisc слой.

Как проверить результат

adb shell cat /proc/net/dev 2>&1 | grep -E '(^|:)[[:space:]]*(tun0|wg0):'
adb shell tc qdisc show 2>/dev/null

Вторая команда иллюстрирует, что actual qdisc — другая поверхность.

После любого изменения сделайте force-stop RKNHardering и VPN-клиента, запустите их заново и повторите полный scan. Для Zygisk/Xposed/kernel-модулей обычно нужна перезагрузка. Сравнивайте не только эту строку, но и соседние сигналы: частичный hook часто создаёт несогласованность между API.

Необходимые права и риски

Сама проба выполняется с обычными правами приложения и не запрашивает root. ADB-команды ниже служат только для ориентира: adb shell работает под другим UID и может видеть больше или меньше, чем процесс приложения. Решающий тест — повторный запуск самой проверки после force-stop.

Риски

Не обнуляйте реальные counters и не меняйте qdisc без необходимости: это влияет на QoS/latency.

Откат

Верните последнее изменение: отключите добавленный модуль или правило через штатный менеджер, перезагрузите устройство и повторите baseline. Не накладывайте новый hook поверх неизвестного состояния.

Уровень доказательности

Средняя. Проверено по parser /proc/net/dev; документация прямо исправляет историческое название.

Статус стороннего решения не переносится автоматически на это устройство. Заявление разработчика модуля — это исходная гипотеза; подтверждением служит повторяемый результат RKNHardering на конкретной версии Android, прошивки и ядра.

Источники и дата последней проверки

Связанные сигналы: proc-net-dev-vpn, deep-vpn-qdisc.

К справочнику Native signs