VPN गेटवेको अपडेट असफल हुन्छ: बाहिर जाने बाटो खोल्नु अघि चरण पढ्नुहोस्
असफल अपडेटले हराएको पोर्टको होइन, एउटा चरणको नाम लिन्छ। सन्देशलाई यसको मालिकसँग जोड्नुहोस्, प्रोक्सीको बाटो पढ्नुहोस् र त्यसपछि जानाजान मर्मत नीति तय गर्नुहोस्।
सुरक्षा अपडेट स्थापना गर्न इन्कार गर्नु अरू कसैको समस्या बन्नुभन्दा एक हप्ता मात्र टाढा छ, र ग्राहकहरूलाई भित्र पस्न दिने गेटवे यो बानी विकास गर्ने सबैभन्दा सजिलो ठाउँ हो। सामान्य कारण हराएको मार्ग होइन तर हराएको निर्णय हो: ग्राहक फर्वार्डिङ जानाजान साँघुरो हुँदा होस्ट आफैंले कसरी भण्डारसम्म पुग्नुपर्छ भनी कसैले भनेन। त्यो निर्णय स्पष्ट रूपमा लिनुपर्छ, र त्यो एक दिनको लागि निर्गमन नीति बन्द गर्नुभन्दा साँघुरो हुनुपर्छ।
चार चरण, चार फरक मालिक
अपडेटको असफलता नामित चरण हो, सन्देशले भनोस् वा नभनोस्, र प्रत्येक चरण फरक मालिकको हो। जुन नाम समाधान हुँदैन त्यो रिजोल्भरको प्रश्न हो। जुन जडान समयसीमा नाघ्छ त्यो यातायात, प्रोक्सी वा टाढाको छेउको प्रश्न हो। TLS पहिचानको त्रुटि विश्वासको प्रश्न हो, र अस्वीकृत भण्डार मेटाडाटा हस्ताक्षरको प्रश्न हो। चार चरण, चार मालिक, र पोर्टको नियम सधैं यीमध्ये एउटाको मात्र जवाफ दिन्छ।
| The failure text mentions | Which component owns it | What you check first | What you must not change |
|---|---|---|---|
| a name that will not resolve | the resolver policy for this host | which resolver is used, and whether its path is permitted | nothing in the firewall: no repository packet has left yet |
| a connection that times out | routing, proxy or the far end | the destination, port and proxy the manager actually attempts | the egress policy, before you know that destination |
| a TLS identity mismatch | trust configuration and the server's identity | the chain the manager is presented with | verification settings, which only hide the mismatch |
| rejected archive metadata | the repository's signing metadata | whether the source carries valid, trusted metadata | the signature check, which is not a routing question |
पिङ र नाम समाधान ती दुई परीक्षण हुन् जुन मानिसहरूले पहिले प्रयोग गर्छन्, र दुवैले कसैले नसोधेका प्रश्नको जवाफ दिन्छन्। इको जवाफले भण्डार जडानभन्दा फरक प्रोटोकल प्रयोग गर्छ, र सफल खोजी तान्ने परीक्षण नगरी नाम समाधानमा रोकिन्छ। दुवै वास्तविक कारोबार असफल हुँदा पास हुन सक्छन्, र दुवै बाटोसँग असम्बन्धित कारणले असफल हुन सक्छन्।
प्रबन्धकले वास्तवमा लिने बाटो पढ्नुहोस्
कन्फिगर गरिएका स्रोत URI र प्रोक्सीको वास्तविक मिलान जाँच्नुहोस्, तीमध्ये एउटा मानेर बस्नुको सट्टा। सादा HTTP का लागि लेखिएको नियम भण्डारले HTTPS बोल्दा मर्मत होइन, र प्रोक्सी अनिवार्य गर्ने संस्थाले बाटो पहिले नै छानिसकेको हुन्छ। प्याकेज प्रबन्धकहरू वातावरण चर र आफ्नै कन्फिगरेसनको आदर गर्छन्, र होस्ट-विशिष्ट सेटिङले विश्वव्यापी सेटिङलाई पछि पार्न सक्छ। अन्तरक्रियात्मक ब्राउजरले गर्ने कुरा प्रबन्धकले गर्नुपर्छ भन्ने छैन।
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyAPT यातायात कागजात ले कुन सेटिङ कुन URI योजनामा लागू हुन्छ र होस्ट-विशिष्ट छनोट कसरी लेखिन्छ भनी वर्णन गर्छ। आदेशको आउटपुट टिकटसँग राख्नुहोस्, किनकि यसले प्रोक्सी समस्या हराएको बाटोबाट पिङ नतिजाको जतिसुकै संख्याभन्दा छिटो अलग गर्छ। प्रबन्धकले प्रयास गर्ने ठ्याक्कै गन्तव्य, पोर्ट र प्रोटोकल लेख्नुहोस्, र फायरवाल परिवर्तनलाई महिनाभरमा पुरानो हुने अनुमानित मिरर ठेगानामा होइन, त्यही अभिलेखमा टेकाउनुहोस्।
मर्मत नीति छान्नुहोस्, अपवाद होइन
तीन नीति रक्षात्मक छन्: सुरुङमार्फत मर्मत, व्यवस्थित अपडेट प्रोक्सीमार्फत मर्मत, वा साँघुरो अधिकृत सिधा मार्गमार्फत मर्मत। प्रत्येकले आफूलाई मिल्ने रिजोल्भर मिलान मान्छ। जुन रक्षात्मक छैन त्यो अपवाद हो जुन सुरुङ खस्ने हरेक पटक चुपचाप असीमित वैकल्पिक मार्ग बन्छ।
छानिएको नीति मालिकसँगै लेख्नुहोस्, किनकि अर्को अपरेटरले नियम भेट्टाउनेछ, त्यसपछिको तर्क होइन। अनुमति विद्यमान फायरवाल र नेटवर्क मालिकमार्फत लागू गर्नुहोस्, नियम खाली गरेर वा एउटा होस्टका लागि दोस्रो नीति प्रबन्धक थपेर होइन। वास्तविक स्रोतले प्रयोग गर्ने ठेगाना परिवार र सेवा अन्त्यबिन्दु समेट्नुहोस्, र भण्डार सर्दा सूचीको समीक्षा गर्नुहोस्।
विश्वास कमजोर नबनाई प्रमाणित गर्नुहोस्
सफल यातायात प्रमाणीकरण खुकुलो पार्ने अनुमति होइन: भण्डार प्रमाणीकरण र TLS सर्भर पहिचान दुई फरक जाँच हुन्, र कुनै एउटा बन्द गर्दा त्रुटि हराउँछ तर होस्टले के स्वीकार्नेछ त्यो बदलिन्छ। अवरोध गर्ने प्रोक्सी नेटवर्क मालिकको विश्वास निर्णय हो, जाँच स्थानीय रूपमा बन्द गर्ने कारण होइन, र भण्डारका प्रमाणहरू साझा निदानमा हुनु हुँदैन, किनकि विस्तृत लग तिनलाई चुहाउने सबैभन्दा सजिलो ठाउँ हो।
परिवर्तनलाई नियन्त्रित मेटाडाटा पुनःप्राप्ति र त्यसपछि एक स्वीकृत प्याकेज कारोबारसँग स्वीकार्नुहोस्, त्यसपछि सुरुङ खस्दा के हुन्छ परीक्षण गर्नुहोस्। अवरोधका क्रममा चुपचाप फराकिलो हुने मर्मत मार्ग बन्द भएर असफल हुने मार्गभन्दा नराम्रो छ, र नतिजा नामित मालिक र सीमित दायरा भएको अपडेट मार्ग हुनुपर्छ।