ID:
UDP_PMTU_OKКатегория: Маршруты и сетевой стек Статус в RKNHardering 2.10.0: Активная проверка Роль в вердикте: Низкая
Эта страница описывает фактическую реализацию RKNHardering 2.10.0. Здесь отдельно указано, что можно сделать без root, что требует root, а также где способ только уменьшает один сигнал, но не скрывает VPN целиком.
Проба создаёт UDP socket и выполняет один sendto() буфера 1500 bytes на loopback DNS port 53. Если возвращено >0, создаётся udp_pmtu_ok; receiver/listener не требуется. Строка informational low.
Kernel принял локальную UDP datagram длиной 1500 bytes в send path.
Успех показывает только возможность loopback send. Он не измеряет PMTU внешнего маршрута, фрагментацию или прохождение пакета до DNS-сервиса.
Как строка влияет на отчёт: Строка информационная либо диагностическая. Она нужна для сравнения запусков, но сама по себе не доказывает VPN или вмешательство.
Loopback MTU обычно намного выше physical MTU. UDP send success не подтверждает delivery. Название PMTU завышает информативность.
Важно оценивать эту строку вместе с соседними сигналами. Один чистый API не перекрывает Java Binder, libc, raw netlink/syscall, procfs/sysfs, локальные сокеты и серверные признаки одновременно.
Для диагностического сигнала сначала ничего не «исправляйте». Запишите baseline на том же устройстве без VPN, затем повторите с VPN при одинаковой сети, температуре и нагрузке. Только воспроизводимая разница между сериями пригодна для анализа. Одиночное значение MTU, времени или GSO не является доказательством.
Root-модуль может изменить этот показатель, но настройка ради конкретного числа легко нарушает TCP/UDP, DNS, звонки или энергопотребление. VPNHide Next заявляет фильтрацию ряда косвенных параметров, однако такие возможности нужно проверять отдельно от базового сокрытия интерфейсов. Не включайте максимальный набор kernel hooks до получения чистого baseline и рабочего отката. Не блокируйте loopback UDP/53 ради смены результата: это создаст udp-pmtu-fail и может повредить локальный DNS.
adb shell ip link show lo
adb shell 'cat /sys/class/net/lo/mtu 2>/dev/null'
Ожидайте успешную отправку на обычном kernel независимо от listener.
После любого изменения сделайте force-stop RKNHardering и VPN-клиента, запустите их заново и повторите полный scan. Для Zygisk/Xposed/kernel-модулей обычно нужна перезагрузка. Сравнивайте не только эту строку, но и соседние сигналы: частичный hook часто создаёт несогласованность между API.
Сама проба выполняется с обычными правами приложения и не запрашивает root. ADB-команды ниже служат только для ориентира: adb shell работает под другим UID и может видеть больше или меньше, чем процесс приложения. Решающий тест — повторный запуск самой проверки после force-stop.
Firewall/SELinux эксперименты на loopback DNS могут сломать резолвинг приложений.
Удалите временное loopback/firewall правило и перезапустите netd/VPN или устройство.
Низкая. Проверено по fixed 1500-byte loopback send; informational.
Статус стороннего решения не переносится автоматически на это устройство. Заявление разработчика модуля — это исходная гипотеза; подтверждением служит повторяемый результат RKNHardering на конкретной версии Android, прошивки и ядра.
native_signs_probe.cpp — нативная реализация проб.VpnNativeDetectorChecker.kt — deep VPN verdict и confidence.NativeSignalId.kt — полный реестр ID.NativeSignalCatalog.kt — категория, slug и mapping строк.Связанные сигналы: udp-pmtu-fail, normal-pmtu, backpressure.