کون سا macOS اوزار کسی ایک ایپ کو صرف VPN کے ذریعے جانے پر مجبور کر سکتا ہے؟
صرف-VPN حد کے لیے راستہ اور انکار دونوں درکار ہیں۔ فی-ایپ پروفائلز، پراکسی، فلٹرز اور PF کا موازنہ کریں، پھر وہی ایک ایپ آزمائیں جو آپ کے لیے اہم ہے۔
ضروریات کی دستاویز میں ایک سطر — «یہ ایپ VPN استعمال کر سکتی ہے، اور اس کے سوا کچھ نہیں» — خاموشی سے دو ایسے طریقے مانگتی ہے جو کوئی ایک سوئچ فراہم نہیں کرتا۔ ٹریفک کو مطلوبہ سرنگ سے گزرنے کا راستہ درکار ہے، اور جو ٹریفک سیدھا باہر جائے گا اسے مسترد کیا جانا چاہیے۔ ایسے اوزار عام ہیں جو ایک کام اچھی طرح کرتے ہیں اور دوسرا بالکل نہیں، اسی لیے صرف یہ پوچھنے والا موازنہ کہ کوئی چیز بلاک کر سکتی ہے یا نہیں، سوال کے نصف کا اعتماد سے جواب دیتا ہے۔ پہلے حد لکھیں، پھر وہ اجزا چنیں جو اس کے دونوں نصف حصوں کو ڈھانپتے ہیں۔
ایک ہی جملے میں چھپی دو ضرورتیں
رہنمائی وہ حصہ ہے جو کسی کنکشن کو سرنگ یا پراکسی میں رکھتا ہے۔ انکار وہ حصہ ہے جو اسی کنکشن کو کسی بھی دوسرے راستے سے باہر جانے سے روکتا ہے۔ مختلف اجزا انہیں نافذ کرتے ہیں، وہ مختلف طریقوں سے ناکام ہوتے ہیں، اور کوئی پروڈکٹ ایک میں بہترین ہو سکتی ہے اور دوسرے کے بارے میں کچھ نہ کہے:
| Approach | Steers traffic | Refuses direct egress | Knows the app identity |
|---|---|---|---|
| Per-app VPN profile | Yes, for the apps it names | Only if a filter or firewall also blocks | Yes, within its own rules |
| Application proxy setting | Partly, for requests that honour it | No | No |
| Content filter | No | Yes | Yes, if the filter is written that way |
| Local PF ruleset | No | Yes, by address and port | Not reliably |
جدول کو درجہ بندی نہیں، چیک لسٹ کی طرح پڑھیں۔ کوئی قطار دونوں درمیانی کالم نہیں بھرتی، اور جو قطاریں انہیں ڈھانپتی ہیں وہ دو تعاون کرنے والے اجزا ہیں: ایک راستے کا مالک، دوسرا انکار کا۔ شناخت کا کالم کسی اور وجہ سے اہم ہے، کیونکہ جو قاعدہ ایپ کا نام نہیں لے سکتا وہ اس ایپ کے بارے میں قاعدہ نافذ نہیں کر سکتا۔ آپ جو بھی تعینات کریں، اسے تینوں کا جواب دینا ہوگا، ورنہ ضروریات کی دستاویز کی حد مشین پر موجود حد نہیں ہے۔
صرف رہنمائی باہر نکلنے کا راستہ چھوڑ دیتی ہے
ایپلی کیشن پراکسی کی ترتیب انکار کے بغیر رہنمائی کی سب سے واضح مثال ہے۔ یہ ایسی ایپ کی درخواستوں کی رہنمائی کر سکتی ہے جو سسٹم پراکسی کا احترام کرتی ہے، اور اس کے سوا کچھ نہیں ڈھانپتی: کوئی معاون عمل، اپ ڈیٹر، پس منظر سروس یا مختلف پروٹوکول اس ترتیب کو کبھی پڑھے بغیر اپنا راستہ لے سکتے ہیں۔ اس لیے ایک پینل میں SOCKS اختتامی نقطہ چننا ایپلی کیشن کے لیے براہ راست اخراج کی ممانعت کی پالیسی نہیں بناتا۔ اگر ضرورت پوری ایپ کے بارے میں ہو، تو پوچھیں کہ قاعدہ حقیقت میں کون سے اجزا کی شناخت کرتا ہے۔
فی-ایپ VPN پروفائل پراکسی سے بہتر رہنمائی کرتا ہے، کیونکہ کون سی ایپس سرنگ میں داخل ہوں گی یہ پلیٹ فارم طے کرتا ہے بجائے اس کے کہ ہر ایپ خود فیصلہ کرے۔ پھر بھی یہ کسی چیز سے انکار نہیں کرتا: پروفائل راستہ دیتا ہے، اور جو ٹریفک اس سے نہیں ملتا وہ معمول کا راستہ لیتا ہے۔ یہی خلا وہ جگہ ہے جہاں دوسرا جزو اپنی جگہ کماتا ہے، اور اسی لیے ایک سوئچ جیسے نظر آنے والی مصنوعات عام طور پر دو ہوتی ہیں۔
صرف انکار ایپ کو توڑ دیتا ہے
Apple کی دستاویزات مواد کے فلٹرز کے بارے میں نیٹ ورک اسٹیک سے گزرتے ہوئے ٹریفک پر اجازت-یا-بلاک کے فیصلے کی وضاحت کرتی ہیں۔ یہ فیصلہ نہ سرنگ ہے نہ پراکسی کنکشن، کیونکہ یہ طے کرتا ہے کہ کوئی چیز آگے بڑھ سکتی ہے یا نہیں، یہ نہیں کہ کہاں جاتی ہے۔ صرف فلٹر انکار کو مکمل طور پر نافذ کرتا ہے اور ایپلی کیشن کو ناقابل استعمال چھوڑ دیتا ہے، صاف لاگز کے ساتھ اور بغیر کسی وضاحت کے۔ فلٹر کا فیصلہ کنکشن روک سکتا ہے مگر کبھی سرنگ فراہم نہیں کرتا، اس لیے اسے رہنمائی کے ساتھ جوڑنا ڈیزائن کا فیصلہ ہے، اختیاری اضافہ نہیں۔
مقامی طور پر زیرِ انتظام PF قواعد کا مجموعہ اس اسپیکٹرم کے دوسرے سرے پر کھڑا ہے۔ یہ ایسی مشین پر جائز معاونت کا فیصلہ ہے جس کا مالک منتظم ہے، اور یہ خود بخود قابلِ تقسیم پروڈکٹ کی بنیاد نہیں ہے، کیونکہ جس کے پاس قواعد کا مجموعہ ہے اس کے پاس دوسرے فائر وال صارفین کے ساتھ اس کے تعاملات، اس کا اپ گریڈ راستہ اور قاعدہ غلط ہونے پر اس کی بحالی بھی ہے۔ پروڈکٹ میں PF شامل کرنا اس ملکیت کے سوال کو نہیں ہٹاتا؛ یہ اس کی تعریف کرتا ہے۔
تعیناتی طے کرتی ہے کہ قاعدہ کل بھی موجود رہے گا یا نہیں
Network Extension کو Apple پلیٹ فارمز پر کیسے تعینات کیا جاتا ہے یہ آپ کے سامنے موجود فراہم کنندہ کی قسم، پیکیجنگ اور OS ورژن پر منحصر ہے۔ macOS پر ایپ ایکسٹینشن صارف کے سیاق میں چلتا ہے اور جب وہ صارف لاگ آؤٹ ہوتا ہے تو ختم ہو جاتا ہے، جبکہ سسٹم ایکسٹینشن کا سیاق عالمی ہوتا ہے جو سیشن پر منحصر نہیں۔ اگر تحفظ کو لاگ آؤٹ کے بعد بھی قائم رہنا ہے، تو یہی فرق پورا ڈیزائن ہے، حاشیہ نہیں۔ رویے کا وعدہ کرنے سے پہلے تعیناتی کا راستہ تصدیق کریں، کیونکہ وہی کوڈ کس ایکسٹینشن قسم کے بھیجنے پر مختلف انداز میں اترتا ہے۔
ماخذ کی دستیابی نفاذ سے الگ معاملہ ہے۔ کسی ذخیرے کو پڑھنا بتاتا ہے کہ کوئی چیز کیسے نافذ کی گئی ہے، یہ نہیں کہ اس مشین پر نصب بائنری کیا کر سکتی ہے۔ دستخط، تنصیب اور اجازت اب بھی لاگو ہیں، اور پرانے کرنل ایکسٹینشن یا لائبریری انجیکشن کی چال کے گرد بنی ہدایات کسی اور پلیٹ فارم اور کسی اور خطرے کے رویے کی وضاحت کرتی ہیں، چاہے وہ کبھی کتنی ہی اچھی طرح چلی ہوں۔
ایپ کا نام لینے والا قبولیتی معاملہ
ایک ایسا عمل چنیں جو ایپ خود کرتی ہے، جس پتے تک اسے پہنچنا چاہیے اور یہ کہ وہ پتہ IPv4 ہے یا IPv6، نوٹ کریں، پھر منظور شدہ بغیر سرنگ حالت میں وہی عمل دہرائیں۔ دوسری بار چلانے پر اعلان کردہ انکار آنا چاہیے، خاموش سیدھی دوبارہ کوشش نہیں۔ یہی وہ نصف ہے جسے لوگ غیر واضح چھوڑ دیتے ہیں، اور انکار کے وجود کو ثابت کرنے والا واحد نصف۔ اسے پہلے سرنگ دستیاب ہونے پر چلائیں، تاکہ دونوں نتائج کا فرق صرف غیر موجود سرنگ سے آ سکے۔
پھر ان تبدیلیوں سے گزریں جن کا ذکر ضرورت کرتی ہے: ایپ کا دوبارہ آغاز، معاون عمل کا متحرک ہونا، سرنگ کا دوبارہ جڑنا، مشین کا نیٹ ورک بدلنا، اور جہاں لاگو ہو وہاں لاگ آؤٹ یا ری بوٹ۔ براؤزر کا عوامی-IP صفحہ کسی دوسری ایپلی کیشن کے ساکٹ کا امتحان نہیں، اس لیے یہ اس کا متبادل نہیں بن سکتا۔ جہاں کوئی معاون تعیناتی ایپ کے حقیقی رویے کو نہیں ڈھانپتی، وہاں واضح گیٹ وے اور متبادل اخراج کے بغیر ایک مجاز الگ تھلگ ماحول اپنی انتظامی لاگت والا تحفظ کا فیصلہ ہے، چیک باکس کا متبادل نہیں۔
چار اندراجات لکھ کر مکمل کریں: ایپ کن اجزا سے بنی ہے، رہنمائی کا مالک کون ہے، انکار کا مالک کون ہے، اور وہ حالتیں جن میں قاعدہ اب بھی لاگو رہنا چاہیے۔ کوئی عوامی ذخیرہ انتخاب کا ایک معیار ہو سکتا ہے، مگر وہ ان چار میں سے ایک نہیں، اور وہی اندراجات طے کرتے ہیں کہ دیا گیا اوزار نیٹ ورکنگ کی ضرورت پوری کرتا ہے یا نہیں۔