تفتح المواقع عبر 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 ولا يزال يفحص توقيعات المستودع، لأن وسيطًا يفحص حركة المرور ليس سببًا لتعطيل أي منهما. أكّد أيضًا أن العميل غير المصادق يحصل على رفض صريح بدلًا من مهلة صامتة.

احفظ المقتطف العامل والمخرجات الفاشلة معًا في سجل التغييرات. الشخص التالي الذي يصادف التعليق نفسه سيعرف الفرق بين السطرين أسرع من أي شرح.