webpack ڈیو سرور کو VPN پتے پر کیسے پیش کریں

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

تین سوال جواب کا تعین کرتے ہیں: کون جڑتا ہے، وہ کس پتے تک پہنچ سکتے ہیں، اور کیا ان کے لیے لائیو ری لوڈ کام کرنا چاہیے۔

کنفیگ فائل سے نہیں، ساکٹ سے شروع کریں

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

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

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

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

بائنڈ پتہ اس بنیاد پر منتخب کریں کہ کس کو وہاں پہنچنا ہے

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

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

پھر پتہ اسی شکل میں مقرر کریں جو آپ کا لانچر واقعی پڑھتا ہے۔ کنفیگ فائل اور سرور کو پروگراماتی طور پر بنانے والی اسکرپٹ ایک جیسے آپشن استعمال نہیں کرتیں:

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

اس ٹکڑے میں پتہ مثال کے طور پر ہے اور ہوسٹ کے پاس موجود VPN پتے کی نمائندگی کرتا ہے۔ اگر پروجیکٹ سرور کو new WebpackDevServer(options, compiler) سے بناتا ہے تو اس کے بجائے آپشن کنسٹرکٹر آرگیومنٹ کے ذریعے بھیجیں، کیونکہ webpack کنفیگریشن کی الگ devServer خاصیت اس راستے پر نہیں دیکھی جاتی۔ کنفیگ فائل اور Node API کے درمیان یہ فرق ان لوگوں کو پکڑتا ہے جو ٹکڑا ایسے پروجیکٹ میں نقل کرتے ہیں جو اسے کبھی نہیں پڑھتا۔ dev-server دستاویزات دو لانچ اسٹائل الگ کرتی ہیں اور استعمال شدہ ورژن سے موازنہ کرنے کا حوالہ ہیں۔

ہوسٹ نام کی جانچ کو ان ناموں سے ہم آہنگ کریں جن کی آپ منظوری دیتے ہیں

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

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

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

صفحہ اور لائیو ری لوڈ ساکٹ کو ساتھ ملا کر تصدیق کریں

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

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

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

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