ہاٹ اسپاٹ کلائنٹس کے لیے اسپلٹ ٹنلنگ فی ایپ اخراج نہیں ہے
کسی ایپ کو VPN سے باہر رکھنا صرف فون بدلتا ہے۔ منسلک لیپ ٹاپ کو اپنا فارورڈنگ قاعدہ چاہیے، جو ماخذ، منزل اور NAT پر میلا جاتا ہے۔
ایک جیسے سنائی دینے والے دو تقاضے ایک جیسے نہیں: «اس ایپ کو VPN سے باہر رکھو» اور «اس ایک منزل کو میرے ہاٹ اسپاٹ والے لیپ ٹاپ کے لیے VPN سے باہر بھیجو»۔ پہلا بدلتا ہے کہ فون پر سوکٹ نیٹ ورک کیسے چنتا ہے۔ دوسرے کو اُس پیکٹ کے لیے فارورڈنگ فیصلہ بدلنا ہوتا ہے جو فون کے پہلے ہی قبول کر لینے کے بعد کسی دوسرے آلے سے آیا ہو۔ دونوں کو ملانا ہی وہ سبب ہے جس سے ہاٹ اسپاٹ کلائنٹ کے پاس ایسی استثنا رہ جاتی ہے جو ہمیشہ صرف فون کے اپنے براؤزر پر لاگو ہوتی تھی۔
دو سوالوں کے مالک دو الگ ذیلی نظام ہیں
Android ایپ نیٹ ورکنگ اور ٹیتھرنگ کو الگ رکھتا ہے۔ ایپس کے سوکٹ کو کنیکٹیویٹی اسٹیک نیٹ ورک تفویض کرتا ہے، اور VPN ایپ فیصلہ کرتی ہے کہ اس کے اپنے کون سے سوکٹ سرنگ میں داخل ہوں گے۔ منسلک کلائنٹ سے فارورڈ کیے گئے پیکٹ ٹیتھرنگ ذیلی نظام سنبھالتا ہے، جو netd سے راستے، پالیسی قواعد اور نیچے کے انٹرفیس پر ترجمہ مانگتا ہے۔
فی ایپ اخراج کا جائزہ اس وقت ہوتا ہے جب کوئی ایپ سوکٹ کھولتی ہے۔ فارورڈ کیا گیا پیکٹ اُس جانچ تک کبھی نہیں پہنچتا، کیونکہ وہ اس آلے کے ایپ سوکٹ سے پیدا نہیں ہوا۔ دو ترتیبات کے ایک دوسرے کی جگہ نہ لے سکنے کی پوری وجہ یہی ہے، اور یہ دونوں میں سے کسی میں بھی خرابی نہیں ہے۔
فی ایپ اخراج حقیقت میں کیا بدلتا ہے
VpnService کا بنانے والا addDisallowedApplication کے ساتھ سرنگ سے باہر رہنے والے پیکجز کے نام دے سکتا ہے، یا addAllowedApplication کے ساتھ اندر اجازت یافتہ واحد پیکجز کے نام دے سکتا ہے۔ وہ ایپس پھر بنیادی نیٹ ورک پر سوکٹ کھولتی ہیں، جبکہ VPN باقی سب کے لیے ڈیفالٹ راستے کا مالک رہتا ہے۔
دائرہ بالکل درست ہے: پیکیج کے اپنے سوکٹ، اسی آلے پر، جب تک سرنگ قائم ہے۔ یہ فارورڈ کی گئی ٹریفک کے بارے میں کچھ نہیں کہتا، دوسرے آلے کے بارے میں کچھ نہیں، اور نظام کی طرف سے ٹیتھرنگ کے نام پر بھیجے گئے پیکٹوں کے بارے میں بھی کچھ نہیں۔
یہ منزل کا کنٹرول بھی نہیں ہے۔ براؤزر کو باہر رکھنے سے ہر وہ پتہ باہر ہو جاتا ہے جہاں وہ براؤزر پہنچتا ہے، بشمول وہ جسے آپ سرنگ کے اندر رکھنا چاہتے تھے۔ جب تقاضہ ایپ کے بجائے منزل کا نام لیتا ہے، تو ایپ منتخب کرنے والا بطورِ ساخت ہی غلط اوزار ہے۔
فون کے لیے ٹیتھر شدہ پیکٹ کیسا دکھائی دیتا ہے
کلائنٹ کا پیکٹ ہاٹ اسپاٹ انٹرفیس پر فون کے دیے گئے نجی ماخذ پتے کے ساتھ، کہیے 192.168.43.20، اور عوامی منزل کے ساتھ آتا ہے۔ اسے فارورڈ کرنے کے لیے فون کو اوپر کے لنک کی طرف راستہ اور ترجمے کا قاعدہ چاہیے، تاکہ جواب واپسی کا راستہ پا سکیں، کیونکہ کلائنٹ کا نجی پتہ سیلولر نیٹ ورک پر بے معنی ہے۔
Android اسے ایسے پالیسی قواعد سے ظاہر کرتا ہے جو روٹنگ جدول منتخب کرتے ہیں، اور جب نیٹ ورک اور VPN بدلتے ہیں تو netd متعلقہ جدول اور قواعد دوبارہ بناتا ہے۔ کسی فورم پوسٹ سے یا اسی ماڈل کے پرانے ریلیز سے نقل کیا گیا جدول نمبر، قاعدے کی ترجیح یا انٹرفیس کا نام پائیدار ملکیت قائم نہیں کرتا۔ یہی دوبارہ تشکیل وہ سبب بھی ہے کہ ہاتھ سے لکھا قاعدہ ایک گھنٹہ کام کر کے اگلی دوبارہ رابطے کے بعد رک سکتا ہے۔
ہاٹ اسپاٹ استثنا کو حقیقت میں کون سی پالیسی درکار ہے
کسی قاعدے کو چھونے سے پہلے فیصلہ ماخذ، منزل اور مطلوبہ راستے کے طور پر لکھیں۔ ایک منظور شدہ منزل کے لیے کم سے کم شکل ایسی دکھتی ہے:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
دونوں سمتوں کا مکمل ہونا ضروری ہے۔ سیدھی شاخ کو موجودہ سیلولر اوپر کے لنک سے قابلِ استعمال راستہ چاہیے؛ VPN شاخ کو سرنگ کا راستہ اور فارورڈ کرنے کی اجازت چاہیے۔ کوئی بھی ماخذ ترجمہ آپ کے منتخب کردہ اخراج سے میل کھانا چاہیے، کیونکہ سرنگ کے انٹرفیس پر لاگو NAT سرنگ کا پتہ دکھاتا ہے، سیلولر کا نہیں، اور تب واپسی کا راستہ جانے کے راستے سے مطابقت نہیں رکھتا۔
جوابات کو ٹریک شدہ حالت یا واضح راستے کے ذریعے اسی نیچے کے کلائنٹ تک پہنچنا چاہیے، اور باہر جانے والے پیکٹوں کا شمار کنندہ ان میں سے کچھ بھی ثابت نہیں کرتا۔ VPN کی اپنی بیرونی ترسیل کو بھی استثنا کے دائرے سے باہر رکھیں، ورنہ سرنگ کے حامل پیکٹ کسی کلائنٹ کی ویب درخواست کے لیے لکھی گئی پالیسی ورثے میں پا لیں گے۔
پکڑا گیا ایک پتہ منزل نہیں ہے
براؤزر سے پڑھا گیا ایک ہی IPv4 پتہ ایک لمحے کی تصویر ہے۔ بڑی خدمات anycast یا گھومتے کنارے کے پتوں کے مجموعے سے جواب دیتی ہیں، کئی دوہرے اسٹیک ہیں، اور لاگ اِن کا بہاؤ ایسے توثیق اور ٹیلی میٹری میزبانوں کو چھو سکتا ہے جو صفحہ کبھی نہیں دکھاتا۔ جو پتہ آپ نے اتفاقاً دیکھا اُس کے گرد بنائی گئی استثنا اگلی بار ٹوٹ جاتی ہے جب خدمت بوجھ دوبارہ متوازن کرتی ہے۔
خدمت کے مالک کے دستاویزی پتے، یا وہ جو رینج شائع کرتا ہے، استعمال کریں اور پتوں کے دونوں خاندانوں کو شمار میں رکھیں۔ اگر تقاضے کو مستحکم مجموعے کے طور پر بیان نہ کیا جا سکے، تو یہ غالباً خدمت کے لیے پالیسی کا سوال ہے، فون پر روٹنگ کی ترکیب نہیں۔
نیچے کی طرف سے تصدیق کریں
تین جانچیں، اسی ترتیب سے: لیپ ٹاپ سے منتخب خدمت، ایک عام منزل جو VPN کے اندر رہنی چاہیے، اور ایک فون ایپ جو متاثر نہیں ہونی چاہیے۔ پھر دوبارہ رابطے کے بعد اور اوپر کا لنک بدلنے کے بعد دہرائیں، کیونکہ تبھی پالیسی جدول دوبارہ بنتے ہیں۔
اگر فون کی اشتراک کی عمل آوری دوبارہ رابطے کے دوران وہ معاہدہ نہ رکھ سکے، تو ہینڈ سیٹ پر root قواعد جمع کرنے کی بجائے منتخب پالیسی کو معاون نیچے کے راؤٹر پر منتقل کریں۔ راؤٹر مستحکم مالک کے ساتھ ماخذ اور منزل کی مطابقت بیان کر سکتا ہے، اور ٹیتھرنگ ماڈیول کی دستاویزات اس بات کا درست حوالہ ہیں کہ فون حقیقت میں کیا کرتا ہے۔