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 सर्वर पहचान दो अलग जाँचें हैं, और इनमें से किसी को बंद करना त्रुटि को गायब कर देता है जबकि यह बदलता है कि मेज़बान क्या स्वीकार करेगा। अवरोधक प्रॉक्सी नेटवर्क स्वामी का विश्वास निर्णय है, जाँच को स्थानीय रूप से बंद करने का कारण नहीं, और भंडार की साख साझा निदान में नहीं होनी चाहिए, क्योंकि विस्तृत लॉग उन्हें लीक करने की सबसे आसान जगह है।
परिवर्तन को नियंत्रित मेटाडेटा प्राप्ति और फिर एक स्वीकृत पैकेज लेन-देन के साथ स्वीकार करें, फिर परखें कि सुरंग गिरने पर क्या होता है। रखरखाव का वह मार्ग जो रुकावट के दौरान चुपचाप चौड़ा होता है, उस मार्ग से बुरा है जो बंद होकर विफल होता है, और परिणाम नामित स्वामी और सीमित दायरे वाला अपडेट मार्ग होना चाहिए।