ٹرمینل میں ڈاؤن لوڈ کام کرتے ہیں، لیکن VPN پر VS Code ایکسٹینشنز ناکام ہوتی ہیں

کنٹینر کے ٹرمینل میں کامیاب ہونے والے ڈاؤن لوڈ اُس ٹرمینل کے ماحول کا حقیقی ثبوت ہیں۔ وہ ایڈیٹر کے عمل، ایکسٹینشن انسٹالر یا اُس بائنری کے بارے میں کچھ نہیں کہتے جو ایکسٹینشن بعد میں لاتی ہے۔ اُن تینوں کے درمیان پراکسی متغیرات کاپی کرنا ایک ناکام درخواست کو غیر متعلقہ ترمیمات کی پوری دوپہر میں بدل دیتا ہے۔

دو ماحول عام طور پر بالکل ایک ہی پہلو میں مختلف ہوتے ہیں۔ اُس پہلو کو تلاش کرنا پراکسی دستاویزات دو بار پڑھنے سے تیز تر ہے۔

کون سا عمل ناکام درخواست کرتا ہے

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

کام کرنے والا ٹرمینل ثابت کرتا ہے کہ کنٹینر انٹرنیٹ تک پہنچ سکتا ہے، یہ نہیں کہ ایڈیٹر پہنچ سکتا ہے۔ ایکسٹینشن لاگ میں وہ آخری URL پڑھیں جو اُس نے آزمایا۔ وہاں نامزد ہوسٹ عمل اور اُس پر لاگو پالیسی کی نشاندہی کرتا ہے۔

مقامی ایڈیٹر اور دور دراز کنٹینر دو ماحول ہیں

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

کچھ بھی تبدیل کرنے سے پہلے انسٹالیشن کا مقام پڑھیں۔ جب لاگ دور دراز انسٹال کی اطلاع دے تو کنٹینر کا ماحول ہی اہم ہوتا ہے۔

پراکسی وہاں رکھیں جہاں درخواست شروع ہوتی ہے

واقعی HTTP پراکسی درکار Dev Container کے لیے، متغیر کنٹینر کی ترتیب میں ہونا چاہیے تاکہ دوبارہ تعمیر اُسے دوبارہ پیدا کرے۔ نیچے دیا گیا حصہ اُسے اُس ماحول کے لیے مقرر کرتا ہے۔ پلیس ہولڈر پتہ آپ کے اپنے گیٹ وے کی نمائندگی کرتا ہے، اور استثنائیں اختیاری بھرائی نہیں ہیں۔

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

متغیر کا نام منزل کے پروٹوکول کی وضاحت کرتا ہے، اِس لیے HTTPS_PROXY کی قدر قانونی طور پر http سے شروع ہو سکتی ہے۔ تبدیلی کو معاون دوبارہ تعمیر کے راستے سے لاگو کریں اور استثنائیں برقرار رکھیں، کیونکہ اندرونی ہوسٹوں کو روکنے والی پراکسی کنٹینر کو درکار سروسز توڑ دیتی ہے۔

اعتماد کی ناکامیوں کو رسائی سے الگ کریں

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

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

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

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