برنامه VPN مخاطبین و دسترس‌پذیری می‌خواهد: چه چیزی را مجاز کنیم

نصب‌کننده نخست دسترسی به شبکه را می‌خواهد، سپس مخاطبین، دسترس‌پذیری و نصب یک گواهی. تنها درخواست نخست به این کار مربوط است. تصمیم واقعی در صفحهٔ دوم گرفته می‌شود.

هر درخواست را در برابر ویژگی‌ای که خود برگزیده‌اید، روی سکویی که اجرا می‌کنید بسنجید. هیچ فهرست مجوز جهانی همهٔ محصولات VPN را پوشش نمی‌دهد، و یک فهرست بلند به خودی خود چیزی را ثابت نمی‌کند.

تنها مجوزی که این کار واقعاً لازم دارد

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

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

دسترسی اضافی مجوزی جداگانه با اثرهای جداگانه است. کارخواه مسیریابی که آن را می‌خواهد به دلیل خود نیاز دارد.

جایی که درخواست‌های اضافی به روایت خود نیاز دارند

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

هر یک از این‌ها می‌تواند مشروع باشد. محصولات دستگاه مدیریت‌شده و کنترل والدین ممکن است به اختیارات سیاستی نیاز داشته باشند، و یک ابزار پشتیبانی ممکن است برای راهنمایی شما در تنظیمات به دسترس‌پذیری نیاز داشته باشد.

شرط، ردیابی‌پذیری است: درخواست به ویژگی‌ای نام‌برده اشاره می‌کند، و آن ویژگی در محصولی که نصب کرده‌اید دیده می‌شود. درخواست مخاطبین بدون صفحهٔ مرتبط با مخاطبین توضیحی برای ارائه ندارد. استدلال رمزنگاری هم منتقل نمی‌شود، زیرا محافظت از بسته‌ها چیزی دربارهٔ اینکه دوستانتان چه کسانی هستند نمی‌گوید. یک محصول مشروع هنوز می‌تواند از طریق یک کتابخانهٔ همراه بیش از حد درخواست کند، و این نقصی است که باید گزارش شود، نه جرمی که باید اعلام شود.

درخواست و ویژگی‌ای که به آن مربوط است را ثبت کنید، سپس تصمیم بگیرید. همین یادداشت چیزی است که پس از یک رد، وقتی ویژگی‌ای خراب می‌شود، به پشتیبانی نشان می‌دهید.

خواندن درخواست روی دستگاه

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

دو پرس‌وجو بیشتر آن را پوشش می‌دهد:

adb shell dumpsys package com.example.vpn | grep -E "requested permissions|install permissions" -A 30
adb shell cmd appops get com.example.vpn

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

این صفحه‌ها یک دقیقه وقت می‌گیرند و به هیچ نرم‌افزاری نیاز ندارند. دسترس‌پذیری، مدیریت دستگاه و انبار گواهی‌ها هر یک برنامه‌های دارای مجوز را فهرست می‌کنند.

تصمیم گرفتن، سپس محدود کردن آسیب

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

پس گرفتن یک مجوز معمولاً یک ویژگی را غیرفعال می‌کند بدون حذف برنامه یا از هم پاشیدن هر نمایه. پس از آن دوباره وصل شوید و تأیید کنید که تونل هنوز برقرار می‌شود.

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