شناسه:
NORMAL_PMTUدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: پایین
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
پروب getifaddrs() را پیمایش میکند و نخستین ورودی را برمیگزیند که نامش lo نیست و شامل زیررشتههای tun، wg یا ppp نمیشود. MTU را با fetchMtu() میگیرد و نام رابط و مقدار را گزارش میکند. xfrm، utun و tailscale در اینجا حذف نمیشوند. خط اطلاعاتی است.
نخستین رابط منطبق با MTU بزرگتر از 0 پیدا شود؛ آستانهای وجود ندارد.
این مقدار هنگام مقایسهٔ شاخصهای دیگر نقطهٔ مرجعی برای MTU مسیر فیزیکی فراهم میکند. مقدار 1500، 1400، 1350 یا مشابه آن بهتنهایی وجود VPN را ثابت نمیکند.
تأثیر این خط بر گزارش: این خط اطلاعاتی یا تشخیصی است. برای مقایسهٔ اجراها مفید است، اما بهتنهایی وجود VPN یا دستکاری را ثابت نمیکند.
ترتیب بازگشتی getifaddrs() تضمین نمیکند رابط انتخابشده مسیر پیشفرض اصلی را حمل کند؛ یک رابط نیز ممکن است چند رکورد نشانی داشته باشد. فیلتر زیررشته ناقص است و شاید رابط شبیه VPN را انتخاب کند. هیچ همبستگی با مقصد مسیر وجود ندارد.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
برای سیگنال تشخیصی، ابتدا هیچ چیزی را «اصلاح» نکنید. روی همان دستگاه بدون VPN خط مبنا ثبت کنید و سپس آزمون را با VPN و تحت همان شبکه، دما و بار تکرار کنید. فقط تفاوت تکرارپذیر میان دو مجموعه برای تحلیل مفید است. یک مقدار MTU، زمانبندی یا GSO بهتنهایی مدرک نیست. نام رابط را با مسیر پیشفرض مقایسه کنید. فقط برای رسیدن به مقدار «معمول» 1500، MTU را تغییر ندهید؛ شبکههای همراه و overlay بهطور مشروع از مقادیر دیگری استفاده میکنند.
ماژول روت میتواند این شاخص را تغییر دهد، اما تنظیم آن برای رسیدن به عددی خاص بهآسانی TCP/UDP، DNS، تماسها یا مصرف انرژی را مختل میکند. VPNHide Next ادعا میکند چند پارامتر غیرمستقیم را فیلتر میکند، ولی این قابلیتها باید جدا از پنهانسازی پایهٔ رابط آزموده شوند. پیش از داشتن خط مبنای پاک و روش بازگردانی عملی، بیشترین مجموعهٔ هوکهای هسته را فعال نکنید. هر جایگزینی MTU باید در ioctl، sysfs، netlink، MSS مربوط به TCP و forwarding واقعی سازگار بماند. مقدار ناسازگار سیگنالهای بیشتر و اتلاف بسته ایجاد میکند.
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'
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
MTU بیش از حد بالا میتواند black-hole routing یا fragmentation ایجاد کند؛ مقدار بسیار پایین کارایی را کم میکند. بدون آزمون ICMP، QUIC و TCP تغییر سراسری اعمال نکنید.
MTU اصلی را در پیکربندی VPN یا رابط بازگردانید، یا NetworkStack و VPN را دوباره راهاندازی کنید. پیش از تغییر، مقدار اصلی را ثبت کنید.
پایین. الگوریتم نخستین تطبیق و نبود آستانه راستیآزمایی شدهاند؛ اطلاعاتی.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: pmtu-mss-combined, udp-pmtu-ok, tuntap-type.