वेबसाइटहरू 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 प्रमाणित गर्छ र अझै रिपोजिटरीका हस्ताक्षर जाँच्छ भनी पुष्टि गर्नुहोस्, किनकि ट्राफिक जाँच्ने प्रोक्सी यीमध्ये कुनै पनि बन्द गर्ने कारण होइन। साथै अप्रमाणित क्लाइन्टले चुपचाप समय-समाप्तिको सट्टा स्पष्ट अस्वीकृति पाउँछ भनी पुष्टि गर्नुहोस्।

चालु टुक्रा र असफल आउटपुट परिवर्तन रेकर्डमा सँगै राख्नुहोस्। अर्को पटक त्यही अड्काइ भोग्ने व्यक्तिले दुई लाइनको फरक कुनै पनि व्याख्याभन्दा छिटो चिन्नेछ।