چرا یک برنامه مسدودشده در اندروید هنوز مصرف شبکه نشان می‌دهد

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

شمارنده بایت‌ها را می‌شمارد، نه تحویل را

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

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

به همین دلیل سطر یک برنامه مسدودشده می‌تواند بالا برود در حالی که هر درخواست شکست می‌خورد. شمارنده به پرسش «چند بایت به این هویت نسبت داده شد» پاسخ می‌دهد، نه «آیا این هویت به اینترنت رسید». یک نمودار نمی‌تواند جریان پذیرفته‌شده را از دست‌دادنی مؤدبانه ردشده تشخیص دهد، و مجموعی که هر دو جهت را با هم جمع می‌کند نیز نمی‌تواند.

انتساب از UID پیروی می‌کند، نه از نماد

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

وقتی اعداد اشتباه به نظر می‌رسند، UID را مقایسه کنید نه برچسب را. API مصرف بر پایه UID پرسیده می‌شود و adb shell dumpsys package <package> | grep userId= عددی را چاپ می‌کند که باید با آن مقایسه کنید، پس دو ورودی با UID یکسان از دید شمارنده یک هویت‌اند.

پنجره زمانی ممکن است پیش از قاعده شما باشد

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

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

ممکن است سرویس VPN همانی نباشد که پیکربندی کردید

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

IPv4، IPv6 و DNS هم می‌توانند واگرا شوند. فیلتری که IPv4 را مدیریت می‌کند ممکن است IPv6 یا یک حل‌کننده DNS خصوصی را بیرون بگذارد، پس بخشی از ترافیک برنامه مسیری را می‌پیماید که قواعد شما هرگز توصیف نکرده‌اند. پیش از بازنویسی هر چیزی بررسی کنید کدام برنامه اکنون مالک VPN است و فهرست استثناها چه می‌گوید:

adb shell settings get secure always_on_vpn_app
adb shell dumpsys connectivity
adb shell dumpsys netstats detail

یک درخواست تازه را بیازمایید و چهار واقعیت ثبت کنید

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

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