برنامه استثناشده هنوز آنلاین است؟ قواعد هر برنامه و مسیرها متفاوتاند
استثنا کردن یک برنامه اندروید از VPN آن را مسدود نمیکند. فهرستهای مجاز، قواعد UID و مسیرهای ارسالی هر یک بخش متفاوتی از مسیر را تعیین میکنند.
استثنا کردن یک بسته دستور مسیریابی است، نه مسدودسازی، پس صفحههایی که پس از اتصال VPN بارگذاری میشوند مورد انتظارند و نشانه خرابی نیستند. استثنا برنامه را از تونل بیرون میآورد بهجای اینکه مسدودش کند، و شبکه معمولی ترافیک آن را حمل میکند. اینجا دو سیاست جدا به هم میرسند: یکی فرایندها را انتخاب میکند، دیگری مقصدها را. خواندن آنها به این ترتیب توضیح میدهد چرا نماد متصل و برنامهای که کار میکند تناقض نیستند.
چرا استثنا شبکه را باز نگه میدارد
VpnService.Builder یا فهرست مجاز میپذیرد یا فهرست ممنوع، هرگز هر دو را. تنها بستههای فهرست مجاز از تونل عبور میکنند. فهرست ممنوع این را برعکس میکند: هر بسته بهجز موارد فهرستشده از تونل استفاده میکند و موارد فهرستشده مسیر فیزیکی را نگه میدارند. بستهای که در فهرست مجاز نیامده نیز بیرون تونل است، پس استثنا در این حالت وضعیت عادی بیشتر برنامههاست.
این یک ورودی ممنوع محلی را به تصمیم مسیریابی تبدیل میکند، نه قاعده فایروال. اگر الزام این است که برنامهای به میزبان نرسد، تونل باید آن را بپوشاند و سرور یا سیاستی محلی باید ترافیک را رد کند. بیرون آوردن یک برنامه از تونل فقط تغییر میدهد کدام رابط بستههایش را حمل میکند.
مورد Play Store نمونه عمدی معمول است. استثنا کردن بسته فروشگاه باعث میشود دانلودها هنگام اختلال خروجی VPN در انتقالها از اتصال زیرین استفاده کنند، و نشان میدهد استثنا یعنی دور زدن، نه مسدودسازی.
یک پروفایل، یک فهرست
سازنده اگر هر دو فراخوانی استفاده شود خطا میدهد، پس پروفایلی که پیش شماست یا فهرست مجاز است یا فهرست ممنوع. همین یک واقعیت تعیین میکند هر مشاهده بعدی را چگونه بخوانید. پیش از جدول مسیریابی کد یا پیکربندی مدیریتشده را بررسی کنید، چون فهرست تعیین میکند بقیه خروجی چه معنایی دارد. پروفایل ترکیبی حالتی نیست که بتوانید به آن نگاه کنید.
این تفاوت همچنین پیشبینی میکند برنامه تازهنصبشده چه خواهد کرد. در فهرست مجاز بیرون میماند تا کسی آن را اضافه کند، و در فهرست ممنوع بهطور پیشفرض به تونل میپیوندد.
پیکربندیهای مدیریتشده همان انتخاب را زیر نامهای کلید متفاوت ارائه میدهند و برخی کنسولها آن را حالت VPN هر برنامه مینامند نه فهرست. رفتار همچنان به همان دو فراخوانی فروکاسته میشود، پس تنظیم را تا فهرست بستهها عقب ببرید و به برچسب اعتماد نکنید. اگر برچسب و فهرست ناسازگار باشند، فهرست برنده است.
قاعده UID را تا جدول تونل دنبال کنید
اندروید به هر برنامه شناسه کاربری لینوکس خودش را میدهد و سرویس VPN قواعد سیاستی نصب میکند که با بازههای UID منطبقاند. ترافیک منطبق به جدول مسیریابیای فرستاده میشود که مسیر پیشفرضش به دستگاه tun اشاره دارد. شماره جدول برای هر نمونه VPN تخصیص مییابد، پس پس از اتصال دوباره یا ساخت پروفایل دوم VPN تغییر میکند.
خروجی قواعد همان نقشه است. هر سطر یک جدول جستجو را نام میبرد و آن جدول مسیر پیشفرضی را نگه میدارد که تعیین میکند بستههای منطبق وارد تونل میشوند یا نه.
adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>
ابتدا فرمان سوم را اجرا کنید تا UID را بگیرید، سپس قاعدهای را بیابید که بازهاش آن را در بر میگیرد. آن قاعده به شماره جدولی اشاره میکند، و ip route show table <n> با آن شماره نشان میدهد آیا مسیر پیشفرضی از دستگاه tun وجود دارد. اگر جدول پیشفرضی نداشته باشد، برنامه انتخاب شده اما مسیری ندارد، که خرابی دیگری است.
این فرمانها به بیلد قابل اشکالزدایی یا دستگاهی نیاز دارند که adb shell بتواند وضعیت شبکه را در آن بخواند. روی گوشی تولیدی مدیر بسته هنوز پاسخ میدهد، اما بازرسی مسیریابی ممکن است رد شود، پس هر چه میتوانید ثبت کنید و بقیه را تأییدنشده بدانید.
مسیر یک پیشوند را ادعا میکند، نه یک برنامه
Builder.addRoute پیشوندهای مقصد را برای تونل ادعا میکند. پروفایلی که فقط 10.0.0.0/8 اضافه میکند آن پیشوند را از تونل میفرستد و هر مقصد دیگر را روی مسیر فیزیکی میگذارد. این تونلسازی تقسیمی عادی است و به اینکه قواعد کدام برنامهها را انتخاب کردهاند بستگی ندارد.
پیکربندی ارسالی سرور همان مدل را بازتاب میدهد. ارسالهای مسیر جداگانه پیشوندها را اضافه میکنند، در حالی که دستور redirect-gateway مسیر پیشفرض را جایگزین میکند و همهچیز را برای برنامههایی که تونل میپوشاند میگیرد. حذف آن دستور میتواند تونلی کارآمد را بدون هیچ تغییری روی دستگاه به یک زیرشبکه کوچک کند.
مسیر ارسالی با گیتوی یا سنجه غیرمعمول نیز ممکن است نصب نشود. شکل ساده پیشوند را ترجیح دهید و ارسال و NAT را به سرور بسپارید.
پیش از تغییر یک تنظیم، اشتراک را بخوانید
تونل اشتراک فرایندهای پوششدادهشده و مقصدهای ادعاشده را حمل میکند. برنامه پوششدادهشدهای که نشانی بیرون از پیشوندهای منتشرشده بخواهد، از شبکه فیزیکی خارج میشود. بسته ممنوعشده حتی وقتی نشانی درون آن پیشوندها بخواهد بیرون میماند. هیچکدام باگ نیست؛ هر دو همان دو سیاستاند که کار خود را میکنند.
VPN هر برنامه میتواند برنامه مرتبط را نیز بدون اتصال بگذارد. وقتی on-demand خاموش است و تونل پایین، برنامه به VPN هر برنامه وابسته میماند و راه جایگزینی ندارد، که شبیه برنامه خراب است نه وضعیت سیاست. روشن کردن on-demand یا حذف ارتباط از طریق مدیریت این را تغییر میدهد.
| Layer | What it selects | Where to look | Typical mismatch |
|---|---|---|---|
| Package list | Processes | Builder calls or managed configuration | App excluded but expected to be blocked |
| UID policy rule | Which table a UID uses | ip rule show | Tunnel icon on, app still on Wi-Fi |
| Routing table | Destinations for matched traffic | ip route show table <n> | Covered app reaches only one subnet |
| Server push | Prefixes offered to the client | Server route configuration | Tunnel shrinks after a server edit |
هر بار یک محور را عیبیابی کنید. نخست مجاز یا ممنوع را تأیید کنید، دوم قواعد UID و جدولهای نصبشده را بخوانید، و آخر برنامه دوم را روی همان مقصد بیازمایید. برنامه دوم در یک درخواست، انتخاب فرایند را از انتخاب مقصد جدا میکند.
نتیجه را بهصورت برنامه، مقصد و شماره جدول بنویسید. همان سهگانه چیزی است که تغییر بعدی باید حفظش کند.