RKNHardering Help

Низкий TCP MSS на локальном соединении

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

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

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

Проба пытается подключиться к 127.0.0.1:443. Только если там есть принимающий listener, она читает TCP_INFO и выдаёт tcp_mss_low, когда tcpi_snd_mss > 0 && < 500. Legacy policy считает kind high. Без локального listener функция молча завершается.

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

Успешный TCP connect к localhost:443 и send MSS меньше 500.

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

В текущей реализации это редкий и контекстный сигнал. Он больше зависит от локального listener/loopback, чем от реального Internet PMTU.

Как строка влияет на отчёт: Строка переводится в detected=true и считается высокодостоверным локальным признаком.

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

Порог 500 очень низкий; обычный VPN MTU чаще даёт MSS значительно выше. Если port 443 закрыт, проверка вообще отсутствует. TCP_INFO loopback не отражает внешний tunnel path.

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

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

Без root

Для диагностического сигнала сначала ничего не «исправляйте». Запишите baseline на том же устройстве без VPN, затем повторите с VPN при одинаковой сети, температуре и нагрузке. Только воспроизводимая разница между сериями пригодна для анализа. Одиночное значение MTU, времени или GSO не является доказательством. Проверьте, кто слушает localhost:443. Если listener не нужен, выключите его; не меняйте системный MTU ради этой пробы.

С root

Root-модуль может изменить этот показатель, но настройка ради конкретного числа легко нарушает TCP/UDP, DNS, звонки или энергопотребление. VPNHide Next заявляет фильтрацию ряда косвенных параметров, однако такие возможности нужно проверять отдельно от базового сокрытия интерфейсов. Не включайте максимальный набор kernel hooks до получения чистого baseline и рабочего отката. Подмена TCP_INFO возможна userspace/kernel hook, но upstream VPNHide не обещает этот legacy loopback сценарий; Next заявляет TCP_INFO/MSS filtering.

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

adb shell ss -ltn 2>/dev/null | grep '127.0.0.1:443'
adb shell ip link show

Для точного MSS нужен test client в том же app context.

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

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

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

Риски

Снижение/повышение MTU вслепую вызывает fragmentation, зависания отдельных сайтов и проблемы звонков.

Откат

Верните исходный MTU/MSS и отключите только тестовый localhost listener.

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

Высокая. Проверено по connect target, TCP_INFO и порогу <500; legacy high, но probe условный.

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

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

Связанные сигналы: pmtu-mss-combined, normal-pmtu, loopback-port-conflict.

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