شناسه:
TCP_MSS_LOWدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
پروب تلاش میکند به 127.0.0.1:443 متصل شود. فقط اگر شنونده اتصال را بپذیرد، TCP_INFO را میخواند و در صورت tcpi_snd_mss > 0 && < 500 نتیجهٔ tcp_mss_low را تولید میکند. سیاست قدیمی این نوع را اطمینان بالا میداند. بدون شنوندهٔ محلی، تابع بیسروصدا خارج میشود.
اتصال موفق TCP به localhost:443 با MSS ارسال کمتر از 500.
در پیادهسازی فعلی، این سیگنال نادر و وابسته به زمینه است. بیشتر به شنوندهٔ محلی و پشتهٔ loopback وابسته است تا PMTU واقعی اینترنت.
تأثیر این خط بر گزارش: این خط detected=true را تنظیم میکند و بهعنوان یک نشانهٔ محلی با اطمینان بالا در نظر گرفته میشود.
آستانهٔ 500 بسیار پایین است؛ MTU معمول VPN معمولاً MSS بسیار بالاتری میسازد. اگر درگاه 443 بسته باشد، بررسی اصلاً اجرا نمیشود. TCP_INFO روی loopback مسیر تونل خارجی را بازتاب نمیدهد.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
برای یک سیگنال تشخیصی، ابتدا هیچ چیزی را «اصلاح» نکنید. روی همان دستگاه بدون VPN خط مبنا ثبت کنید، سپس آزمون را با VPN و تحت همان شبکه، دما و بار تکرار کنید. فقط تفاوت تکرارپذیر میان دو مجموعه برای تحلیل مفید است. یک مقدار MTU، زمانبندی یا GSO بهتنهایی مدرک نیست. مشخص کنید چه چیزی روی localhost:443 گوش میدهد. اگر شنونده لازم نیست، آن را متوقف کنید؛ برای این پروب MTU سیستم را تغییر ندهید.
ماژول روت میتواند این شاخص را تغییر دهد، اما تنظیم آن برای رسیدن به عددی خاص بهآسانی TCP/UDP، DNS، تماسها یا مصرف انرژی را مختل میکند. VPNHide Next ادعا میکند چند پارامتر غیرمستقیم را فیلتر میکند، ولی این قابلیتها باید جدا از پنهانسازی پایهٔ رابط آزموده شوند. پیش از داشتن خط مبنای پاک و روش بازگردانی عملی، بیشترین مجموعهٔ هوکهای هسته را فعال نکنید. TCP_INFO را میتوان با هوک فضای کاربر یا هسته جایگزین کرد، اما VPNHide بالادستی پوشش این سناریوی قدیمی loopback را ادعا نمیکند؛ VPNHide Next فیلتر TCP_INFO و MSS را ادعا میکند.
adb shell ss -ltn 2>/dev/null | grep '127.0.0.1:443'
adb shell ip link show
اندازهگیری دقیق MSS به سرویسگیرندهٔ آزمایشی در همان زمینهٔ برنامه نیاز دارد.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
پایین یا بالا بردن کورکورانهٔ MTU میتواند fragmentation ایجاد کند، بعضی سایتها را معطل نگه دارد و تماسها را مختل کند.
رفتار اصلی MTU و MSS را بازگردانید و فقط شنوندهٔ آزمایشی localhost را متوقف کنید.
بالا. مقصد اتصال، TCP_INFO و آستانهٔ <500 راستیآزمایی شدهاند؛ نوع قدیمی اطمینان بالا دارد، اما اجرای پروب مشروط است.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: pmtu-mss-combined, normal-pmtu, loopback-port-conflict.