खरे स्रोत शोधण्यासाठी DNS क्वेरीचा टप्प्याटप्प्याने माग काढा
लादलेला रिझोल्व्हर पत्ता रिझोल्व्हर कोणता स्रोत पाहतो हे ठरवत नाही. क्लायंट, फॉरवर्डर आणि प्राप्त करणारा सर्व्हर यांचा माग काढा, नंतर मार्ग लिहा.
क्लायंटला रिझोल्व्हर पत्ता देणे हे ठरवते की क्वेरी कुठे जातात, रिझोल्व्हर कोणता स्रोत पाहील हे नाही. राउटिंग, फॉरवर्डिंग आणि भाषांतर दोन्ही टोकांमध्ये आलटून पालटून येतात. स्रोताबद्दलच्या प्रश्नांसाठीची रनबुक क्वेरीचा टप्प्याटप्प्याने माग काढते आणि प्रत्येक निरीक्षकाने प्रत्यक्षात काय पाहिले ते नोंदवते. क्रम महत्त्वाचा आहे, कारण निरीक्षणापूर्वी केलेला दावा हा केवळ चांगल्या स्वरूपणाचा अंदाज असतो.
पुरावे गोळा करण्यापूर्वी रचना लिहा
चार ठिकाणे DNS स्रोताबद्दल तुम्हाला काही सांगू शकतात आणि सर्व एकच सांगत नाहीत. क्लायंटचा कर्नेल कोणता स्रोत वापरेल हे जाणतो, फॉरवर्डर वर काय पाठवले हे जाणतो, भाषांतर करणारे उपकरण काय पुन्हा लिहिले हे जाणते, आणि प्राप्त करणारा रिझोल्व्हर काय पोहोचले हे जाणतो. काहीही गोळा करण्यापूर्वी यापैकी कोणापर्यंत तुम्ही प्रत्यक्षात पोहोचू शकता ते लिहा.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
तुमची अपेक्षाही लिहा, वापरात आहे असे तुम्हाला वाटणारा रिझोल्व्हर धरून. विभागलेला मार्ग क्वेरी पूर्णपणे दुसरीकडे पाठवू शकतो, आणि कॅश कोणत्याही वरच्या देवाणघेवाणीशिवाय उत्तर देऊ शकतो, म्हणून केवळ स्मृतीत ठेवलेली गृहीत धारणा पहिल्या आश्चर्यापर्यंत टिकणार नाही. जाहीर केलेली रचना आणि निरीक्षण केलेला मार्ग एकाच टिपणाच्या वेगळ्या स्तंभांत ठेवा; जेव्हा दोन्ही जुळत नाहीत, तेव्हा तुम्ही माग काढण्यासारखा प्रश्न सापडला आहे.
क्वेरी प्रत्यक्षात कोणत्या प्रक्रियेने पाठवली ते तपासा
क्लायंटपासून सुरुवात करा: रिझोल्व्हर पत्ता, क्वेरीचे नाव आणि वेळ नोंदवा, नंतर कोणत्या प्रक्रियेने ती पाठवली याची पुष्टी करा. खालील पहिली ओळ UDP सॉकेट धारण करणाऱ्या प्रक्रियेचे नाव घेते, आणि हीच ती तपासणी जिचे हे शीर्षक वचन देते. जर ती प्रक्रिया सिस्टम रिझोल्व्हरऐवजी ब्राउझर सहाय्यक किंवा कंटेनर रनटाइम असेल, तर उर्वरित माग कोणीही न मागितलेल्या मार्गाचे वर्णन करतो.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53अनेक इंटरफेस असलेल्या होस्टवर, दुसरीकडे पाहण्यापूर्वी कर्नेल त्या गंतव्यासाठी कोणता स्रोत पत्ता निवडतो ते शोधा. हा शेवटचा बिंदू आहे जिथे मार्ग पूर्णपणे तुमच्या नियंत्रणात आहे, आणि हेच ते मूल्य ज्याची तुलना तुम्ही रिझोल्व्हर ने सांगितलेल्याशी कराल. विसंगती हे लक्षण आहे की मधल्या कुठल्या तरी गोष्टीने पॅकेट पुन्हा लिहिले, किंवा दोन वेगळ्या क्वेरी पाठवल्या गेल्या.
चाचणी नावे अंतर्गत ठेवा, कारण सार्वजनिक रिझोल्व्हरला पाठवलेले अंतर्गत नाव अंतर्गत मार्गाबद्दल काहीही सिद्ध करत नाही आणि असे नाव प्रकाशित करते जे प्रकाशित करण्याची गरज नव्हती. सुरक्षित DNS सुरू असलेला ब्राउझर त्या सॉकेट यादीत अजिबात दिसणार नाही, आणि ती अनुपस्थितीच स्वतः उत्तर आहे.
फॉरवर्डर दुसरी, वेगळी क्वेरी करतो
फॉरवर्डर एक देवाणघेवाण दोन करतो. खालून विनंती येते, आणि मग फॉरवर्डर आपली क्वेरी वर पाठवतो त्या पत्त्यावरून जो तो निवडतो. त्याचे कॉन्फिगरेशन, क्लायंट नाही, हे ठरवते की वरचा रिझोल्व्हर काय पाहतो.
dnsmasq पुस्तिका याच कारणासाठी वाचनीय आहे: ती नोंदवते की फॉरवर्डर वरचे सर्व्हर कसे निवडतो आणि आपली ऐकणारी बाजू कशी बांधतो, आणि त्या रचनेत काहीही क्लायंटचा स्रोत वर घेऊन जात नाही. म्हणून गेटवे पत्ता दाखवणारा रिझोल्व्हर लॉग सामान्य आहे, बिघाडाचा पुरावा नाही. अनुपस्थितीही तितक्याच सहजपणे चुकीची वाचली जाते, कारण कॅश हिट कोणतीही वरची क्वेरी तयार करत नाही आणि कधीही न पोहोचलेल्या क्वेरीसारखीच दिसते. दोनपैकी कोणताही निष्कर्ष काढण्यापूर्वी फॉरवर्डरचे कॉन्फिगरेशन आणि त्याच्या कॅशची स्थिती वाचा. दोन प्रश्न, पाहण्यासाठी दोन ठिकाणे.
स्रोत प्राप्त करणाऱ्या रिझोल्व्हरवर वाचा
हे ठरवणारे एकमेव निरीक्षण सर्व्हरच्या बाजूला घेतले जाते. क्लायंटच्या इंटरफेस यादीतून जे काही काढले जाईल ते गृहीतच राहते जोपर्यंत रिझोल्व्हर प्रत्यक्षात काय पोहोचले ते सांगत नाही.
tcpdump -ni any port 53 and host 10.20.30.53रिझोल्व्हर होस्टवर कॅप्चर करा, कॅप्चर लहान आणि मर्यादित ठेवा, आणि ते जिथे धोरण परवानगी देते तिथे साठवा. जर निरीक्षण केलेला स्रोत भाषांतरित पत्ता असेल, तर पुढील प्रश्न हा आहे की कोणत्या उपकरणाने भाषांतर केले आणि त्याचे धोरण हेच हेतू असलेले आहे का. कॅप्चर काय पोहोचले हे सांगते; धोरणाने का परवानगी दिली हे सांगत नाही. टिपणात निरीक्षक आणि टप्पा नावाने नमूद करा, कारण गेटवेबद्दलचा गोपनीयतेचा दावा त्या टप्प्याबद्दल आहे, संपूर्ण मार्गाबद्दल नाही.
निष्कर्ष मार्ग म्हणून लिहा, पत्ता म्हणून नाही
क्लायंट, रिझोल्व्हर, कोणताही फॉरवर्डर, प्रत्येक टप्प्यावर निरीक्षण केलेला स्रोत आणि त्याला नियंत्रित करणारे धोरण नोंदवा. अशी नोंद बहुतेक भविष्यातील प्रश्नांचे उत्तर दुसऱ्या कॅप्चरशिवाय देते. ती साखळीसारखी काढा, कारण पत्त्यांची यादी लपवते की कोणत्या टप्प्याने कोणता निर्माण केला.
चित्राला तारीख, क्लायंट आवृत्ती आणि कॉन्फिगरेशनची उजळणी जोडा, जेणेकरून नंतरचा वाचक सांगू शकेल की ते अजूनही लागू आहे का. वाहतूक स्रोत सेवा जे काही प्रक्रिया करते त्यापासून वेगळा ठेवा, कारण गेटवे पत्ता पाहणे याबद्दल काहीही सांगत नाही की अजून काय साठवले जाते. रिझोल्व्हरचे स्थानही याबद्दल काहीही सांगत नाही की कोणत्या क्लायंटने विचारले. हे दावे वेगळे ठेवणेच निष्कर्षाला पुनरावलोकनात टिकाऊ बनवते.