ID:
NORMAL_PMTUКатегория: Маршруты и сетевой стек Статус в RKNHardering 2.10.0: Активная проверка Роль в вердикте: Низкая
Эта страница описывает фактическую реализацию RKNHardering 2.10.0. Здесь отдельно указано, что можно сделать без root, что требует root, а также где способ только уменьшает один сигнал, но не скрывает VPN целиком.
Проба перебирает getifaddrs() и выбирает первую запись, чьё имя не lo и не содержит substrings tun, wg, ppp. Через fetchMtu() получает MTU и выводит имя/значение. xfrm, utun, tailscale здесь не исключены. Строка informational.
Найден первый подходящий интерфейс с MTU >0; threshold отсутствует.
Это ориентир физического path MTU для сравнения с другими показателями. Значение 1500, 1400, 1350 и т.п. само по себе не доказывает VPN.
Как строка влияет на отчёт: Строка информационная либо диагностическая. Она нужна для сравнения запусков, но сама по себе не доказывает VPN или вмешательство.
Порядок getifaddrs() не гарантирует основной default route; одна interface имеет несколько address records. Substring filter неполный и может выбрать VPN-like interface. Нет correlation с route destination.
Важно оценивать эту строку вместе с соседними сигналами. Один чистый API не перекрывает Java Binder, libc, raw netlink/syscall, procfs/sysfs, локальные сокеты и серверные признаки одновременно.
Для диагностического сигнала сначала ничего не «исправляйте». Запишите baseline на том же устройстве без VPN, затем повторите с VPN при одинаковой сети, температуре и нагрузке. Только воспроизводимая разница между сериями пригодна для анализа. Одиночное значение MTU, времени или GSO не является доказательством. Сравните имя с default route. Не меняйте MTU только ради «типичного» 1500: мобильные и overlay-сети законно используют другие значения.
Root-модуль может изменить этот показатель, но настройка ради конкретного числа легко нарушает TCP/UDP, DNS, звонки или энергопотребление. VPNHide Next заявляет фильтрацию ряда косвенных параметров, однако такие возможности нужно проверять отдельно от базового сокрытия интерфейсов. Не включайте максимальный набор kernel hooks до получения чистого baseline и рабочего отката. Подмена MTU должна быть согласована с ioctl, sysfs, netlink, TCP MSS и фактическим forwarding. Несогласованное значение создаёт больше сигналов и packet loss.
adb shell ip route get 1.1.1.1
adb shell 'for i in /sys/class/net/*; do echo -n "${i##*/} "; cat "$i/mtu" 2>/dev/null; done'
После любого изменения сделайте force-stop RKNHardering и VPN-клиента, запустите их заново и повторите полный scan. Для Zygisk/Xposed/kernel-модулей обычно нужна перезагрузка. Сравнивайте не только эту строку, но и соседние сигналы: частичный hook часто создаёт несогласованность между API.
Сама проба выполняется с обычными правами приложения и не запрашивает root. ADB-команды ниже служат только для ориентира: adb shell работает под другим UID и может видеть больше или меньше, чем процесс приложения. Решающий тест — повторный запуск самой проверки после force-stop.
Слишком высокий MTU вызывает black-hole/fragmentation, слишком низкий снижает производительность. Не применяйте глобально без теста ICMP/QUIC/TCP.
Верните исходный MTU в VPN/интерфейсе или перезапустите NetworkStack/VPN; сохраните значение до изменения.
Низкая. Проверено по first-match algorithm и отсутствию thresholds; informational.
Статус стороннего решения не переносится автоматически на это устройство. Заявление разработчика модуля — это исходная гипотеза; подтверждением служит повторяемый результат RKNHardering на конкретной версии Android, прошивки и ядра.
native_signs_probe.cpp — нативная реализация проб.VpnNativeDetectorChecker.kt — deep VPN verdict и confidence.NativeSignalId.kt — полный реестр ID.NativeSignalCatalog.kt — категория, slug и mapping строк.Связанные сигналы: pmtu-mss-combined, udp-pmtu-ok, tuntap-type.