مہمان VPN اور ہوسٹ VPN: کون سا راستہ واقعی جیتتا ہے

دو کلائنٹ ایک ساتھ چل رہے ہیں، دونوں کو یقین ہے کہ ڈیفالٹ راستہ انہی کا ہے، اور علامت کچھ عجیب سی صورت میں آتی ہے: مہمان کی ایک ایپلیکیشن کام کرتی ہے، دوسری غلط جگہ پر حل ہوتی ہے۔ مہمان کے اندر VPN اور ہوسٹ پر VPN ساتھ رہ سکتے ہیں، لیکن تب ہی جب بیرونی راستہ اور اندرونی پالیسی اس بات پر متفق ہوں کہ کون کیا اٹھاتا ہے۔ دونوں کو شروع کرنا بذات خود کوئی زنجیر نہیں بناتا۔ پہلے کنکشن ریکارڈ کریں، پھر ایک وقت میں ایک چیز بدلیں۔

پہلے مہمان کا کنکشن ریکارڈ کریں

مہمان اپنے VPN سرور تک اسی راستے سے پہنچتا ہے جو ہائپر وائزر نے دیا: ہوسٹ کے پیچھے NAT، طبعی حصے پر پل، یا صرف ہوسٹ کے لیے نیٹ ورک جس پر روٹنگ شامل کی گئی ہے۔ ہر کنکشن بدلتا ہے کہ مہمان کیا دیکھ سکتا ہے اور ہوسٹ اس کی ٹریفک کے ساتھ کیا کر سکتا ہے۔ NAT کے نیچے مہمان کے پیکٹ ہوسٹ سے آتے دکھائی دیتے ہیں، اس لیے ہوسٹ کی اپنی ٹنل انہیں مہمان کو کچھ معلوم ہوئے بغیر لے جا سکتی ہے۔ پل کے نیچے مہمان کی حصے پر اپنی موجودگی اور اپنا ڈیفالٹ گیٹ وے ہوتا ہے۔

کسی بھی کنفیگریشن کو چھونے سے پہلے کنکشن ریکارڈ کریں، ساتھ یہ بھی کہ کون سا کلائنٹ کون سی ایپلیکیشن اٹھائے گا۔ یہی جملہ ایسے زیادہ تر معاملات حل کرتا ہے، کیونکہ دونوں کلائنٹ عموماً مختلف مفروضوں پر بنے ہوتے ہیں۔ جس مہمان سے ہوسٹ کی ٹنل استعمال کرنے کی توقع ہو اس کے پاس اپنا مسابقتی ڈیفالٹ راستہ بھی نہیں ہونا چاہیے۔

مہمان کے آخری نقطے کو باہر کی طرف ٹریس کریں

مہمان VPN کو کسی اور چیز کے کام کرنے سے پہلے اپنے سرور تک قابل استعمال راستہ درکار ہے۔ جب ہوسٹ کی ٹنل فعال ہو اور مہمان NAT کے پیچھے بیٹھا ہو، تو مہمان کا ہینڈ شیک ہوسٹ کی ٹنل سے باہر نکلتا ہے، جو یا تو ڈیزائن ہے یا ایسا حادثہ جسے کسی نے ریکارڈ نہیں کیا۔ جب ہوسٹ کی ٹنل گر جائے اور مہمان اس پر منحصر ہو، تو مہمان اپنی طرف ایک بھی تبدیلی کے بغیر رابطہ کھو دیتا ہے۔ آخری نقطے کو باہر کی طرف ٹریس کرنا بتاتا ہے کہ ان دونوں میں سے کون سی صورت واقعی آپ کے پاس ہے۔

کسی بھی سیاق میں وسیع راستہ دوسرے کلائنٹ کی متوقع ٹریفک پکڑ لیتا ہے۔ مہمان کے اندر 0.0.0.0/0 راستہ اور مکمل ٹنل والا ہوسٹ کلائنٹ دونوں ہر چیز کا دعویٰ کرتے ہیں، اور آخر میں لاگو ہونے والا جیتتا ہے۔ مہمان کے ورچوئل نیٹ ورکس، مقامی LAN اور دور دراز نیٹ ورکس کے درمیان اوورلیپ نجی سابقوں کے لیے وہی اثر پیدا کرتا ہے، ناکامیاں تصدیق کے مسائل جیسی لگتی ہیں؛ پتوں کی ترجمانی کا رویہ وہی ہے جو کنٹینر نیٹ ورکنگ کے لیے بیان کیا گیا ہے۔

پہلے اور بعد کا ریکارڈ موازنہ کریں

ہوسٹ کی ٹنل بند حالت میں، یا آپ کی پالیسی جو بھی کنٹرول شدہ حالت اجازت دے اس میں بنیادی لکیر لیں اور مہمان کا راستہ اور حل کنندہ ریکارڈ کریں۔ پھر مشترکہ کنفیگریشن لاگو کریں اور دونوں ریکارڈ موازنہ کریں، رازداری کی ضروریات کو برقرار رکھتے ہوئے۔ اگر براہ راست بنیادی لکیر موزوں نہ ہو تو موازنہ چھوڑنے کے بجائے وہ حد ریکارڈ میں لکھیں۔

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

راستے کا سوال بتاتا ہے کہ کون سا انٹرفیس اور ماخذ پتہ کسی مخصوص منزل کو لے جائے گا، اور یہ اس تحقیق کی سب سے مفید سطر ہے۔ قواعد کی فہرست دکھاتی ہے کہ آیا پالیسی روٹنگ کچھ منزلیں دوسرے جدول سے بھیجتی ہے۔ حل کنندہ کا آؤٹ پٹ دکھاتا ہے کہ آیا DNS نے مہمان کی ٹنل کی پیروی کی یا ہوسٹ کے راستے پر رہا۔ وہی تین کمانڈز تبدیلی سے پہلے اور بعد چلائیں، اور فرق ہی مجرم کا نام بتائے گا۔

دوبارہ آغاز کے دوران ملکیت واضح رکھیں

ہوسٹ کلائنٹ کی مقامی رسائی کی پابندی ورچوئل NAT یا پل تک ٹریفک روک سکتی ہے، اور اس پابندی کو اکثر مہمان کی اسناد کا مسئلہ سمجھ لیا جاتا ہے۔ ٹیسٹ پاس کرانے کے لیے پابندی بند کرنے کے بجائے کلائنٹ کا درج رویہ پڑھیں۔ تعاون یافتہ اصلاح کے بعد مہمان کی ایپلیکیشن اور مطلوبہ ناکامی پالیسی دوبارہ جانچیں۔ کامیابی سے دوبارہ جڑنے والا ہوسٹ مہمان کے راستے یا حل کنندہ کے بارے میں کچھ ثابت نہیں کرتا۔

طے کریں کہ ڈیفالٹ راستہ کس فریق کا ہے اور اسے آپریشن کتابچے میں لکھیں۔ مہمان کا دوبارہ آغاز یا ہوسٹ پر نیٹ ورک کی تبدیلی جو ملکیت خاموشی سے الٹ دے، ایسے VPN کے بارے میں بگ رپورٹ بناتی ہے جو کبھی مجرم نہیں تھا۔ انتظام کو ری بوٹ کے بعد بھی قائم رہنا چاہیے، بغیر کسی کو یاد ہو کہ یہ کیوں کام کرتا تھا۔