ایک ساتھ دو iPhone VPN: آپ کا ٹریفک کون لے کر جاتا ہے؟
iPhone پر جڑے دو VPN زنجیر نہیں ہیں۔ دستاویزی ہم آہنگی ماڈل پڑھیں، پھر جانچیں کہ کون سی ترتیب ہر بہاؤ کو لے کر جاتی ہے۔
دونوں VPN ایپس Connected دکھاتی ہیں، اور یہ فرض کیا جاتا ہے کہ ٹریفک اب دونوں سے گزرتی ہے، ایک دوسرے کے اندر۔ عام طور پر ایسا نہیں ہوتا۔ iOS کا ایک مخصوص ہم آہنگی ماڈل ہے، اور یہ زنجیر نہیں ہے۔ ترتیب کی ایک کلاس صرف ایک فعال نمونے تک محدود ہے، دوسری اس کے ساتھ چل سکتی ہے، اور راستے کی ترجیح تنازعات طے کرتی ہے۔ دو جلے ہوئے سوئچ دو چھلانگیں نہیں ہیں۔ ماڈل دستاویزی ہے، یعنی راستے کا اندازہ آئیکنز سے لگانے کے بجائے پہلے سے لگایا جا سکتا ہے۔
افسانہ: دو جڑے VPN ایک زنجیر ہیں
دو چھلانگوں کی زنجیر کے لیے متعین بیرونی نقل و حمل، متعین اندرونی سرنگ، موافق اختتامی نقطوں کی راستہ بندی اور یہ منصوبہ درکار ہے کہ دونوں میں سے کوئی ناکام ہو تو کیا ہوگا۔ دو خودمختار ترتیبیں صرف ایک ساتھ موجود ہونے سے یہ نہیں بناتیں۔ راستے کی ترجیح انکیپسولیشن جیسی نہیں ہے، اور ایک ترتیب کا راستہ تلاش جیتنا اس بارے میں کچھ نہیں کہتا کہ دوسری نتیجے میں بننے والے پیکٹ لے کر جاتی ہے یا نہیں۔
اگر آپ کو نیسٹنگ درکار ہو تو اسے نیسٹنگ کے طور پر ڈیزائن کریں۔ دو کنکشن اشاروں سے اس کا اندازہ نہ لگائیں۔ یہ فرق بہت سی ڈیبگنگ بچاتا ہے۔
اس افسانے کے پیچھے دستاویزی ماڈل
Apple کا NETunnelProviderManager عام انٹرپرائز VPN ترتیبوں کی وضاحت کرتا ہے اور کہتا ہے کہ اس قسم کی ایک ہی ایک وقت میں فعال کی جا سکتی ہے۔ وہی حوالہ Personal VPN کو اس کے ساتھ فعال اور جڑا رہنے دیتا ہے، اور جہاں دونوں اوورلیپ ہوں وہاں انٹرپرائز راستوں کو ترجیح دیتا ہے۔
یہاں Personal VPN NEVPNManager کے ذریعے منظم بلٹ ان IPsec یا IKEv2 عمل درآمد کے لیے API اصطلاح ہے۔ NETunnelProviderManager سرنگ فراہم کنندہ ماڈل ہے۔ صارف کی ایپ فراہم کنندہ ماڈل استعمال کر سکتی ہے، اس لیے personal والا مصنوعات کا نام اسے درجہ بند نہیں کرتا۔
Apple ایک اجازت شدہ مجموعہ دستاویز کرتا ہے، اور اجازت آپ کو یہ نہیں بتاتی کہ دو وینڈرز کے پروفائل موافق ہیں، اس لیے ہر وینڈر سے پوچھیں کہ کون سا جوڑا معاون ہے۔ ان کی ترتیب کی اقسام، راستے اور پالیسیاں اب بھی نتیجہ طے کرتی ہیں۔
افسانہ: ذاتی VPN براؤزنگ ٹریفک لیتی ہے
ہر منزل کا دعویٰ کرنے والا کام پروفائل عوامی براؤزنگ کے لیے راستہ تلاش بھی جیتے گا، اس لیے ذاتی اخراج اس میں سے کچھ نہیں لے کر جاتا۔ دستاویزی ترجیح کے مطابق انٹرپرائز راستے جہاں ٹکراتے ہیں وہاں جیتتے ہیں، اس لیے عوامی براؤزنگ صرف اس لیے خودبخود ذاتی اخراج نہیں لیتی کہ وہ ایپ بھی جڑا ہونے کی اطلاع دیتی ہے۔ تنگ تر کام ترتیب راستہ بندی کی تصویر بدل سکتی ہے، لیکن ادارے کا کلائنٹ پھر بھی DNS، بلاکنگ یا ڈیوائس کی شرائط عائد کر سکتا ہے۔ معاون انتظام اس کے مالک سے لیں، ان شرائط کو مقامی طور پر تبدیل کرنے کے بجائے۔
منظم ایپ کے حساب سے ترتیبوں کا اپنا دائرہ ہے۔ ڈیوائس کی سطح کے قاعدے کو ہر منظم تعیناتی تک نہ بڑھائیں۔
جانچ سے پہلے دونوں بہاؤ لکھیں: کام سروس کا نجی نام اور حد، اور نئی عوامی براؤزنگ درخواست۔ دونوں جائز ہیں، اور دونوں کو مختلف جانچ درکار ہے۔
منقسم سرنگ والی کام ترتیب کے ساتھ راستے کی ترجیح
منقسم سرنگ والا کام پروفائل اپنے درج نجی سابقوں اور اندرونی DNS لاحقے کا دعویٰ کرتا ہے، اور وہ راستے ان سے ملنے والی ہر تلاش جیتتے ہیں۔ عوامی منزلیں جو کسی انٹرپرائز راستے سے نہیں ملتیں جسمانی رابطے پر گرتی ہیں، جب تک ذاتی VPN پہلے ان کا دعویٰ نہ کرے۔ ترجیح کا قاعدہ صرف اوورلیپ ہونے والی مطابقتوں کا فیصلہ کرتا ہے، اس لیے دونوں پروفائلز کو آئیکنز کی طرح نہیں، راستہ جدولوں کی طرح پڑھنا ہوگا۔
جوڑے کو دو سطروں میں لکھیں اور ہر ایک کے لیے متوقع فاتح کا نام دیں: 10.x یا 172.16.x میں حل ہونے والا کام ہوسٹ نام انٹرپرائز سرنگ سے باہر جانا چاہیے، اور ملتا جلتا سابقہ نہ رکھنے والا عوامی پتہ بقیہ ڈیفالٹ راستہ لینا چاہیے۔ اگر دونوں سطریں ایک ہی اخراج کا نام دیں، تو تقسیم وہ نہیں کر رہی جو دستاویز بیان کرتی ہے۔
دو بہاؤ لکھیں اور ہر ایک کو جانچیں
ہر بہاؤ کے لیے لکھیں کہ کون سی منظور شدہ ترتیب اسے لے کر جانی چاہیے اور کون سا حل کنندہ ہر قسم کا نام پانا چاہیے۔ پھر نئی درخواستوں سے تصدیق کریں، کیش شدہ کام صفحے یا پرانے IP نتیجے سے نہیں۔
ایک ترتیب روکیں اور دونوں بہاؤ دہرائیں۔ ناکامی کا رویہ ڈیزائن کا حصہ ہے، اور وہی وہ حصہ ہے جو صارفین نوٹ کرتے ہیں۔ جب دونوں فراہم کنندگان مجموعے کی معاونت نہ کر سکیں، ایک منظور شدہ ترتیب پر ٹھہریں اور دستاویز کریں کہ یہ کون سا بہاؤ لے کر جاتی ہے، یا منظم واحد سرنگ ڈیزائن کی طرف جائیں۔ NETunnelProviderManager دستاویز ہم آہنگی قاعدے کا ماخذ ہے۔