شناسه:
PMTU_MSS_COMBINEDدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: پایین
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
تابع یک سوکت TCP میسازد و تلاش میکند به 127.0.0.1:443 متصل شود. فقط اگر شنوندهٔ محلی اتصال را بپذیرد، TCP_INFO را میخواند و tcpi_snd_mss و tcpi_rcv_mss را گزارش میکند. برخلاف نام تابع، UDP یا PMTU را واقعاً آزمایش نمیکند.
اتصال موفق به localhost:443 و سپس فراخوانی موفق getsockopt(TCP_INFO). مقادیر با آستانهای مقایسه نمیشوند؛ خط اطلاعاتی است.
این خط مبنایی برای پشتهٔ TCP محلی و شنونده است، نه شاخص VPN. اگر چیزی روی درگاه 443 گوش ندهد، خط اصلاً تولید نمیشود. هر مقدار MSS فقط در زمینهٔ همتا و مسیر معنا دارد.
تأثیر این خط بر گزارش: این خط اطلاعاتی یا تشخیصی است. برای مقایسهٔ اجراها مفید است، اما بهتنهایی وجود VPN یا دستکاری را ثابت نمیکند.
loopback نه PMTU اینترنت را میسنجد و نه مسیر تونل را. شنونده ممکن است گزینههای سوکت خودش را اعمال کند. واژهٔ «combined» در نام گمراهکننده است؛ آستانه یا همبستگی وجود ندارد.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
برای سیگنال تشخیصی، ابتدا هیچ چیزی را «اصلاح» نکنید. روی همان دستگاه بدون VPN خط مبنا ثبت کنید و سپس آزمون را با VPN و تحت همان شبکه، دما و بار تکرار کنید. فقط تفاوت تکرارپذیر میان دو مجموعه برای تحلیل مفید است. یک مقدار MTU، زمانبندی یا GSO بهتنهایی مدرک نیست. فقط برای «عبور» از این بررسی شنونده راه نیندازید؛ خود شنونده سیگنال تداخل درگاه میسازد. برای پژوهش شبکه از سرور آزمایشی جداگانه و پروب اختصاصی استفاده کنید.
ماژول روت میتواند این شاخص را تغییر دهد، اما تنظیم آن برای رسیدن به عددی خاص بهآسانی TCP/UDP، DNS، تماسها یا مصرف انرژی را مختل میکند. VPNHide Next ادعا میکند چند پارامتر غیرمستقیم را فیلتر میکند، ولی این قابلیتها باید جدا از پنهانسازی پایهٔ رابط آزموده شوند. پیش از داشتن خط مبنای پاک و روش بازگردانی عملی، بیشترین مجموعهٔ هوکهای هسته را فعال نکنید. TCP_INFO را سراسری جایگزین نکنید. هنگام بررسی MSS، بستهها و MTU مسیر را در محیط آزمایشی ثبت کنید.
adb shell 'ss -H -ltn | grep -E "127[.]0[.]0[.]1:443|[*]:443" || echo no-local-443-listener'
وقتی شنونده وجود دارد، جزئیات را با آزمون بومی getsockopt(TCP_INFO) مقایسه کنید؛ ممکن است ss فیلد دیگری از MSS را نشان دهد.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
اجرای سرویس آزمایشی روی درگاه 443 میتواند با APIهای محلی تداخل کند. جایگزینی سراسری MSS ممکن است fragmentation یا اتصالهای black-hole ایجاد کند.
فقط شنوندهٔ آزمایشی ساختهشده را متوقف و ورودی autostart آن را حذف کنید. گزینههای پیشفرض سوکت و هسته را بازگردانید.
پایین. با اتصال loopback و نبود آستانه راستیآزمایی شده است؛ نوع نتیجه اطلاعاتی.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: tcp-mss-low, loopback-port-conflict, normal-pmtu.