მიჰყევით 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ჩაწერეთ რეზოლვერის ჰოსტზე, შეინახეთ ჩანაწერი მოკლე და შეზღუდული, და შეინახეთ იქ, სადაც პოლიტიკა იძლევა საშუალებას. თუ დაკვირვებული წყარო თარგმნილი მისამართია, შემდეგი კითხვაა, რომელმა მოწყობილობამ შეასრულა თარგმნა და არის თუ არა მისი პოლიტიკა განზრახული. ჩანაწერი პასუხობს, რა ჩამოვიდა; ის არ ხსნის, რატომ დაუშვა პოლიტიკამ. დაასახელეთ დამკვირვებელი და ნაბიჯი ჩანაწერში, რადგან შესასვლელის შესახებ კონფიდენციალურობის მტკიცება ამ ნაბიჯზეა და არა მთელ გზაზე.
ჩაწერეთ აღმოჩენა გზად, და არა მისამართად
ჩაწერეთ კლიენტი, რეზოლვერი, ნებისმიერი გამტარებელი, თითოეულ ნაბიჯზე დაკვირვებული წყარო და პოლიტიკა, რომელიც მას მართავს. ასეთი ჩანაწერი პასუხობს მომავალი კითხვების უმეტესობას ახალი ჩანაწერის გარეშე. დახაზეთ ის ჯაჭვად, რადგან მისამართების სია მალავს, რომელმა ნაბიჯმა რომელი შექმნა.
დაურთეთ ნახაზს თარიღი, კლიენტის ვერსია და კონფიგურაციის რევიზია, რათა გვიანდელმა მკითხველმა თქვას, ძალაშია თუ არა ის ჯერ კიდევ. გამოყავით ტრანსპორტის წყარო ყველაფრისგან, რასაც სერვისი ამუშავებს, რადგან შესასვლელის მისამართის დანახვა არაფერს ამბობს იმაზე, კიდევ რა ინახება. არც რეზოლვერის მდებარეობა ამბობს რამეს იმაზე, რომელმა კლიენტმა იკითხა. სწორედ ამ მტკიცებების განცალკევება ხდის დასკვნას დასაცავს მიმოხილვაში.