دانلودها در ترمینال کار می‌کنند، اما افزونه‌های VS Code روی VPN شکست می‌خورند

دانلودهایی که در ترمینال کانتینر موفق می‌شوند شاهدی واقعی درباره محیط همان ترمینال هستند. آن‌ها هیچ چیزی درباره فرایند ویرایشگر، نصب‌کننده افزونه یا فایل دودویی که افزونه بعداً می‌گیرد نمی‌گویند. کپی کردن متغیرهای پروکسی میان این سه یک درخواست ناموفق را به یک بعدازظهر کامل از ویرایش‌های بی‌ربط تبدیل می‌کند.

دو محیط معمولاً دقیقاً در یک جهت با هم تفاوت دارند. یافتن آن جهت از دو بار خواندن مستندات پروکسی سریع‌تر است.

کدام فرایند درخواست ناموفق را فرستاد

در یک نصب واحد ممکن است سه درخواست شکست بخورند و هر یک هویت شبکه‌ای خودش را دارد. ویرایشگر از Marketplace فراداده و نشانی بسته را می‌خواهد و سپس بسته را دانلود می‌کند. تنها پس از آن است که میزبان افزونه کدی را اجرا می‌کند که ممکن است یک سرور زبان یا فایل دودویی خودش را بگیرد. مرحله‌ای که شکسته است تعیین می‌کند کدام فرایند به پروکسی نیاز دارد، و سطح خطا به‌ندرت نام آن مرحله را می‌آورد.

ترمینالِ کارکننده ثابت می‌کند کانتینر می‌تواند به اینترنت برسد، نه اینکه ویرایشگر می‌تواند. گزارش افزونه را برای آخرین نشانی‌ای که امتحان کرده بخوانید. میزبانی که آنجا نام برده می‌شود فرایند و سیاستی را که بر آن اعمال می‌شود مشخص می‌کند.

ویرایشگر محلی و کانتینر راه دور دو محیط‌اند

در یک فضای کاری راه دور، افزونه در سمتی اجرا می‌شود که نوعش اعلام می‌کند. افزونه‌های رابط با ویرایشگر محلی می‌مانند و افزونه‌های فضای کاری در کانتینر اجرا می‌شوند. پروکسی‌ای که در یکی تنظیم شود برای دیگری نامرئی است، و بازسازی محیط کانتینر را از فایل پیکربندی آن می‌سازد نه از چیزی که در یک پوسته صادر کرده‌اید. این شکاف توضیح می‌دهد چرا همان افزونه روی یک لپ‌تاپ نصب می‌شود و در همان پروژه از طریق SSH شکست می‌خورد.

پیش از ویرایش هر چیزی محل نصب را بخوانید. وقتی گزارش از نصب راه دور خبر می‌دهد، محیط کانتینر است که اهمیت دارد.

پروکسی را همان‌جا بگذارید که درخواست آغاز می‌شود

برای Dev Container که واقعاً به پروکسی HTTP نیاز دارد، متغیر باید در پیکربندی کانتینر باشد تا بازسازی آن را بازتولید کند. قطعه زیر آن را برای همان محیط تنظیم می‌کند. نشانی جای‌نگهدار نماینده دروازه خودتان است، و استثناها پرکننده اختیاری نیستند.

"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 شروع شود. تغییر را از مسیر بازسازی پشتیبانی‌شده اعمال کنید و استثناها را نگه دارید، زیرا پروکسی‌ای که میزبان‌های داخلی را رهگیری می‌کند سرویس‌هایی را که کانتینر لازم دارد می‌شکند.

شکست‌های اعتماد را از دسترس‌پذیری جدا کنید

پروکسی‌ای که متصل می‌شود و سپس خطای بررسی گواهی برمی‌گرداند به مرحله‌ای دیرتر از پروکسی‌ای رسیده که اتصال را رد می‌کند. شکست اول مواد اعتماد تأییدشده سازمان را می‌خواهد که در محیط اجراکننده درخواست نصب شده باشد. شکست دوم نشانی و درگاهی قابل دسترس می‌خواهد. برخورد با آن دو به‌عنوان یک مشکل راه‌حلی می‌سازد که برای هیچ‌کدام کار نمی‌کند.

غیرفعال کردن بررسی، یا اجرای ویرایشگر با اختیارات بالا، تعمیری برای پروکسی غایب یا زنجیره اعتماد غایب نیست. هر دو یک خطای دیدنی را با خطایی خاموش عوض می‌کنند. سپس همان افزونه را دوباره امتحان کنید و نشانی بعدی‌ای را که شکست می‌خورد یادداشت کنید.

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

یادداشت کنید کدام سمت فضای کاری آن نشانی را تولید کرد. یادداشت کوتاهی که مرحله، میزبان و سمت را نام ببرد از فهرستی از تنظیماتی که کسی تغییر داده ارزشمندتر است، زیرا همان یادداشت چیزی است که نفر بعدی می‌تواند بازتولید کند.