RKNHardering Help

رابط VPN در /proc/net/if_inet6

شناسه: PROC_IF_INET6_VPN دسته: رابط‌ها وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا

این صفحه پیاده‌سازی واقعی RKNHardering 2.10.0 را توضیح می‌دهد. در آن مشخص شده است چه اقدام‌هایی بدون روت ممکن‌اند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش می‌دهد، بی‌آن‌که VPN را به‌طور کامل پنهان کند.

چه چیزی بررسی می‌شود و چرا

پروب /proc/net/if_inet6 و /proc/self/net/if_inet6 را بررسی می‌کند. هر خط به شش توکن تقسیم می‌شود و توکن ششم نام رابط در نظر گرفته می‌شود. نام‌های tun0، tun1، utun0، wg0، ppp0 و xfrm0 شمرده می‌شوند؛ تابع پس از نخستین فایل قابل دسترسی که تطبیق داشته باشد متوقف می‌شود.

شرط دقیق فعال‌شدن

یک یا چند ردیف با نام ثابت رابط VPN در جدول رابط‌های IPv6 پیدا شود.

معنای نتیجه

یک دستگاه شبکهٔ شبیه VPN نشانی IPv6 دارد و از طریق procfs قابل مشاهده است. حتی وقتی ترافیک اصلی IPv4 باشد، این یک اثر مستقیم است.

تأثیر این خط بر گزارش: این خط detected=true را تنظیم می‌کند و به‌عنوان یک نشانهٔ محلی با اطمینان بالا در نظر گرفته می‌شود.

محدودیت‌ها و مثبت‌های کاذب احتمالی

رابط بدون نشانی IPv6 در اینجا دیده نمی‌شود. دسترسی به procfs به نسخهٔ Android و سیاست SELinux بستگی دارد. فهرست نام‌ها محدود است و چند نشانی روی یک رابط شمارش را افزایش می‌دهد.

این خط باید همراه با سیگنال‌های مجاور ارزیابی شود. پاک‌بودن نتیجهٔ یک API به‌تنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکت‌های محلی و نشانه‌های سمت سرور را هم‌زمان پوشش نمی‌دهد.

توصیه‌ها برای این بردار

بدون روت

مطمئن‌ترین روش بدون روت این است که روی تلفن تحت آزمون رابط VPN ساخته نشود: تونل را به روتر، روتر مسافرتی، تلفن جداگانهٔ دروازه یا گره دیگری از شبکه منتقل کنید. دورزدن به‌ازای برنامه در VpnService مسیر برنامهٔ انتخاب‌شده را تغییر می‌دهد، اما establish() همچنان رابط VPN سیستمی می‌سازد؛ بنابراین بررسی محلی رابط‌ها ممکن است همچنان فعال شود. حالت پراکسی محلی HTTP/SOCKS بدون TUN گاهی این بردار مشخص را حذف می‌کند، ولی درگاه‌های شنود و تنظیمات پراکسی را باقی می‌گذارد و برنامه‌های بی‌اعتنا به پراکسی را پوشش نمی‌دهد. غیرفعال‌کردن IPv6 داخل VPN ممکن است همین خط را حذف کند، اما اتصال را تضعیف می‌کند و رابط را از مسیر IPv4 یا netlink پنهان نمی‌سازد. این دورزدن کامل نیست.

با روت

پنهان‌سازی در سطح آزمایشگاه معمولاً هم به یک لایهٔ Java سیستمی و هم به یک پس‌زمینهٔ بومی نیاز دارد. در VPNHide یعنی APK به‌همراه Vector/LSPosed با دامنه‌ای محدود به System Framework، و دقیقاً یکی از kmod، KPM یا Zygisk. برای بررسی‌ای که ممکن است syscall مستقیم یا netlink به‌کار ببرد، kmod یا KPM ترجیح دارد: هوک Zygisk در فضای کاربر قابل دورزدن است و داخل فرایند رد باقی می‌گذارد. ابتدا نقشهٔ پوشش VPNHide را بررسی کنید و ساخت‌ها را فقط از صفحهٔ رسمی انتشار بگیرید. VPNHide Next پوشش گسترده‌تری ادعا می‌کند، اما دربارهٔ احتمال حلقهٔ بوت و کرنل پنیک نیز هشدار می‌دهد؛ آن را فقط روی دستگاه اختصاصی آزمون کنید. در زمان نگارش مستنداتش، VPNHide بالادستی /proc/net/if_inet6 را برای پس‌زمینه‌های هسته شکافی فقط قابل پوشش با Zygisk معرفی می‌کرد. به‌جای اتکا به نام ماژول، نسخهٔ فعلی و پس‌زمینهٔ مشخص را بررسی کنید.

روش راستی‌آزمایی نتیجه

adb shell 'cat /proc/net/if_inet6 2>/dev/null || cat /proc/self/net/if_inet6 2>/dev/null'
adb shell 'ip -6 addr show'

پس از هر تغییر، RKNHardering و سرویس‌گیرندهٔ VPN را به‌اجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژول‌های هسته معمولاً به راه‌اندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنال‌های مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد می‌کند.

مجوزهای لازم و خطرها

خود پروب با مجوزهای معمول برنامه اجرا می‌شود و روت درخواست نمی‌کند. دستورهای ADB زیر فقط برای جهت‌یابی تشخیصی‌اند: adb shell با UID دیگری اجرا می‌شود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیین‌کننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.

خطرها

غیرفعال‌کردن سراسری IPv6 شبکه‌های فقط IPv6 و NAT64، DNS64 و بخشی از اتصال همراه را خراب می‌کند. این را نخستین اقدام قرار ندهید.

بازگردانی

تنظیمات IPv6 در VPN و سیستم را بازگردانید، فیلتر هدفمند را حذف و دستگاه را ریبوت کنید. دادهٔ همراه و Wi‑Fi را جداگانه بیازمایید.

سطح شواهد

بالا. هر دو مسیر، توکن [5] تجزیه‌گر و فهرست شش‌نامی راستی‌آزمایی شده‌اند؛ نوع نتیجه بالا است.

وضعیت یک راهکار شخص ثالث خودبه‌خود به این دستگاه تعمیم پیدا نمی‌کند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجه‌ای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میان‌افزار و هسته نیاز دارد.

منابع و تاریخ آخرین راستی‌آزمایی

سیگنال‌های مرتبط: proc-ipv6-route-vpn, getifaddrs-vpn, sysfs-vpn-leak.

بازگشت به مرجع بررسی‌های بومی