वास्तविक स्रोत पत्ता लगाउन 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रिजोल्भर होस्टमा क्याप्चर गर्नुहोस्, क्याप्चर छोटो र सीमित राख्नुहोस्, र नीतिले अनुमति दिने ठाउँमा भण्डारण गर्नुहोस्। यदि अवलोकन गरिएको स्रोत अनुवादित ठेगाना हो भने, अर्को प्रश्न कुन यन्त्रले अनुवाद गर्यो र त्यसको नीति नै अभिप्रेत हो कि होइन भन्ने हो। क्याप्चरले के पुग्यो भन्ने जवाफ दिन्छ; नीतिले किन अनुमति दियो भन्ने व्याख्या गर्दैन। टिप्पणीमा पर्यवेक्षक र चरणको नाम लिनुहोस्, किनकि गेटवेबारे गोपनीयताको दाबी त्यो चरणबारे हो, सम्पूर्ण मार्गबारे होइन।
निष्कर्षलाई मार्गको रूपमा लेख्नुहोस्, ठेगानाको रूपमा होइन
ग्राहक, रिजोल्भर, कुनै पनि फर्वार्डर, प्रत्येक चरणमा अवलोकन गरिएको स्रोत र त्यसलाई नियन्त्रण गर्ने नीति लेख्नुहोस्। त्यस्तो अभिलेखले धेरै भावी प्रश्नको जवाफ अर्को क्याप्चरबिना दिन्छ। यसलाई साङ्लोको रूपमा कोर्नुहोस्, किनकि ठेगानाको सूचीले कुन चरणले कुन उत्पादन गर्यो लुकाउँछ।
चित्रमा मिति, ग्राहक संस्करण र कन्फिगरेसनको संशोधन जोड्नुहोस्, ताकि पछिको पाठकले यो अझै लागू छ कि छैन भन्न सकोस्। यातायात स्रोतलाई सेवाले प्रशोधन गर्ने अरू सबैबाट अलग राख्नुहोस्, किनकि गेटवे ठेगाना देख्नुले अरू के भण्डारण गरिन्छ भन्नेबारे केही भन्दैन। रिजोल्भर को स्थानले पनि कुन ग्राहकले सोध्यो भन्नेबारे केही भन्दैन। यी दाबीहरू अलग राख्नुले नै निष्कर्षलाई समीक्षामा टिकाउ बनाउँछ।