ვინ მართავს 1.1.1.1-ს? DNS მისამართის შემოწმება ნდობამდე
VPN-თან ერთად გამოყენებულ DNS მისამართს სულაც არ მართავს ის VPN. დაადგინეთ გამხსნელი, შემდეგ ცალკე შეამოწმეთ მარშრუტი და კერძო სახელების პოლიტიკა.
ჩასვით 1.1.1.1 VPN-ის DNS ველში, გვერდი ჩაიტვირთა და გზამკვლევი ახლა დადასტურებულად გამოიყურება. ეს დაკვირვება უფრო ვიწროა, ვიდრე ჩანს: აპლიკაცია სხვანაირად მოიქცა და ცვლილება ჯერ არაფერს ამბობს იმაზე, თუ ვინ უპასუხა მოთხოვნას ან რატომ ჩავარდა ძველი წყობა. კოპირებული გზამკვლევი ხშირად უწოდებს ცნობილ საჯარო მისამართს „VPN-ის DNS-ს“, და ეს საკუთრების შესახებ განაცხადია და არა ხელმისაწვდომობის. იმის შემოწმებას, რას წარმოადგენს მისამართი, ხუთი წუთი სჭირდება და თავიდან გვაშორებს არასწორი მიზეზით გაკეთებულ მუდმივ ცვლილებას.
მოქმედი პარამეტრი იდენტობა არ არის
მისამართი პარამეტრების ველში არის ბოლო წერტილი, ხოლო ბოლო წერტილს ჰყავს ოპერატორი. ეს ორი ფაქტი განცალკევებულია და მეორეა ის, რომელსაც ხალხი გამოტოვებს. ყველაზე ხშირად კოპირებული წყვილისთვის პასუხი საჯაროა: Cloudflare აქვეყნებს 1.1.1.1 და 1.0.0.1 როგორც თავისი გამხსნელის მისამართებს და ჩამოთვლის მათ თავის ოფიციალურ მისამართების ცნობარში. ამიტომ ოპერატორის სახელი მისამართის გვერდით უნდა იყოს და არა ცალკე გზამკვლევში.
ამ წყვილის შეყვანა მაშინ, როცა გვირაბი აქტიურია, VPN კომპანიას მის ოპერატორად არ აქცევს და ტრაფიკს ანონიმურს არ ხდის. მოთხოვნა თქვენი მანქანიდან მიდის კომპანიასთან, რომელიც აქვეყნებს მისამართების დიაპაზონს, და ეს კომპანია შეიძლება სანდო იყოს და მაინც არ იყოს ის მხარე, რომელიც გზამკვლევმა მოიგულა. ინსტრუქციებში არსებული ნიშანი და რეალური ოპერატორი განსხვავებული განაცხადებია. არც ერთი არ ამბობს, ვინ მართავს მათ შორის არსებულ ქსელურ მარშრუტს.
გამოიყენეთ თავად გამხსნელის გამოქვეყნებული ცნობარი მისამართების წყვილის ან დაშიფრული ბოლო წერტილის დასადასტურებლად. სხვა მომწოდებლის რეკომენდაცია შეიძლება ლეგიტიმური იყოს, და „რეკომენდებული“, „მიღწეული“ და „მართული“ კვლავ სამ განსხვავებულ კავშირს აღწერს.
შეადარეთ სამი რამ, რაც ჩანაწერს სჭირდება
განხილვისთვის მზა ჩანაწერი ყოფს სამ კითხვას: ვინ უნდა მიიღოს მოთხოვნა, ღიაა თუ დაშიფრული გაცვლა და რომელმა მარშრუტმა უნდა გადაიტანოს იგი. მომწოდებლის სახელი ვერ შეავსებს მეორეს ან მესამეს, და ქვეყნის ნიშანი ვერცერთს ვერ შეავსებს. ჩაწერეთ სამი ჩანაწერი ცვლილებამდე და შეადარეთ შემდეგ. ეს ჩანაწერები ურთიერთშემცვლელი არ არის, და მათი ერთად მოპყრობა ის გზაა, რომლითაც ვარაუდი დოკუმენტაციად იქცევა.
შედარებაა ის, რაც მოქმედ პარამეტრს დოკუმენტირებულ გადაწყვეტილებად აქცევს. მის გარეშე შემდეგი ადამიანი მემკვიდრეობით იღებს მისამართს ყოველგვარი მიზეზის გარეშე. ჯერ წაიკითხეთ ქვემოთ მოცემული ცხრილის მესამე სვეტი, რადგან სწორედ იქ ჩერდება სინამდვილეში თავდაჯერებული ახსნების უმეტესობა.
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
ცხრილი განზრახ მოკლეა. მისი აზრი ისაა, რომ თითოეული ჩანაწერი სხვა კითხვას პასუხობს და არც ერთი ველი არ ავსებს სამივეს.
ადგილობრივი გადამამისამართებელი მალავს ნამდვილ წყაროს
მოწყობილობა, რომელიც DNS-ად თავის როუტერს იყენებს, გადამამისამართებელზე მიუთითებს. ეს მისამართი მოთხოვნის შემდეგ მიმღებს განსაზღვრავს და არა გამხსნელს, რომელიც მას საბოლოოდ უპასუხებს. ადგილობრივი stub გამხსნელი იმავე დამატებით ნაბიჯს ამატებს, და ადვილია მისი რეალურ რამესთან აღრევა, რადგან ყველა სტატუსის გამოსავალში ჩანს.
Stub გადასცემს იმ წყაროებს, რომლებსაც იგივე გამოსავალი ასევე ჩამოთვლის, ჩვეულებრივ უფრო ქვემოთ. წაიკითხეთ მთელი ჯაჭვი, სანამ ოპერატორზე რაიმეს დაასკვნით, რადგან პირველი ხაზი მთელი პასუხი არ არის. წინააღმდეგ შემთხვევაში მისაღებს კომპანიად უწოდებთ.
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'მეორე ბრძანება იყენებს გამხსნელის ექო-სახელს, სადაც ოპერატორი აქვეყნებს მას, რომ მიუთითოს თავის მიერ დანახული წყაროს მისამართი. მესამე ასახელებს სერვერს, რომელმაც უპასუხა, და ეს ხშირად არ არის ის მისამართი, რომელიც თქვენ დააკონფიგურირეთ. შეადარეთ სამივე გამოსავალი, სანამ ოპერატორს ჩაწერთ.
დაშიფრული DNS ცვლის იმას, რაც ჩანს და არა იმას, ვინ ხედავს
DNS over HTTPS და DNS over TLS იცავს კლიენტსა და გამხსნელს შორის გაცვლას. გამხსნელი კვლავ კითხულობს ყველა სახელს, რომელზეც კითხულობენ, რადგან პასუხი მისი საქმეა. იცვლება ის, თუ ვის შეუძლია გაცვლის დაკვირვება: ადგილობრივი ქსელი ხედავს კავშირს ერთ ბოლო წერტილთან და არა ღია ტექსტური მოთხოვნების ნაკადს.
რაც არ იცვლება, არის ნდობის ურთიერთობა, რომელიც კვლავ იმ ორგანიზაციაზე მიუთითებს, რომელიც ამ ბოლო წერტილს მართავს. ბრაუზერს, რომელსაც საკუთარი უსაფრთხო DNS პარამეტრი აქვს, შეუძლია ოპერაციული სისტემის გამხსნელი სრულად გვერდის ავლით. მოეპყარით მათ როგორც ორ კონფიგურაციას, რომლებიც შეიძლება არ დაემთხვეს, და არა როგორც ერთ პარამეტრს, რომელიც ორჯერ გამოიყენება.
კერძო სახელებს კვლავ საკუთარი გადაწყვეტილება სჭირდება. სამუშაო გვირაბმა შეიძლება შერჩეული დომენები ორგანიზაციის გამხსნელებზე გადაამისამართოს, და ამის საჯარო სერვისით ჩანაცვლებამ შეიძლება შიდა ძიებები გატეხოს ან შიდა სახელები არასწორ მხარეს გაუმჟღავნოს. შეამოწმეთ დომენების პოლიტიკა, სანამ მთელი ადაპტერის პარამეტრებს ჩაანაცვლებთ.
შეინარჩუნეთ დაკვირვება ვიწროდ
როცა ადარებთ, შეინახეთ ძველი კონფიგურაცია და ერთდროულად ერთი პარამეტრი შეცვალეთ. ჩაწერეთ აპლიკაცია, ოპერაცია, გამხსნელის პოლიტიკა და ის, გადაიჭრება თუ არა საჯარო და დაშვებული კერძო სახელები ხელახალი დაკავშირების შემდეგ. ორი ცვლილების მქონე შედარება არც ერთს არ ამტკიცებს. ჩაწერეთ შედეგი იქ, სადაც შემდეგი ადამიანი იპოვის, თავად პარამეტრის გვერდით.
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comთუ აპლიკაცია მუშაობას დაიწყებს, შეინარჩუნეთ განაცხადი იმდენად მცირე, რამდენსაც მტკიცებულებები დაუშვებენ. ამ ცვლილებამ ერთ ტესტს დაეხმარა და არაფერს ამბობს იმაზე, მოქმედებდა თუ არა წინა გამხსნელი ცუდი განზრახვით, გატეხილი იყო თუ არა გვირაბი ან სჭირდება თუ არა სხვა მოწყობილობას იგივე ჩანაცვლება. ხანგრძლივი შედეგი კონფიგურაციაა, რომლის ოპერატორიც და დანიშნულებაც ახსნა გქონდეთ.