سایت‌ها از طریق VPN باز می‌شوند، اما apt به مخزن نمی‌رسد

VPN وصل می‌شود، ویکی داخلی در مرورگر بارگذاری می‌شود، و apt update هنوز روی آینه‌ای معلق است که نمی‌تواند به آن برسد. در آن تصویر هیچ چیز در تونل خراب نیست. مرورگر و مدیر بسته‌ها دو تصمیم پروکسی جداگانه گرفتند و تنها یکی از آن‌ها پیکربندی شده بود.

اینکه کدام تصمیم شکست خورده، تنها چیزی است که ارزش دارد اول مشخص شود.

پیش از دست زدن به یک تنظیم، خطا را بخوانید

هر مرحله پیام متفاوتی بر جای می‌گذارد. نامی که هرگز حل نمی‌شود DNS است، اتصالی که هرگز کامل نمی‌شود مسیریابی یا دیوار آتش است، خطای 407 فوری احراز هویت پروکسی است، شکایت درباره گواهی بررسی TLS است و هشدار درباره امضا فراداده مخزن است. این پنج خرابی به پنج اصلاح مختلف نیاز دارند و خط پروکسی‌ای که روی یک مشکل DNS چسبانده شود فقط محل گیر کردن را جابه‌جا می‌کند.

پیش از تغییر هر چیزی، خط دقیق و مخزنی را که نام می‌برد کپی کنید. خاطره مبهم «زمان تمام شد» همان چیزی است که یک تشخیص ده دقیقه‌ای را به یک بعدازظهر کامل تبدیل می‌کند.

APT تنظیمات پروکسی خودش را نگه می‌دارد

APT فایل /etc/apt/apt.conf.d/، فایل اصلی apt.conf و هر فایلی را که APT_CONFIG نام می‌برد می‌خواند. پروفایل پروکسی میزکار، تنظیم شبکه GNOME یا افزونه مرورگر را نمی‌خواند. اما لایه انتقال متغیرهای محیطی پروکسی را رعایت می‌کند، و به همین دلیل export https_proxy=... کارآمد در پوسته شما درباره یک زمان‌سنج که در محیط دیگری اجرا می‌شود چیزی را اثبات نمی‌کند.

آنچه را که فرآیند ناموفق واقعاً می‌بیند تخلیه کنید: apt-config dump | grep -i proxy.

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

پروکسی را همان‌جا تنظیم کنید که صاحب پیکربندی انتظار دارد

برای یک پروکسی صریح که مدیر تأیید کرده، یک قطعه کوچک در یک فایل جدید کافی است:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

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

قطعه را به‌عنوان یک فایل شماره‌دار جدید اضافه کنید، مثلاً /etc/apt/apt.conf.d/95proxy. بازنویسی یک فایل توزیع یعنی به‌روزرسانی بعدی بسته‌ها بی‌صدا تغییر شما را برمی‌گرداند.

اعتبارنامه‌ها بیرون از URI می‌مانند

مرجع لایه انتقال APT برای احراز هویت به apt_auth.conf اشاره می‌کند و نام کاربری و گذرواژه همان‌جا جای دارند. جای‌دادن آن‌ها در URI پروکسی، آن‌ها را در فهرست فرآیندها، تاریخچه پوسته و هر تخلیه پیکربندی که در یک تیکت چسبانده می‌شود قرار می‌دهد. فایل احراز هویت به مجوزهای سخت‌گیرانه نیاز دارد، زیرا انبار اعتبارنامه است.

طرح را هم بررسی کنید. مخزن HTTPS همچنان از طریق پروکسی HTTP در دسترس است؛ لایه انتقال انتخابی جدا از طرح URI آینه است.

مرکز نرم‌افزاری گرافیکی یک رابط جداست. اگر از PackageKit یا پشتوانه snap استفاده کند، قطعه APT برای آن هیچ چیزی را تغییر نمی‌دهد، پس بررسی کنید کدام فرآیند درخواست ناموفق را ساخته است.

مسیر را تأیید کنید، نه فقط کد خروج را

وقتی قطعه سر جایش است، به‌جای اعتماد به یک نتیجه سبز، درخواست را تماشا کنید. apt-get -o Debug::Acquire::http=true update تلاش اتصال، پروکسی انتخاب‌شده و کد پاسخ را چاپ می‌کند، و همین پروکسی اشتباه را از پروکسی‌ای که شما را رد کرده جدا می‌کند.

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

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