RKNHardering Help

شناسهٔ قدیمی رزروشده برای درگاه‌های UDP مربوط به VPN

شناسه: UDP_VPN_PORT دسته: آثار VPN و سوکت‌ها وضعیت در RKNHardering 2.10.0: شناسه برای سازگاری حفظ شده است؛ در 2.10.0 تولیدکنندهٔ جداگانه‌ای ندارد نقش در حکم نهایی: رجیستری/سازگاری

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

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

UDP_VPN_PORT و udp_vpn_port در کاتالوگ باقی مانده‌اند و حتی به‌عنوان نوع قدیمی با اطمینان بالا علامت‌گذاری شده‌اند، اما کد فعلی C++ ردیفی از این kind تولید نمی‌کند. بررسی‌های فعال UDP تداخل درگاه روی IP فیزیکی و تشخیص‌های PMTU/GSO را پوشش می‌دهند.

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

تولیدکنندهٔ جداگانه‌ای وجود ندارد؛ بدون ردیف، سیاست اطمینان بالا فعال نمی‌شود.

معنای نتیجه

این صفحه برای سازگاری وجود دارد. درگاه‌های اشغال‌شدهٔ UDP شامل 500، 4500، 1194، 1701 و 51820 با udp-port-conflict-physical بررسی می‌شوند.

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

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

شناسهٔ اطمینان‌بالا در Kotlin ممکن است این تصور نادرست را ایجاد کند که بررسی فعال است؛ مستندات حاضر رجیستری را صریحاً از تولیدکننده جدا می‌کنند.

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

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

بدون روت

شنوندهٔ غیرضروری UDP را ببندید یا VPN را به دروازه منتقل کنید. شناسهٔ صرفاً کاتالوگی به دورزدن نیاز ندارد.

با روت

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

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

rg -n 'udp_vpn_port|udp_port_conflict_physical' app/src/main
adb shell ss -lun 2>/dev/null | head -80

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

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

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

خطرها

مسدودکردن سراسری UDP 500/4500، IPsec را از کار می‌اندازد؛ درگاه 51820 ممکن است برای WireGuard استفاده شود.

بازگردانی

فقط قاعدهٔ فایروالی را که ساخته‌اید حذف و VPN را دوباره راه‌اندازی کنید.

سطح شواهد

رجیستری/سازگاری. نگاشت کاتالوگ و نبود تولیدکننده راستی‌آزمایی شده‌اند.

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

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

سیگنال‌های مرتبط: udp-port-conflict-physical, udp-pmtu-ok, udp-pmtu-fail.

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