RKNHardering Help

پورت‌های UDP مرتبط با VPN و اشغال‌شده روی نشانی فیزیکی IPv4

شناسه: UDP_PORT_CONFLICT_PHYSICAL دسته: آثار VPN و سوکت‌ها وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا

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

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

پروب نخستین نشانی IPv4 را از getifaddrs() می‌گیرد، با حذف نام رابط‌هایی که شامل tun، wg، ppp، xfrm، utun یا lo هستند. سپس SO_REUSEADDR را فعال و تلاش می‌کند سوکت UDP را روی همان IP به پورت‌های 500، 4500، 1194، 1701 و 51820 bind کند. فقط EADDRINUSE پورت را به نتیجه می‌افزاید.

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

حداقل یکی از پنج پورت UDP روی نشانی IPv4 انتخاب‌شده به‌عنوان «فیزیکی» از قبل اشغال باشد.

معنای نتیجه

روی این نشانی محلی bind متعارض وجود دارد که اغلب با IKE/IPsec، OpenVPN، L2TP یا WireGuard مرتبط است. بررسی‌کننده این سیگنال را با اطمینان بالا می‌گیرد، اما مالک پورت را مشخص نمی‌کند.

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

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

نخستین رکوردهای getifaddrs() انتخاب مسیر فیزیکی اصلی را تضمین نمی‌کنند و ممکن است رابط container یا OEM اشتباه انتخاب شود. این پورت‌ها استفادهٔ مشروع نیز دارند. SO_REUSEADDR/SO_REUSEPORT و semantics مربوط به bind می‌توانند نتیجه‌های متفاوتی بسازند.

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

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

بدون روت

ابتدا خود اثر واقعی را رفع کنید: listener، پورت API، daemon محلی یا سرویس‌گیرندهٔ VPN غیرضروری را متوقف کنید؛ سپس برنامه‌ها را force-stop و آزمایش را تکرار کنید. وقتی VPN لازم است، دروازهٔ خارجی معمولاً از هر bypass محلی تمیزتر است. پروفایل دوم شاید دید بسته‌ها را محدود کند، اما پنهان‌شدن اشیای شبکه را تضمین نمی‌کند و سیگنال کاربر/پروفایل خودش را ایجاد می‌کند. فقط VPN یا listener سروری را متوقف کنید که می‌شناسید. VpnService سمت کاربر در Android معمولاً نیازی ندارد روی این پورت‌ها و IP فیزیکی گوش دهد؛ پس ابتدا مالک را شناسایی کنید.

با روت

روت می‌تواند داده را برای UID مشخص فیلتر کند، اما سطح تشخیص خودش را می‌افزاید. در VPNHide نقش‌های Apps و Ports به‌ترتیب PackageManager و localhost را پوشش می‌دهند و backend بومی مسیرهای پشتیبانی‌شدهٔ رابط و route را مدیریت می‌کند. برای پورت غیراستاندارد، پیش از تلاش برای پوشاندنش API کنترل را غیرفعال کنید. هر قاعدهٔ iptables/nftables را از طریق ماژولی با مسیر بازگردانی روشن اعمال کنید و loopback نسخهٔ IPv4 و IPv6 را جداگانه بیازمایید. برای شناسایی مالک از ss -ulpn یا lsof با روت استفاده کنید. پیش از تأیید فرایند، پورت را پنهان نکنید؛ جابه‌جایی listener از هوک هسته تمیزتر است.

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

adb shell su -c 'ip -4 -br addr; ss -H -u -l -n -p | grep -E ":(500|4500|1194|1701|51820)( |$)"'

connection/listener not shown یک bind کوتاه‌عمر یا مخصوص namespace را رد نمی‌کند؛ بررسی داخلی را تکرار کنید.

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

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

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

خطرها

توقف فرایند IKE، IMS یا VPN ممکن است ارتباط موبایل یا تونل سازمانی را قطع کند. فایروال bind را آزاد نمی‌کند و بنابراین لزوماً این سیگنال را حذف نمی‌کند.

بازگردانی

سرویس یا VPN متوقف‌شده را دوباره راه بیندازید، پورت قبلی را برگردانید و فقط قاعدهٔ موقت ویژهٔ UID را حذف کنید. ریبوت معمولاً سوکت‌های آزمایشی را آزاد می‌کند.

سطح شواهد

بالا. انتخاب نخستین IPv4 فیزیکی، فهرست پنج پورت و شرط EADDRINUSE راستی‌آزمایی شده‌اند؛ kind دارای اطمینان بالا است.

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

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

سیگنال‌های مرتبط: udp-vpn-port, loopback-port-conflict, established-vpn-socket.

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