Android VPN انتساب: getConnectionOwnerUid بمقابلہ /proc/net
Android 10 ایپس سے /proc/net چھپا دیتا ہے۔ VPN اب بھی پیکٹ وصول کرتا ہے، مگر انتساب اپنے tuple اور اجازت کے قواعد کے ساتھ getConnectionOwnerUid کی طرف چلا جاتا ہے۔
Android 10 اور اس کے بعد، /proc/net/tcp کھولنے والی ایپ کو socket جدول کی بجائے رسائی سے انکار ملتا ہے۔ VPN انٹرفیس کو اس سے غرض نہیں: پیکٹ اب بھی آتے ہیں، کیونکہ ٹنل روٹنگ کا فیصلہ ہے، فائل کی اجازت نہیں۔ جو بدلا وہ ایک تنگ سوال کا جواب ہے: «کون سی ایپ اس کنکشن کی مالک ہے؟» متبادل ConnectivityManager.getConnectionOwnerUid ہے، ہر کنکشن کے لیے معاون استفسار، اور پرانی عادت اور نئی API کے درمیان انتخاب اس پر منحصر ہے کہ آپ کے پاس درحقیقت تین کاموں میں سے کون سا ہے: پیکٹ وصول کرنا، بہاؤ کی انتساب، یا استعمال کا مجموعہ۔
مالک کے سوال کے دو جواب
API 29 سے پہلے، ایک مراعات یافتہ یا root عمل کرنل کے socket جدولوں کو پڑھ سکتا تھا، چوکڑی کو مل سکتا تھا اور مالک UID جان سکتا تھا۔ اس سے ایک ہی فائل میں پورے آلے کی فہرست ملتی تھی۔ API 29 سے فائل سسٹم کا منظر محدود ہے، اور معاون راستہ پروٹوکول، مقامی پتہ اور دور دراز پتے کے ساتھ ہر کنکشن کا استفسار ہے۔
| Question | Legacy socket tables | getConnectionOwnerUid |
|---|---|---|
| Who owns this flow? | Scan and match the tuple | Ask once per tuple |
| Device-wide inventory? | Yes, when readable | No, one flow at a time |
| Historical usage? | No | No; that is NetworkStatsManager |
| Works without root? | No on modern releases | Yes, for authorized callers |
موازنہ «پرانا بمقابلہ نیا» نہیں ہے۔ یہ تین مختلف کام ہیں جو پہلے ایک پڑھی جانے والی فائل پورا کرتی تھی اور اب تین مختلف معاہدوں کے ساتھ تین مختلف انٹرفیس پورا کرتے ہیں۔
مقامی پتہ ہی ایپ کا سرا ہے
طریقہ کار کا دستخط پروٹوکول، مقامی socket پتہ اور دور دراز socket پتہ لیتا ہے۔ «مقامی» سے مراد کنکشن میں ایپ کا رخ ہے، نہ کہ وہ سرا جو جانچ کے لمحے پیکٹ کا ماخذ ہو۔ دور دراز سرور سے ایپ کی طرف واپس آنے والے پیکٹ کا ماخذ اور منزل اس تعریف کے لحاظ سے الٹے ہوتے ہیں۔
ConnectivityManager cm = getSystemService(ConnectivityManager.class);
int uid = cm.getConnectionOwnerUid(
OsConstants.IPPROTO_TCP, appLocalAddress, appRemoteAddress);یہ سمت کی غلطی ہی عام ترین وجہ ہے کہ کام کرنے والا استفسار غلط جواب دیتا ہے، یا کوئی نہیں۔ کال سے پہلے دونوں سروں کو لاگ کریں اور جوڑی کو اس کنکشن سے ملا کر تصدیق کریں جو ایپ نے واقعی کھولا تھا۔ پتے کا خاندان بھی اہم ہے: IPv4 سے میپ کیا گیا پتہ اور اصل IPv6 پتہ مختلف tuple ہیں، اور اسی طرح ایک ہی پورٹ پر TCP اور UDP بہاؤ بھی۔
اجازت اور نامعلوم نتائج معاہدے کا حصہ ہیں
استفسار مجاز کالرز تک محدود ہے، جس میں متعلقہ صارف کی فعال VPN ایپ بھی شامل ہے۔ غیر متعلقہ نگرانی ایپ یہ فرض نہیں کر سکتی کہ وہ کسی دوسرے پروفائل کے کنکشن گن سکتی ہے، اور غیر مجاز کال دوستانہ خرابی کی بجائے سیکیورٹی استثنا پھینک سکتی ہے۔ دونوں نتائج کو واضح طور پر سنبھالیں۔
غائب مالک پیکیج کا نام نہیں ہے۔ بہاؤ پیکٹ اور استفسار کے درمیان بند ہو سکتا ہے، tuple نامکمل ہو سکتا ہے، یا کالر کو جاننے کی اجازت ہی نہ ہو۔ پہلا کامیاب جواب کیش کر کے بعد میں دوبارہ استعمال کرنا نئے کنکشن کو پرانی ایپ سے منسوب کرتا ہے، جو نامعلوم بتانے سے بدتر ہے۔
جب انتساب ناکام ہو، ٹریفک کو پھر بھی فیصلہ درکار ہوتا ہے: جہاں پالیسی کہے وہاں اسے بلاک کریں، صرف وہی دائرہ اجازت دیں جو آپ سمجھتے ہیں، یا خلا دکھائیں۔ وہ متبادل ڈیزائن کا حصہ ہے، تبصرے کا نہیں۔
حساب ایک الگ سوال ہے
NetworkStatsManager اپنے رسائی قواعد کے تحت استعمال کی رپورٹ دیتا ہے۔ یہ بتا سکتا ہے کہ کسی UID نے کسی مدت میں کتنا منتقل کیا؛ یہ کسی بھی زندہ پیکٹ کا مالک نہیں بتا سکتا۔ نیٹ ورک کی صلاحیتیں نیٹ ورک کی خصوصیات بیان کرتی ہیں، socket کی فہرست نہیں۔ تینوں کو ملانے سے ایسے ڈیش بورڈ بنتے ہیں جو مستقل دکھتے ہیں اور ہوتے نہیں۔
یہ طے کرنے کی سادہ صورت کے لیے کہ کون سی ایپس ٹنل استعمال کرتی ہیں، Android کی معاون اجازت یافتہ اور ممنوع ایپ فہرستیں بغیر کسی scraping کے پالیسی بیان کرتی ہیں۔ ہر بہاؤ کی انتساب ان صورتوں کے لیے رکھیں جنہیں واقعی اس کی ضرورت ہے، اور ایسے برقرار رکھے گئے نفاذ کے لیے بجٹ رکھیں جو سمت، اجازات اور نامعلوم حالتوں کو اکٹھا سنبھالے۔
کام کے مطابق اوزار چنیں، پھر کنارے جانچیں
اگر ضرورت ٹنل کا انتخاب ہے تو پلیٹ فارم فہرست استعمال کریں۔ اگر براہ راست انتساب ہے تو مالک کا استفسار استعمال کریں اور ہر بےجواب tuple کو نامعلوم سمجھیں۔ اگر تاریخی مجموعے ہیں تو stats API استعمال کریں۔ پھر وہ تین کنارے جانچیں جو سادہ نفاذ کو توڑتے ہیں: مخالف سمت کا پیکٹ، استفسار سے پہلے بند ہونے والا بہاؤ، اور ایسا کالر جو فعال VPN نہیں۔
ان میں سے کچھ بھی SELinux بند کرنے، فون کو root کرنے یا کرنل جدولوں کو عالمی طور پر پڑھنے کے قابل بنانے کا تقاضا نہیں کرتا۔ پابندی ہی اصل بات ہے: پلیٹ فارم نے انتساب کو ایک معاہدے کے پیچھے منتقل کیا تاکہ جواب صرف اسی جزو کو ملے جسے قانونی طور پر اس کی ضرورت ہے، کسی اور کو نہیں۔