حالت SOCKS در NetGuard فقط TCP را پوشش می‌دهد، نه هر پروتکلی

NetGuard رابط VPN اندروید را اشغال می‌کند تا ترافیک را فیلتر کند و می‌تواند اتصال‌های پشتیبانی‌شده را به یک نقطه پایانی SOCKS بسپارد. این دو واقعیت را اغلب «تلفن روی VPN است» می‌خوانند، نتیجه‌ای که مکانیزم از آن پشتیبانی نمی‌کند. فیلتر بسته‌ها را می‌بیند؛ پروکسی فقط اتصال‌هایی را می‌بیند که واقعاً به آن سپرده شده‌اند. میان این دو گزاره، تمام پرسش پوشش قرار دارد.

پرسش‌های متداول پروژه بالادستی هم محدودیت تک‌سرویسی و هم گزینه SOCKS را مستند می‌کند. وجود این گزینه شاهدی بر آن نیست که هر بسته مجاز از آن استفاده می‌کند، و پرسش‌های پوشش دقیقاً از همین شکاف برمی‌خیزند.

دو مسیر ارسال درون یک برنامه

سمت TCP پیاده‌سازی شامل پردازش اتصال‌های SOCKS است، بنابراین یک اتصال TCP مجاز می‌تواند با پروکسی مذاکره و از طریق آن منتقل شود. سمت UDP مسیر سوکت جداگانه‌ای دارد و پردازش ارسال و دریافتش به آن مذاکره TCP وابسته نیست. بنابراین بسته داده‌ای که فیلتر اجازه می‌دهد می‌تواند بدون اینکه هرگز از پروکسی بگذرد به شبکه معمولی برسد. هیچ‌کدام از این‌ها نقص برنامه نیست؛ فقط همان است که دو مسیر پیاده می‌کنند.

این تمایز پیامدی دارد که مردم آن را در هر دو جهت اشتباه بیان می‌کنند. نامیدن هر بسته UDP به‌عنوان نشت، قواعد مسدودسازی را نادیده می‌گیرد، زیرا بسته داده ردشده هرگز خارج نمی‌شود. نامیدن کل چیدمان به‌عنوان VPN، مسیر مستقیم مجاز را نادیده می‌گیرد، زیرا بخشی از ترافیک واقعاً بدون پروکسی خارج می‌شود. آنچه دارید دستگاهی فیلترشده با پروکسی جزئی است، و توصیف صادقانه یک ماتریس است نه یک برچسب.

تبلیغ UDP به معنای پیاده‌سازی آن نیست

سرور SOCKS که ادعای پشتیبانی UDP دارد، پردازش سمت کلاینت متناظر را به برنامه روی گوشی شما اضافه نمی‌کند. ویژگی‌های نظری پروتکل و رفتار نسخه نصب‌شده موضوع‌های متفاوتی هستند و تنها دومی ترافیک شما را توصیف می‌کند.

نسخه و پیکربندی‌ای را که واقعاً اجرا می‌کنید بررسی کنید، سپس یک جریان بسته داده بی‌ضرر را آزمایش کنید و ببینید آیا در پروکسی ظاهر می‌شود. هر چیز دیگری استنتاجی از فهرست ویژگی‌ها است، و فهرست ویژگی‌ها نیت‌ها را توصیف می‌کند نه مسیرهای کد.

DNS مسیر سوم است، نه جزئیات

حل نام شاخه خود را به ماتریس اضافه می‌کند. یک ارسال‌کننده محلی DNS، یک جست‌وجوی معمولی UDP، نام میزبان مقصدی که خود پروکسی حل می‌کند و یک حل‌کننده رمزنگاری‌شده در مرورگر چهار چیدمان متمایز هستند. آن‌ها در این تفاوت دارند که چه کسی پرس‌وجو را می‌بیند و کدام مسیر شبکه آن را حمل می‌کند، و آمیختن آن‌ها آزمونی می‌سازد که درباره بقیه چیزی اثبات نمی‌کند.

آگاهانه تصمیم بگیرید کدام را می‌خواهید. اگر الزام این است که نام‌ها از طریق تونل حل شوند، تنها یک تنظیم مرورگر آن را فراهم نمی‌کند، و پروکسی‌ای که خودش نام میزبان‌ها را حل می‌کند پاسخ را فقط برای اتصال‌هایی تغییر می‌دهد که واقعاً مدیریت می‌کند.

انتقال از طریق پروکسی به‌طور خودکار خصوصی نیست

SOCKS ساده یک پیوند رمزنگاری‌شده از گوشی به پروکسی نیست. اگر به نقطه پایانی از مسیر محافظت‌شده دیگری رسیده می‌شود، آن مسیر و سیاست شکستش را نام ببرید، زیرا بازگشت به شبکه باز بدون هشدار یک چیدمان خصوصی را عمومی می‌کند. احراز هویت خود پروکسی هم مهم است: شنونده باز روی دستگاهی مشترک سرویسی است که هیچ‌کس پاسخگوی آن نیست.

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

پوشش را با ماتریس ممیزی کنید، نه با بارگذاری صفحه

برای ارزیابی مجاز، نمونه‌های بی‌ضرری انتخاب کنید که هر طبقه‌ای را که برایتان مهم است نمایندگی کنند: TCP لازم، UDP مجاز و DNS در هر دو خانواده نشانی. برای هرکدام ثبت کنید که آیا از پروکسی گذشت، مسدود شد یا مستقیم ارسال شد. همان یک جدول تحویل‌شدنی است و بسیار سودمندتر از تصویر صفحه‌ای است که بارگذاری شده.

اگر الزام این است که تمام ترافیک انتخاب‌شده برنامه‌ها از یک تونل دور بگذرد، پیاده‌سازی‌ای برگزینید که فیلترینگ و تونل‌سازی ترکیبی را صریحاً پشتیبانی کند. ترکیب پروکسی فقط TCP برای کارهای محدودتر سودمند می‌ماند، به شرط آنکه ترافیک دیگر آگاهانه مدیریت شود نه فراموش.