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 प्रतिसाद कोड उद्धृत करता तेच ते आहेत। दोन्ही नावे आणि उत्तरे एकत्र ठेवा; हाच संपूर्ण प्रकार आहे।