तपाईंको 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 सर्भरको पहिचान छुट्टाछुट्टै ग्यारेन्टी हुन्, र कुनै त्रुटि शान्त पार्न यीमध्ये कुनै पनि बन्द गर्नुले तपाईं केमा भरोसा गर्नुहुन्छ त्यो बदल्छ, तपाईं कहाँ पुग्न सक्नुहुन्छ त्यो होइन।

सुरुङ बिनाको अवस्थालाई जानाजान जाँचेर टुंग्याउनुहोस्। सुरुङ बिना गेटवे कसरी व्यवहार गर्छ भन्ने जान्नु डिजाइनको भाग हो, व्यवधानका बेला त्यो पत्ता लगाउनु होइन। सुरुङ तल झार्नुहोस्, मेटाडेटा रिफ्रेस चलाउनुहोस् र होस्ट तपाईंले चाहेकै तरिकाले असफल हुन्छ भनी पुष्टि गर्नुहोस्, चुपचाप खुला बाटोमा फर्किनुको सट्टा। भण्डार र प्रोक्सीका प्रमाणहरू साझा निदानबाट बाहिर राख्नुहोस् र अद्यावधिक बाटोको मालिक को हो भनी उल्लेख गर्ने टिप्पणी छोड्नुहोस्।