आपके VPN गेटवे को अब भी अद्यतन स्थापित करने का रास्ता चाहिए

सुरंग उसके पीछे मौजूद हर किसी के लिए काम करती है, गेटवे उनका ट्रैफ़िक आगे भेजता है, फिर भी मशीन खुद कोई सुरक्षा अद्यतन स्थापित नहीं कर पाती। समस्या का यही सामान्य रूप है: फ़ॉरवर्डिंग की अनुमति क्लाइंट को दी गई, और गेटवे के अपने आउटबाउंड कनेक्शन योजना में कभी शामिल नहीं किए गए। पैकेज प्रबंधक अपने सॉकेट खोलता है, गेटवे से, ऐसे रिपॉज़िटरी की ओर जिसका नाम आपने फ़ायरवॉल नीति में शायद कहीं नहीं रखा।

गेटवे को बंद करना सही है। उसे इतनी कसकर बंद करना कि वह पैच लेना बंद कर दे, एक अलग निर्णय है, और आमतौर पर अनजाने में लिया गया।

स्थानीय आउटपुट क्लाइंट फ़ॉरवर्डिंग नहीं है

फ़ॉरवर्डिंग नियम उन पैकेटों पर लागू होते हैं जो कहीं और से आते हैं और गेटवे से होकर निकलते हैं। गेटवे का अपना अद्यतन ट्रैफ़िक उनसे कभी मेल नहीं खाता; वह स्थानीय रूप से बनता है और आउटपुट पथ से गुज़रता है। यही अंतर ऐसी विफलता समझाता है जो असंभव लगती है जबकि क्लाइंट पहुँच बिल्कुल ठीक काम करती है।

यह उस नीति-अंतराल को भी समझाता है जो परीक्षणों से बच निकलता है, क्योंकि सुरंग के पीछे लैपटॉप से की गई त्वरित जाँच साबित करती है कि फ़ॉरवर्डिंग श्रृंखला काम करती है और मेज़बान के अपने कनेक्शन के बारे में कुछ नहीं कहती। गेटवे को दो विषयों की तरह देखें: फ़ॉरवर्डिंग श्रृंखला वाला राउटर और आउटपुट श्रृंखला वाला मेज़बान। दोनों को एक राय चाहिए, और आमतौर पर सिर्फ़ एक लिखी जाती है।

उस चरण का नाम बताएँ जो विफल हुआ

अद्यतन त्रुटियाँ अलग-अलग सीमाओं के नाम बताती हैं, और यह पढ़ने से पहले कि कौन-सी विफल हुई पोर्ट नियम पर झपटना दोपहर बर्बाद करता है। ऐसा रिपॉज़िटरी नाम जो हल न हो, resolver का सवाल है, परिवहन का सवाल नहीं।

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

सफल लुकअप के बाद का टाइमआउट सवाल को परिवहन की ओर ले जाता है: पैकेज प्रबंधक ने वास्तव में कौन-सा पता, कौन-सा पोर्ट और कौन-सा कॉन्फ़िगर किया गया प्रॉक्सी आज़माया। TLS सत्यापन की विफलता तीसरी, बिल्कुल अलग चीज़ है, और इसका मतलब है कि कनेक्शन बातचीत के लिए काफ़ी अच्छी तरह काम कर गया। संग्रह प्रमाणीकरण की शिकायत चौथा चरण है, और यह पहुँच के बजाय हस्ताक्षरित मेटाडेटा से जुड़ी है। चार चरण, चार अलग मरम्मतें, और ping हमेशा केवल एक प्रोटोकॉल बताता है जिसे कोई भी पैकेज प्रबंधक इस्तेमाल नहीं करता।

नियम जोड़ने से पहले स्रोत सूची पढ़ें

याद रखे गए स्रोतों के बजाय वास्तविक स्रोत URI और प्रभावी प्रॉक्सी कॉन्फ़िगरेशन की सूची बनाएँ। सादे HTTP के लिए लिखा नियम तब बेकार है जब स्रोत HTTPS हो, और शेल को ज्ञात प्रॉक्सी ऐसी सेवा के लिए अदृश्य हो सकता है जो बूट पर किसी दूसरे वातावरण के साथ शुरू होती है।

APT में HTTP परिवहन का दस्तावेज़ पर्यावरण और APT-विशिष्ट प्रॉक्सी सेटिंग्स को कवर करता है, जिसमें प्रति मेज़बान विकल्प भी शामिल हैं, और इसके HTTPS परिवहन की अपनी सत्यापन सेटिंग्स हैं। ब्राउज़र का रास्ता और पैकेज प्रबंधक का रास्ता अलग-अलग रास्ते हैं, एक ही मशीन पर भी।

ध्यान दें कि स्रोत किन पता परिवारों में हल होते हैं। केवल IPv4 की अनुमति देने वाला नियम ऐसे मेज़बान पर विफल रहेगा जिसके स्रोत AAAA रिकॉर्ड को प्राथमिकता देते हैं, और त्रुटि रुक-रुककर दिखती है क्योंकि यह इस पर निर्भर है कि कौन-सा उत्तर पहले आता है।

रखरखाव का एक रास्ता चुनें और उस पर टिके रहें

तीन बचाव-योग्य विकल्प हैं: रखरखाव ट्रैफ़िक सुरंग के ज़रिए, प्रबंधित अद्यतन प्रॉक्सी के ज़रिए, या संकीर्ण प्रत्यक्ष अपवाद के ज़रिए। एक को सोच-समझकर चुनें और resolver को उससे सहमत करें, क्योंकि ऐसा विभाजन जिसमें नाम एक दिशा में हल होते हैं और कनेक्शन दूसरी दिशा में जाते हैं, ऐसी विफलताएँ पैदा करता है जिन्हें कोई समझा नहीं सकता।

आप जो भी चुनें, यह असीमित वैकल्पिक रास्ता नहीं बनना चाहिए। यदि सुरंग बंद होने पर सीधा आउटबाउंड ट्रैफ़िक मना है, तो रखरखाव का ऐसा अपवाद जो चुपचाप सब कुछ अनुमत कर दे, मरम्मत के भेस में नीति परिवर्तन है। सुरंग के अपने एंडपॉइंट और bootstrap आवश्यकताओं को रिपॉज़िटरी पहुँच से अलग श्रेणी में रखें, क्योंकि वे अलग गंतव्यों की ओर इशारा करते हैं और अलग तरह से विफल होते हैं, इसलिए एक छूट दूसरी को नहीं ढक सकती।

जाँचों को कमज़ोर किए बिना सत्यापित करें

दायरा उसी फ़ायरवॉल के ज़रिए लागू करें जो पहले से नीति का मालिक है, बजाय यह कि दूसरा प्रबंधक जोड़ें क्योंकि किसी गाइड ने उसका इस्तेमाल किया। फिर रखरखाव की गई नीति के अंतर्गत मेटाडेटा रीफ़्रेश और एक वास्तविक पैकेज लेनदेन चलाएँ, और केवल निकास स्थिति नहीं बल्कि आउटपुट पढ़ें।

सफल परिवहन सत्यापन ढीला करने की अनुमति नहीं है। संग्रह प्रमाणीकरण और TLS सर्वर की पहचान अलग-अलग गारंटियाँ हैं, और किसी त्रुटि को शांत करने के लिए इनमें से किसी को भी बंद करना यह बदलता है कि आप किस पर भरोसा करते हैं, यह नहीं कि आप कहाँ पहुँच सकते हैं।

सुरंग के बिना वाले मामले को जानबूझकर जाँचकर समाप्त करें। यह जानना कि सुरंग के बिना गेटवे कैसा व्यवहार करता है, डिज़ाइन का हिस्सा है, किसी व्यवधान के दौरान उसे जानना नहीं। सुरंग नीचे करें, मेटाडेटा रीफ़्रेश चलाएँ और पुष्टि करें कि मेज़बान उसी तरह विफल होता है जैसा आपने चाहा था, न कि चुपचाप खुले रास्ते पर लौट जाए। रिपॉज़िटरी और प्रॉक्सी के क्रेडेंशियल साझा निदान से बाहर रखें और ऐसा नोट छोड़ें जिसमें लिखा हो कि अद्यतन पथ का मालिक कौन है।