ولې بلاک شوې Android اپلیکیشن لا هم د شبکې کارول ښیي

تاسو په خپل Android VPN firewall کې یوه اپلیکیشن بلاک کوئ، اپلیکیشن کار کول بندوي، او د هغې د کارولو کرښه لا هم لوړېږي. زړه راښکونکی پای دا دی چې بلاک تېر شوی، یا شمېرونکی خراب شوی. له دواړو څخه هېڅ نه ترلاسه کېږي. د کارولو ریکارډ وایي چې په یوه کتنې نقطه کې هغه هویت ته بایټ منسوب شول؛ د دې په اړه هېڅ نه وایي چې لرې خدمت غوښتنه منلې وه که نه. کله چې پوه شئ کومه پوله اندازه شوې او کوم هویت ته یې بار ورکړل شوی، دواړه کتنې له یو بل سره د تضاد کولو مخه نیسي.

شمېرونکی بایټ اندازه کوي، نه تحویل

Android ترافیک یو UID ته منسوبوي او په دواړو لورو یې شمېري، او دا د انټرفیس په پوله کې کوي، نه په هغه شیبه چې د اپلیکیشن غوښتنه بریالۍ شي.

رد شوې اړیکې هڅه بیا هم پاکټونه خوځوي: SYN، بیا تنظیمول یا وروسته تکرارونه، او همدارنګه هغه DNS پوښتنه چې له دواړو مخکې وه. دا بایټونه حتی کله چې هېڅ ونه رسېدل هم شته، او په ځینو لارو کې له هر فلټر څخه مخکې شمېرل کېږي.

له همدې امله د بلاک شوې اپلیکیشن کرښه لوړېدلی شي په داسې حال کې چې هرې غوښتنې ناکامېږي. شمېرونکی د «څو بایټ دا هویت ته منسوب شول» پوښتنې ته ځواب وایي، نه د «ایا دا هویت انټرنیټ ته ورسېد» پوښتنې ته. یو ګراف نه شي کولای منل شوی بهیر له مؤدبانه رد شوي لاس نیول څخه بېل کړي، او نه هغه مجموعه چې دواړه لوري یو ځای جمع کوي.

منسوبول د نښان نه، د UID پيروي کوي

کرښه د هر UID لپاره ده، او یو UID کېدای شي له یو څخه ډېر پاکېج سره شریک شي، په داسې حال کې چې ښکاره اپلیکیشن کولای شي کار له یوې جلا برخې سره وسپاري چې په خپل هویت کار کوي. د شریک WebView پروسې لخوا جوړ شوی براوزر ټب، د شالید همغږي خدمت، یا د اصلي اپ سره نصب شوی ملګری پاکېج — ټول داسې ترافیک جوړوي چې د کارولو سکرین یې کېدای شي د هغه نوم لاندې ښکاره کړي چې تاسو تمه نه وه کړې، یا د هغه اپ لاندې چې تاسو بلاک کړی و. بلاک شوی پاکېج او د هغې غوښتنې وړونکی مرستندوی دوه جلا موضوعات دي، او قاعده یوازې یو یې پوښلی و.

کله چې شمېرې غلطې ښکاره شي، لیبل نه، UID پرتله کړئ. د کارولو API په UID پوښتل کېږي، او adb shell dumpsys package <package> | grep userId= هغه شمېره چاپوي چې پرتله پرې وکړئ، نو دوه داخلې چې یو شان UID لري د شمېرونکي له نظره یو هویت دي.

د وخت کړکۍ کېدای شي ستاسو له قاعدې مخکې وي

د کارولو معلومات په بالټیو کې راټولېږي او په دوره یي ډول پوښتل کېږي، نه ژوندي تېرېږي. ورځنی ټول کېدای شي د بلاک د فعالولو مخکې دقیقې، د تېر ساعت شالید همغږي، یا هغه ترافیک چې مخکې په لار کې و شامل کړي. یوه ټولې مجموعې له یوې رد شوې غوښتنې سره پرتله کول او توپیر ته تېریدل ویل د اندازې تېروتنه ده، د firewall موندنه نه.

لږه کړکۍ او نوی پیل وکاروئ. کله چې قاعده بدلوئ د وخت ټاپ یاد کړئ، یوه راټولولو وقفه انتظار وکړئ، بیا یوازې له هغې وروسته معلومات وګورئ. که ټول د قاعدې وروسته پیل شوې کړکۍ کې لوړېدل روان وي، تاسو څه لرئ چې څیړنه یې وکړئ؛ که لوړېدل ودروي، مخکینی زیاتوالی ښودل شوی تاریخ و.

VPN خدمت کېدای شي هغه نه وي چې تاسو تنظیم کړی

د VPN firewall یوازې هغه ترافیک ویني چې خپله خدمت یې وړي. که بل 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 طبقې شعار دا نه حل کوي: صادق ځواب دا دی چې شمېرونکی او بلاک دواړه سم کېدای شي په داسې حال کې چې بېلابېل شیان بیانوي. د Android NetworkStatsManager حواله مستندوي چې دا بالټۍ څنګه پوښتل او منسوبېږي.