VPN آن ہے اور localhost کام نہیں کرتا: نام، پراکسی یا bind؟

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

جب localhost کارپوریٹ زون میں حل ہوتا ہے

ٹنل چڑھنے کے دوران دیکھیں کہ نام کس میں حل ہوتا ہے، پھر ٹنل اتار کر وہی استفسار چلائیں اور دونوں جواب موازنہ کریں۔ جہاں آپ 127.0.0.1 کی توقع رکھتے تھے وہاں کارپوریٹ رینج کا پتہ ملنا ہی اشارہ ہے۔ localhost.mycompany.corp جیسا ریکارڈ کلائنٹ کے اس لاحقہ کو تلاش فہرست میں شامل کرنے ہی سے لوپ بیک اندراج کو ہرا دیتا ہے، اور درخواست اس نجی ہوسٹ تک جاتی ہے جہاں اس پورٹ پر کچھ نہیں سن رہا۔ تلاش فہرست کا اندازہ لگانے کے بجائے پڑھیں، کیونکہ کلائنٹ ایک سے زیادہ ڈومین شامل کر سکتا ہے اور ترتیب طے کرتی ہے کہ کون سا امیدوار پہلے آزمایا جائے:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

ایپلیکیشن، ڈیٹا بیس کلائنٹ یا نوٹ بک URL میں ہوسٹ نام کی جگہ لفظی پتہ رکھیں، پھر درخواست دہرائیں۔ اگر ناکامی ختم ہو جائے تو آپ کو نام رکھنے کا مسئلہ تھا اور ٹنل صرف محرک تھا۔ اگر وہ برقرار رہے تو سننے والا یا راستہ اگلا مشتبہ ہے اور نام صرف گمراہ کن نشان تھا۔

لوپ بیک پکڑنے والی پراکسی سیٹنگز

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

ایپلیکیشن فریم ورک اپنے ماحول کے متغیرات اور بعض اوقات اپنی کنفیگریشن فائل پڑھتے ہیں، اس لیے ایک ٹول کے لیے کام کرنے والا استثنا اگلے کے لیے کچھ ثابت نہیں کرتا۔ براؤزر ایک باریکی شامل کرتے ہیں: Chromium پر مبنی براؤزر لوپ بیک کے لیے پراکسی کو بالواسطہ طور پر نظرانداز کرتے ہیں، اور استثنا ٹوکن اس رویے کو ہٹا سکتا ہے۔ آپریٹنگ سسٹم کی سیٹنگ کو پوری کہانی ماننے کے بجائے حقیقی پراکسی فیصلہ جانچیں۔ شیل سے شروع ہونے والی ہر چیز کے لیے دو حکم یہ طے کرتے ہیں:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

bind پتہ طے کرتا ہے کون جڑ سکتا ہے

127.0.0.1 پر شروع ہونے والا سرور صرف اسی مشین سے کنکشن قبول کرتا ہے، جو ڈویلپمنٹ کے لیے عام طور پر درست ڈیفالٹ ہے۔ 0.0.0.0 پر سرور VPN اڈاپٹر سمیت ہر انٹرفیس پر جواب دیتا ہے، جو زیادہ تر لوگوں کے ارادے سے زیادہ افشا ہے۔ جب لفظی لوپ بیک پتہ ناکام ہو تو سب سے پہلے bind دیکھیں۔

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

جہاں ڈیبگنگ ٹول LAN کی توقع کرتا ہے

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

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

ناکام ہونے والے پہلے مرحلے پر رکیں

تین مراحل میں اتریں: نام حل کریں، لفظی پتے کے لیے ساکٹ کھولیں، پھر ٹول کو اپنا کنکشن بنانے دیں۔ ہر مرحلہ ایک تہہ ہٹاتا ہے، اس لیے پہلی ناکامی درست کرنے والی تہہ کا نام لیتی ہے اور اس کے بعد سب کچھ جانچے بغیر رہتا ہے۔ کچھ بھی بدلنے سے پہلے نتیجہ لکھیں، کیونکہ پیمائش سے پہلے لاگو کیا گیا سدھار قسمت سے الگ نہیں پہچانا جا سکتا۔ اگر پہلی کوشش ناکام ہو اور دوبارہ کوشش کام کرے تو ٹول شروع ہونے کے وقت ٹنل شاید تیار نہ تھا۔

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