RKNHardering Help

رابط‌های IPsec/XFRM

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

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

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

رابط‌های فعال با عبارت منظم ^(ipsec|xfrm).* تطبیق داده می‌شوند. برخلاف الگوهای TUN، این خط اطلاعاتی است: Android، VPNهای OEM و مؤلفه‌های سیستمی IPsec می‌توانند به‌طور مشروع چنین رابط‌هایی بسازند.

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

هر رابط فعال با نام ipsec* یا xfrm* یک خط اطلاعاتی شامل نام و شاخص خود ایجاد می‌کند.

معنای نتیجه

این سیگنال به‌تنهایی دسته را «شناسایی‌شده» علامت نمی‌زند و به دورزدن نیاز ندارد. فقط وقتی با مسیرها، دادهٔ XFRM یا بتا، IP خارجی یا انتقال فعال VPN ترکیب شود مفید است.

تأثیر این خط بر گزارش: این خط اطلاعاتی یا تشخیصی است. برای مقایسهٔ اجراها مفید است، اما به‌تنهایی وجود VPN یا دست‌کاری را ثابت نمی‌کند.

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

IPsec می‌تواند بدون رابط جداگانه از وضعیت policy/XFRM استفاده کند و OEM نیز ممکن است نام دیگری برگزیند. از سوی دیگر، یک پروفایل سازمانی می‌تواند به‌طور کاملاً مشروع رابط XFRM بسازد.

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

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

بدون روت

اگر واقعاً به IPsec نیاز ندارید، VPN سازمانی یا پروفایل همیشه‌روشن مربوط را از کنترل‌های عادی سیستم غیرفعال کنید. اگر لازم است، فقط به‌خاطر یک خط اطلاعاتی نام رابط را عوض نکنید. دروازهٔ خارجی وضعیت IPsec را از تلفن خارج می‌کند.

با روت

فیلتر در سطح هسته فقط در قالب پنهان‌سازی سازگار رابط‌ها، مسیرها و وضعیت XFRM معنا دارد. وضعیت XFRM را با ip xfrm state flush پاک نکنید؛ این کار اتصال را قطع می‌کند و ممکن است سیاست سازمان را نقض کند. برای آزمایش از دستگاهی جداگانه استفاده کنید.

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

adb shell ip -details link show | grep -Ei 'ipsec|xfrm'
adb shell ip xfrm state 2>&1 | head -80
adb shell ip xfrm policy 2>&1 | head -80

ممکن است بخشی از داده‌های XFRM از پوستهٔ معمولی در دسترس نباشد؛ این به‌معنای نبود آن‌ها نیست.

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

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

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

خطرها

غیرفعال‌کردن VPN همیشه‌روشن یا حالت lockdown ممکن است حفاظت اجباری ترافیک را بردارد. تغییر وضعیت XFRM به دسترسی ویژه نیاز دارد و نشست را فوراً قطع می‌کند.

بازگردانی

پروفایل سازمانی یا پیکربندی VPN را بازگردانید و سپس شبکه را دوباره راه‌اندازی کنید. اگر از ماژول روت استفاده کرده‌اید، آن را غیرفعال و دستگاه را ریبوت کنید.

سطح شواهد

پایین. با NetworkInterfacePatterns.IPSEC_INTERFACE_PATTERN و شاخهٔ اطلاعاتی evaluateInterfaces() راستی‌آزمایی شده است.

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

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

سیگنال‌های مرتبط: interface-enumeration, vpn-policy-rules-netlink, route-table.

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