شناسه:
VPN_POLICY_RULES_NETLINKدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
پروب dump مربوط به IPv4 از نوع RTM_GETRULE را درخواست و RTM_NEWRULE را تجزیه میکند. جدول از rtm_table یا RTA_TABLE، رابط خروجی از RTA_OIF و mark موقت از RTA_FLOW گرفته میشود. جدولهای 100 تا 200 در نظر گرفته میشوند؛ قاعده وقتی شبیه VPN دانسته میشود که رابط یکی از نامهای ثابت تونل باشد یا شمارهٔ جدول بین 100 و 110 قرار گیرد.
دستکم یک قاعده بدون توجه به رابط از جدول 100 تا 110 استفاده کند، یا با OIF برابر tun0، tun1، utun0، wg0، ppp0 یا xfrm0 از جدول 100 تا 200 استفاده کند.
پایگاه دادهٔ policy مسیریابی قاعدهای دارد که heuristic آن را مرتبط با VPN میداند. بررسیکننده ردیف را اطمینان بالا در نظر میگیرد.
تأثیر این خط بر گزارش: این خط detected=true را تنظیم میکند و بهعنوان یک نشانهٔ محلی با اطمینان بالا در نظر گرفته میشود.
بازههای جدول heuristic هستند و ممکن است با پیکربندی OEM، سازمانی، tethering یا مسیریابی سفارشی همپوشانی داشته باشند. در اینجا RTA_FLOW با عنوان fwmark ثبت شده، هرچند قواعد policy در Linux معمولاً از FRA_FWMARK استفاده میکنند؛ بنابراین جزئیات ممکن است ناقص باشد. فقط AF_INET بررسی میشود، نه IPv6.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
بدون روت، طراحی مسیریابی را اصلاح کنید، نه نحوهٔ نمایش جدول را. برای تلفنی پاک از دروازهٔ خارجی استفاده کنید. اگر VPN در VpnService باقی میماند، split routing را طوری تنظیم کنید که برنامهٔ تحت آزمون واقعاً از شبکهٔ فیزیکی مورد انتظار خارج شود؛ اما این را پنهانسازی مسیرهای محلی ندانید، زیرا رابط و قواعد policy ممکن است قابل مشاهده بمانند. روی دستگاه در حال استفاده مسیرها را با ip route حذف نکنید؛ Android و سرویس VPN آنها را دوباره میسازند و ممکن است اتصال قطع شود. اگر سرویسگیرندهٔ VPN قاعده را میسازد، غیرفعالکردن حالت TUN/VpnService آن را حذف میکند. استثناکردن یک برنامه الزاماً قواعد مشترک را حذف نمیکند.
روی دستگاه روتشده، پسزمینه باید منبع داده را فیلتر کند، نه فقط libc را. در VPNHide بالادستی، پسزمینههای هسته برای ioctl، netlink و برخی بردارهای route/procfs طراحی شدهاند و Zygisk یک گزینهٔ مشروط باقی میماند. kmod و KPM را همزمان نصب نکنید، زیرا ممکن است همان توابع هسته را رهگیری کنند. VPNHide Next پوشش گستردهتری برای PMTU/MSS/qdisc/BPF ادعا میکند، اما این ادعای بیرونی باید روی همان هسته بازتولید شود. پسزمینههای هستهٔ VPNHide بالادستی فیلتر RTM_GETRULE را ادعا میکنند. پس از نصب، UID هدف را با تصویر پوسته مقایسه کنید، زیرا فیلتر قواعد باید مختص UID باشد.
adb shell ip rule show
adb shell ip -details rule show
adb shell ip route show table all
جدولهای 100 تا 200، مقادیر OIF و مقصدهای واقعی را با هم مرتبط کنید. تا زمانی که سازندهٔ قاعده را نمیدانید آن را حذف نکنید.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
حذف قاعدهٔ policy ممکن است دسترسی شبکهٔ VPN، UID سیستمی، IMS، tethering یا پروفایل کاری را از بین ببرد. فیلتر اشتباه netlink ممکن است خود مسیریابی را تغییر دهد، نه فقط نمای نمایشدادهشده را.
پیش از تغییر، خروجی ip rule show و ip route show table all را ذخیره کنید. VPN یا NetworkStack عادی را بازگردانید، ماژول را غیرفعال و دستگاه را ریبوت کنید؛ Android معمولاً قواعد سیستمی را دوباره میسازد.
بالا. تجزیهگر RTM_GETRULE، بازههای جدول و نگاشت HIGH_CONFIDENCE راستیآزمایی شدهاند. نادقتی RTA_FLOW/fwmark نیز مستند شده است.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: vpn-policy-rules, route-table, route-count.