तुमच्या 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 सर्व्हरची ओळख या वेगवेगळ्या हमी आहेत, आणि त्रुटी शांत करण्यासाठी यापैकी कोणतीही बंद करणे हे बदलते की तुम्ही कशावर विश्वास ठेवता, हे नाही की तुम्ही कुठवर पोहोचू शकता.

बोगद्याशिवायच्या प्रकरणाची जाणीवपूर्वक चाचणी करून समारोप करा. बोगद्याशिवाय गेटवे कसा वागतो हे जाणणे हे रचनेचा भाग आहे, व्यत्ययाच्या वेळी ते शोधणे नाही. बोगदा खाली करा, मेटाडेटा रीफ्रेश चालवा आणि यजमान तुम्ही ठरवलेल्या पद्धतीनेच अयशस्वी होतो याची खात्री करा, शांतपणे खुल्या मार्गावर परत न जाता. रेपॉझिटरी आणि प्रॉक्सीची ओळखपत्रे सामायिक निदानाबाहेर ठेवा आणि अद्यतन मार्गाचा मालक कोण आहे हे सांगणारी नोंद ठेवा.