پاسخ‌های قدیمی درباره «APT از طریق SOCKS» اغلب یک پوشش یا رلهٔ HTTP به SOCKS پیشنهاد می‌کنند. آن پاسخ‌ها ممکن است محدودیت‌های واقعی نسخه‌های قدیمی را توصیف کنند. اما در نسخه‌ای از APT که پشتیبانی socks5h را مستند می‌کند، تنها گزینه نیستند.

یک قطعه پیکربندی می‌تواند از کلیدهای انتقال واکشی موجود استفاده کند:

Acquire::http::Proxy "socks5h://127.0.0.1:1080/";
Acquire::https::Proxy "socks5h://127.0.0.1:1080/";

این مثال فرض می‌کند یک شنوندهٔ SOCKS5 مجاز از قبل روی همان ماشین وجود دارد. خودش یکی را راه‌اندازی نمی‌کند. ارسال دینامیک SSH یکی از راه‌های ساختن آن شنوندهٔ محلی است. اگر پروکسی راه دور است، به‌جای آن از نقطهٔ پایانی واقعی و قابل دسترسش استفاده کنید؛ نامزدهای فهرست پروکسی SOCKS5 فقط جایی کاربرد دارند که پروکسی‌های عمومی برای درخواست‌های مخزن مجاز باشند.

طرح، بخشی از دستور است

راهنمای انتقال APT برای SOCKS5 با تفکیک DNS از راه دور، socks5h را فهرست می‌کند. برای نسخهٔ نصب‌شده از طرح مستند استفاده کنید و آن را به برچسبی که برنامهٔ دیگری تصادفاً می‌پذیرد کوتاه نکنید.

به همین ترتیب، Acquire::socks::Proxy در یک قطعهٔ قدیمی انجمن دلیلی بر این نیست که روش واکشی HTTP آن تنظیم را می‌خواند. یک تجزیه‌کنندهٔ پیکربندی می‌تواند کلیدی را بپذیرد بدون آنکه روشی برای دانلود از آن استفاده کند.

نشانی محلی مرزی دارد

وقتی APT درون یک کانتینر یا ماشین مجازی اجرا می‌شود، 127.0.0.1 به همان محیط اشاره دارد. شنوندهٔ SOCKS روی میزبان نقطهٔ پایانی دیگری است. پیش از عیب‌یابی یک اتصال محلی ردشده، بررسی کنید APT کجا اجرا می‌شود.

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

مقالات مرتبط