VPN मार्फत DNS फिल्टरिङले वेबसाइट लोड हुन रोक्यो: जवाफ पढ्नुहोस्
टनेल चलिरहेको बेला फिल्टर गर्ने रिजोल्भरले एउटा नाम मात्र ब्लक गर्न सक्छ। जवाफको प्रकार पढ्नुहोस्, रिजोल्भर कसको हो पत्ता लगाउनुहोस्, र तपाईंले नियन्त्रण गर्ने कुरा मात्र परिवर्तन गर्नुहोस्।
टनेल चालु हुँदा एउटा नाम असफल हुन्छ, र ब्राउजरले यसलाई नेटवर्क त्रुटि भन्छ, जबकि वास्तविक कारण रिजोल्भरले फर्काएको DNS जवाफ हो। फिल्टर गर्ने रिजोल्भरले एउटा नाम रोक्न, अस्वीकार गर्न वा पुनः लेख्न सक्छ र बाँकी सबै खोजी काम गर्न दिन्छ। टनेलले प्रश्न बोक्छ; रिजोल्भरले जवाफ तय गर्छ। इन्क्रिप्शन सेटिङमा हात हाल्नु अघि त्यो जवाफ जाँच्नुहोस्।
टनेल चालु छ, त्यसैले इन्क्रिप्शन संदिग्ध होइन
जडानको स्थितिले प्याकेट चलिरहेको छ कि भनेर बताउँछ, नाम समाधान हुन्छ कि भनेर होइन। समाधान भनेको क्लाइन्ट कन्फिगर गरिएको सर्भरमा गरिएको प्रश्न हो, र त्यहाँको नीतिले एउटा डोमेनलाई अरू सबैभन्दा फरक जवाफ दिन सक्छ। ब्राउजरको तर्फबाट ती सबै जवाफ एउटै सामान्य असफलतामा मिल्छन्, त्यसैले स्थिति बत्तीले धेरै कम प्रमाणित गर्छ।
पहिले तीन कुरा लेख्नुहोस्: क्लाइन्टले प्रयोग गरेको रिजोल्भर, असफल हुने नामको प्रतिक्रिया कोड, र काम गर्नुपर्ने नामका लागि त्यही प्रश्न। रिजोल्भरलाई सिधै dig example.com @10.20.0.1 सँग सोध्नुहोस् र स्थिति लाइन पढ्नुहोस्, ब्राउजरको सन्देश होइन। यदि नियन्त्रण नाम समाधान भयो र असफल हुनेले नीति-जवाफ फर्कायो भने प्रमाण पूरा छ। यदि दुवै असफल भए, फिल्टर अझै संलग्न छैन।
चार जवाफ, चार फरक मालिक
फिल्टर गर्ने रिजोल्भरसँग नहुन भन्ने एउटै तरिका छैन, र अस्वीकारको रूपले फरक अर्को चरणतर्फ संकेत गर्छ। प्रतिक्रिया कोड लेख्नुहोस्, किनकि ब्राउजरले चारैलाई काटिएको जडानजस्तो सुनिने कुरामा पुनः लेख्छ।
| Answer | What it points at |
|---|---|
| NXDOMAIN | The name is withheld: a policy entry or a zone decision removed it |
| Refused | The resolver declines to answer; usually an access or policy rule |
| Replacement address | A redirect to a block page or sinkhole you can query and inspect |
| No answer at all | Weakest evidence: reachability, load or routing, not necessarily policy |
टनेललाई केही आरोप लगाउनु अघि जवाफलाई तालिकासँग मिलाउनुहोस्। अस्वीकार र रोकिएको नाम दुवैको अर्थ रिजोल्भरले निर्णय गर्यो भन्ने हो, जबकि मौनताको अर्थ प्रश्नले कहिल्यै जवाफ पाएन। यही भिन्नताले तपाईं नीति-मालिकको पछि लाग्नुहुन्छ कि नेटवर्क मार्गको भनेर निर्धारण गर्छ।
दुई ब्राउजरले दुई नीति पछ्याउन सक्छन्
आफ्नै इन्क्रिप्टेड रिजोल्भर ल्याउने ब्राउजरले अपरेटिङ सिस्टमले बाँड्ने सर्भर प्रयोग गर्नै पर्दैन, त्यसैले टनेल जुन नीतिका लागि बनाइएको थियो त्यसलाई बेवास्ता गर्न सक्छ। त्यसपछि एउटै मेसिनका दुई ब्राउजर एउटै होस्टनाममा सहमत हुँदैनन्, र कुनै पनि बिग्रेको छैन। प्रत्येक अनुप्रयोग कुन रिजोल्भरमा बाँधिएको छ जाँच्नुहोस् फिल्टरलाई असंगत भन्नु अघि।
जब दुवै अनुप्रयोगले टनेलको रिजोल्भर प्रयोग गर्छन् र एउटा मात्र असफल हुन्छ, भिन्नता अनुप्रयोगमा छ, DNS मा होइन। प्रत्येक अनुप्रयोगका लागि रिजोल्भरको ठेगाना लेख्नुहोस्, किनकि विन्डो बन्द हुँदा त्यो विवरण हराउँछ।
आफ्नो भएको परिवर्तन गर्नुहोस्, नभएको माथि पठाउनुहोस्
तपाईंको अर्को कदम तपाईंले संकेत गरिरहेको रिजोल्भर कसको हो भन्नेमा निर्भर छ। तपाईं आफैं चलाउनुहुने एउटा पढ्न र कन्फिगर गर्न सकिने सुविधा हो: अभिलेखित फिल्टरिङ विकल्प र त्यसका अपवाद हेर्नुहोस्, त्यसपछि त्यो एक नामलाई अनुमति दिनुहोस्। तपाईंको रोजगारदाता वा प्रदायकले चलाउने चाहिँ डोमेन, ठ्याक्कै जवाफ र समयसहितको टिकट हो।
साइट जबरजस्ती खोल्न कहिल्यै सार्वजनिक रिजोल्भर फेर्नु हुँदैन, किनकि निजी नाम समाधान हुन छाड्छन् र जानाजान बनाइएको नीति लागू हुन छाड्छ। साँघुरो परिवर्तनले प्रमाण पनि अक्षुण्ण राख्छ, ताकि मालिकले तपाईंको प्रतिवेदन आफ्नै अभिलेखसँग तुलना गर्न सकोस्। परिवर्तनपछि शेलबाट खोजी गर्नुको सट्टा मूल अनुप्रयोग परीक्षण दोहोर्याउनुहोस्।
ब्लक पृष्ठ विश्वसनीय प्रमाणपत्र होइन
आफ्नै प्रमाणपत्र प्रस्तुत गर्ने प्रतिस्थापन पृष्ठले HTTPS पहिचान चेतावनी उठाउँछ, र रिडाइरेक्टले त्यो प्रमाणपत्रलाई वैध बनाउँदैन। टनेल चालु छ भनेर त्यसमार्फत क्लिक गर्नु हुँदैन; चेतावनी अलग विश्वास-निर्णय हो जो अझै सही हुनुपर्छ।
असफल हुने नामले नीति-जवाफ र नियन्त्रण नामले त्यही रिजोल्भरबाट सामान्य जवाफ फर्काएपछि निदान बन्द हुन्छ। त्यो बिन्दुमा मर्मत नीतिको परिवर्तन हो, टनेलको होइन, र प्रतिवेदनमा तपाईंले उद्धृत गर्ने RFC 1035 प्रतिक्रिया कोड नै हुन्। दुवै नाम र जवाफ सँगै राख्नुहोस्; पूरै मुद्दा यही हो।