VPN آن ہونے پر Android فائر وال کا قاعدہ کہاں رہنا چاہیے
صرف ایک VpnService فعال ہو سکتا ہے، اس لیے فائر وال ایپ اور VPN ایپ اوپر تلے نہیں چڑھتیں۔ ایک کام کی درخواست پر چلیں اور ہر قاعدہ وہاں رکھیں جہاں ٹریفک واقعی گزرتی ہے۔
آپ کے پاس پالیسی کا ایک جملہ ہے: یہ ایپ کام کی سروس تک پہنچ سکتی ہے، اور کسی اور چیز تک نہیں۔ اگلا سوال مصنوعات کے انتخاب جیسا لگتا ہے، لیکن یہ جگہ کا سوال ہے، کیونکہ ہر ممکن نفاذی نقطہ فون کی ٹریفک کا مختلف حصہ دیکھتا ہے۔ گیٹ وے صرف وہ دیکھتا ہے جو سرنگ میں داخل ہوتا ہے۔ فون کی طرف کا فلٹر صرف وہ دیکھتا ہے جسے دیکھنے کی اجازت ہے۔ ایک درخواست کو دونوں سے گزارنا جواب واضح کر دیتا ہے۔
مصنوعات سے نہیں، جملے سے شروع کریں
کچھ بھی منتخب کرنے سے پہلے تقاضا پھیلائیں۔ اس کا مطلب پیکیج اور وہ پروفائل ہے جس میں یہ چلتا ہے، کیونکہ کام کے پروفائل کی ایپ ذاتی پروفائل کی اسی ایپ سے مختلف صارف ہے۔ اس کا مطلب منزل ہے: host، port اور protocol، نہ کہ سروس کا نام۔ اس کا مطلب وہ DNS راستہ ہے جو یہ نام حل کرتا ہے، اور یہ کہ سرنگ دستیاب نہ ہونے پر کیا ہونا چاہیے۔
لکھے جانے پر، مثال کی پالیسی چار سطریں ہیں: کام کی ایپ کام کی سروس تک پہنچ سکتی ہے؛ کام کی ایپ کسی اور چیز تک نہیں پہنچ سکتی؛ دوسری ایپس میں تبدیلی نہیں؛ سرنگ نہ ہونے پر کام کی ایپ کو براہ راست راستے پر جانے کے بجائے انکار کر دیا جاتا ہے۔ ہر سطر کا ایک مالک ہے، اور سب ایک ہی مالک نہیں ہیں۔
مرحلہ 1: فون خود کیا نافذ کر سکتا ہے
بغیر root کا Android فائر وال ایک VpnService ہے جو ٹریفک کو مقامی طور پر پکڑتا ہے، چاہے اس کے پیچھے دور کی کوئی سرنگ نہ ہو۔ Android فی صارف پروفائل صرف ایک فعال VPN سروس کی اجازت دیتا ہے، اس لیے دوسری فائر وال ایپ پہلی کے پیچھے زنجیر نہیں بنتی۔ یہ اس کی جگہ لیتی ہے، اور وہ انٹرفیس ختم ہو جاتا ہے جسے پہلی ایپ فلٹر کر رہی تھی۔
اسی لیے VPN کلائنٹ کے ساتھ فائر وال نصب کرنا وہ مجموعہ کم ہی دیتا ہے جس کی لوگ توقع کرتے ہیں۔ اگر فائر وال شروع ہو اور VPN قطع ہو جائے تو کچھ بھی نہیں جڑا؛ دونوں نے جگہیں بدل لیں۔ انٹرفیس کی تبدیلی تعاون نہیں ہے، اور علامت وہ سرنگ ہے جو دوسری ایپ کھولنے پر بار بار گرتی ہے۔
معاونت شدہ ترتیبیں پھر بھی موجود ہیں: اسی VPN کلائنٹ میں شامل فلٹرنگ جو آپ پہلے سے چلا رہے ہیں، ڈیوائس پالیسی کنٹرولر یا کام کے پروفائل کے ذریعے منظم پلیٹ فارم کنٹرول، یا کوئی ایسی ساخت جسے وینڈر دستاویز کرتا ہے۔ باقی سب ایک تجربہ ہے جسے ہر ایپ اپ ڈیٹ کے بعد دوبارہ جانچنا پڑتا ہے۔
مرحلہ 2: گیٹ وے کیا نافذ کر سکتا ہے
دور کے سرے پر ٹریفک ڈکرپٹ ہونے کے بعد، گیٹ وے آگے بھیجے گئے پیکٹوں کو منظور شدہ پتوں، سروسز یا تصدیق شدہ VPN شناختوں تک محدود کر سکتا ہے۔ یہ اس سے گزرنے والی ہر چیز کے لیے حقیقی نفاذ ہے، اور نجی ذیلی نیٹ ورکس تک رسائی محدود کرنے کی صحیح جگہ ہے۔
جو اسے نہیں ملتا وہ فون کی ایپ کی شناخت ہے جو ہر عام IP پیکٹ کے ساتھ منسلک ہوتی ہے۔ ایک سرنگ کا پتہ بانٹنے والی کئی ایپس گیٹ وے کے لیے ایک واحد موضوع ہیں، الا یہ کہ ساخت انہیں الگ پتے یا الگ تصدیق شدہ شناختیں دے۔ اس لیے گیٹ وے پر فی صارف قاعدہ فون پر فی ایپ قاعدہ نہیں ہے، چاہے انتظامی کنسول اسے کچھ بھی کہے۔
مرحلہ 3: وہ فہرست بنائیں جو کبھی نہیں پہنچتا
VPN سے خارج شدہ ایپ جو قریبی ڈیوائس سے رابطہ کرتی ہے کبھی گیٹ وے تک نہیں پہنچتی، اس لیے خارجی فائر وال اس پیکٹ کو مسترد نہیں کر سکتا جو اسے کبھی ملتا ہی نہیں۔ یہی بات خرابی کے دوران غیر ارادی براہ راست راستے اور مقامی رسائی نیٹ ورک پر اندرونی افشا پر بھی لاگو ہوتی ہے۔ یہ تعریف کے مطابق مقامی حدود ہیں۔
اس کا الٹ بھی درست ہے: وہ مقامی قاعدہ جو رابطے کی اجازت دیتا ہے گیٹ وے کے نجی نیٹ ورک ACL کے ذریعے رسائی نہیں دیتا۔ ایک درخواست دونوں حدود کے تابع ہو سکتی ہے، اور ایک کو پورا کرنا دوسرے کے بارے میں کچھ نہیں کہتا۔
مرحلہ 4: ہر قاعدے کو راستہ تفویض کریں
کچھ بھی کنفیگر کرنے سے پہلے فیصلہ ایک جدول میں رکھیں، کیونکہ خالی خانے وہ جگہ ہیں جہاں ڈیزائن ناکام ہوتے ہیں۔
| Path | Who can enforce it | Blind spot |
|---|---|---|
| Work app to the work service, tunnel up | Gateway ACL on address and service, plus a local block on other paths | The gateway cannot see which app sent the packet |
| Work app to other destinations, tunnel up | Local app-aware filter, or the gateway if those destinations are addressed there | The local filter must be the active VpnService |
| Work app with no tunnel | Local deny, so the app cannot take a direct path | Requires the filter to survive the tunnel going away |
| Nearby LAN device | Local policy only | The gateway never sees it |
قابل عمل شکل دو حدود ہیں دو کاموں کے ساتھ۔ ایپ سے واقف مقامی حد فون کے رویے کو کنٹرول کرتی ہے، بشمول براہ راست fallback، اور گیٹ وے کی حد دور کے وسائل کو کنٹرول کرتی ہے۔ گیٹ وے کی طرف کام کی سروس کی اجازت دے سکتی ہے اور ہر دوسرے نجی ذیلی نیٹ ورک کو مسترد کر سکتی ہے، جبکہ فون کی طرف کی پالیسی خود اس براہ راست راستے کا فیصلہ کرتی ہے جو ایپ ورنہ اختیار کر سکتی تھی۔
مرحلہ 5: ٹرانسپورٹ کو زندہ رکھیں، پھر تصدیق کریں
آپ جو بھی مقامی پالیسی منتخب کریں، اسے وہ ٹرانسپورٹ اجازت دینا چاہیے جو VPN قائم اور برقرار رکھتا ہے۔ اس ٹرانسپورٹ کو بلاک کرنا فون کو بغیر سرنگ اور بغیر پالیسی چھوڑ دیتا ہے، جو کچھ بھی مستقل طور پر نافذ نہیں کرتا اور اس کی تشخیص مشکل ہے کیونکہ ایپ کے پاس نیٹ ورک ہی نہیں ہوتا۔
پھر مجموعی تاثر کے بجائے اصل جملے کی ہر سطر کی تصدیق کریں: کام کی ایپ کام کی سروس تک پہنچتی ہے، وہی ایپ دوسری منزل پر مسترد ہوتی ہے، غیر کام کی ایپ پہلے کی طرح برتاؤ کرتی ہے، اور سرنگ بند ہونے پر کام کی ایپ براہ راست رابطے پر نہیں جاتی۔ DNS راستہ الگ سے جانچیں، کیونکہ نجی DNS یا خفیہ کردہ resolver ایسے فلٹر کو بائی پاس کر سکتے ہیں جو صرف پتے دیکھتا ہے۔
اگر ان میں سے کوئی مرحلہ فون پر پورا نہ ہو سکے تو تقاضا ساخت کا سوال ہے، فائر وال کی ترتیب نہیں۔ پالیسی کو اس ڈیوائس کے درمیان تقسیم کرنا جسے آپ کنٹرول کرتے ہیں اور اس گیٹ وے کے درمیان جسے آپ کنٹرول کرتے ہیں عام طور پر دیانت دار جواب ہے، اور Android VPN رابطے کی دستاویز وہ جگہ ہے جہاں آپ تصدیق کرتے ہیں کہ پلیٹ فارم ایک سروس کو کیا اجازت دے گا اور کیا نہیں۔