غالبًا ما توصي الإجابات القديمة عن «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 socks5h لSOCKS5 مع تحليل DNS عن بُعد. استخدم المخطط الموثّق للإصدار المثبّت بدلًا من اختصاره إلى تسمية يقبلها برنامج آخر صدفة.

كذلك فإن Acquire::socks::Proxy في مقتطف قديم من منتدى ليس دليلًا على أن طريقة الجلب HTTP تقرأ ذلك الإعداد. فمحلّل الإعدادات قد يقبل مفتاحًا دون أن تستخدمه طريقة التنزيل.

للعناوين المحلية حدّ

عندما يعمل APT داخل حاوية أو جهاز ظاهري، يشير 127.0.0.1 إلى تلك البيئة. أما مستمع SOCKS على المضيف فهو نقطة طرفية مختلفة. تحقق من مكان تنفيذ APT قبل تشخيص اتصال محلي مرفوض.

كما أن دعم SOCKS لا يزيل فحوص توقيع المستودع أو شهادة HTTPS. أبقِ تلك الحمايات مفعّلة. وإذا كان APT المثبّت يفتقر إلى القدرة الموثّقة، فاختر بديلًا معتمدًا أو مسار تحديث بدلًا من التعامل مع مخطط URI غير معروف كمشكلة كلمة مرور.

مقالات ذات صلة