DNS რეზოლვერის ჟურნალები VPN კავშირის ჟურნალების წინააღმდეგ: რას ინახავს თითოეული
რეზოლვერი იწერს სახელებს, რომლებზეც პასუხის გაცემა სთხოვეს; VPN კი თავისი იმპლემენტაციიდან იწერს გვირაბის მოვლენებს. ერთი შენახვის პოლიტიკა მეორეს არ ფარავს.
DNS რეზოლვერის ჟურნალი და VPN კავშირის ჟურნალი ორივე ქსელური ჩანაწერია, ორივე სასარგებლო და არც ერთი მეორით არ იცვლება. რეზოლვერი იღებს სახელებს, რომლებზეც პასუხის გაცემა სთხოვეს. VPN-ის ბოლო წერტილი უმკლავდება გვირაბის კავშირებს და იწერს იმას, რისი ჩაწერაც მისმა იმპლემენტაციამ ამოირჩია. ისინი შეიძლება იყოს ერთ შენობაში, მართავდეს ერთი გუნდი და მოქცეული იყოს ერთი კონფიდენციალურობის შეტყობინებით, მაგრამ მაინც სხვადასხვა მოვლენას აღწერენ სხვადასხვა იდენტიფიკატორითა და სხვადასხვა შენახვით. ერთის მეორედ წაკითხვა იმ გზაა, რომლითაც გამოძიებები იხრება.
ორი ჟურნალი, ორი მოვლენა
რეზოლვერის ჩანაწერი პასუხობს სახელდების შესახებ კითხვას: ამ კლიენტმა ამ დროს ეს სახელი მოითხოვა და პასუხი ეს იყო. VPN-ის ჩანაწერი პასუხობს კავშირიანობის შესახებ კითხვას: ამ პირმა დაამყარა ან დაკარგა გვირაბი, მას მიენიჭა ეს მისამართი და გადასცა დაახლოებით ამდენი მონაცემი სანამ გაქრა. არც ერთი არ არის ჩანაწერი იმისა, თუ რა გააკეთა მომხმარებელმა HTTPS სესიის შიგნით, და არც ერთი არ ცვლის მეორეს.
ამ განსხვავებას პრაქტიკული შედეგი აქვს დაპირებებისთვის. მტკიცება, რომ VPN მომწოდებელი არ იწერს გვირაბის აქტივობას, არაფერს ამბობს იმ რეზოლვერზე, რომელსაც ის გასცემს, ხოლო რეზოლვერის შენახვის პოლიტიკა არაფერს ამბობს იმაზე, თუ ვინ დაუკავშირდა გვირაბს. ყოველი მტკიცება ეკუთვნის თავის ოპერატორს და თავის სისტემას.
მიჰყევით მოთხოვნას, სანამ რომელიმე ჟურნალს წაიკითხავთ
მოთხოვნა რეზოლვერამდე აღწევს მხოლოდ მაშინ, როცა გზა ნამდვილად ეკითხება მას. აპლიკაციამ შეიძლება გამოიყენოს ოპერაციული სისტემის რეზოლვერი, გაუშვას საკუთარი დაშიფრული DNS კლიენტი, ან წაიკითხოს ქეშირებული პასუხი და არასოდეს გააგზავნოს არაფერი. ამიტომ რეზოლვერის ჟურნალი, რომელიც არაფერს აჩვენებს, არ არის მტკიცებულება იმისა, რომ სახელი არასოდეს გამოუყენებიათ; ეს არის მტკიცებულება იმისა, რომ ამ რეზოლვერს არ ჰკითხეს.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerეს უკანასკნელი ბრძანება კითხულობს ლოკალური რეზოლვერის საკუთარ ჟურნალს, რაც არ არის იგივე, რაც ზედა სერვერის ჟურნალი. თუ თქვენი მოთხოვნები გადის DNS over HTTPS-ით მომწოდებელთან, ლოკალურმა stub-მა შეიძლება არაფერი აჩვენოს, სანამ მომწოდებელს აქვს სრული ჩანაწერი, და მომწოდებელი სხვა ოპერატორია სხვა პოლიტიკით.
რა შეიძლება და რა არ შეიძლება აჩვენოს თითოეულმა ჩანაწერმა
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
მათი დაკავშირება ნამდვილი სამუშაოა და დაკავშირება ყოველთვის შესაძლებელი არ არის. რეზოლვერი, რომელიც იწერს კლიენტების მისამართებს, შეიძლება შევადაროთ VPN-ს, რომელიც მისამართებს ანაწილებს ცნობილი აუზიდან, და ეს შედარება ქმნის დამაჯერებელ კავშირს მოთხოვნილ სახელსა და გვირაბს შორის, რომელიც რჩება კავშირად ორ ჩანაწერს შორის და არა პიროვნების ჩანაწერად.
დაშიფრული DNS ცვლის ტრანსპორტს და არა ხილვადობას ბოლო წერტილში. რეზოლვერი კვლავ იღებს კითხვას, რომელზეც პასუხობს, როგორც RFC 8484 განმარტავს, და ამ რეზოლვერში შენახვა პოლიტიკის გადაწყვეტილებაა და არა პროტოკოლის თვისება.
სად ირევა გაყოფილი DNS და ქეშები
რამდენიმე რეზოლვერი ნორმაა. გაყოფილი DNS-ის დიზაინი შიდა სახელებს აგზავნის შიდა სერვერზე, დანარჩენს კი საჯაროზე, ასე რომ ერთი გამოძიება შეიძლება მოიცავდეს ორ ჟურნალს, რომლებიც არასოდეს ყოფილა განკუთვნილი გაერთიანებისთვის და ორ შენახვის პარამეტრს, რომლებიც არასოდეს ყოფილა განკუთვნილი შედარებისთვის. ორივეში მოთხოვნების დანახვა იმის მტკიცებულებაა, რომ დიზაინი მუშაობს, და არა გაჟონვის მტკიცებულება.
ქეშები საპირისპირო მიმართულებით ჭრიან. პოპულარულ სახელზე შეიძლება საათობით პასუხობდეს ქეშიდან, ამიტომ რეზოლვერის ჩანაწერი აჩვენებს პირველ მოთხოვნას და შემდეგ არაფერს, სანამ მომხმარებლის აპლიკაცია სიამოვნებით აგრძელებს იმავე სახელის ამოხსნას. გარკვეული დროის შემდეგ ჩანაწერების არარსებობა არ ნიშნავს, რომ ამ დროის შემდეგ სახელი არავის გამოუყენებია.
ფონური ტრაფიკი მესამე დამახინჯებაა. ტელეფონი, რომელიც ჩართვისას ხსნის ტელემეტრიის სახელს, ბრაუზერი, რომელიც ხსნის ძიების შეთავაზების დომენს, და განახლების პროგრამა, რომელიც ყოველ საათში აკავშირებს, ყველა ჩნდება რეზოლვერის ჟურნალში იმ სახელის გვერდით, რომელიც ნამდვილად გაღელვებთ. ამ ჟურნალში მოცულობა ყურადღება არ არის და მოთხოვნების დათვლა ვიზიტების დათვლა არ არის. რეზოლვერის ჟურნალი კითხვების ჩანაწერია და კითხვების შექმნა იაფია.
შენახვის კითხვები ცალ-ცალკე დასვით
თითოეული სისტემისთვის დასვით სამი კითხვა: ვინ აგროვებს, რა გროვდება და რამდენ ხანს ინახება ის. შემდეგ იკითხეთ ვის შეუძლია მისი წაკითხვა და რა პროცესით. RFC 8484-ის განხილვა DNS over HTTPS-ზე კარგი შეხსენებაა, რომ დაშიფრული ტრანსპორტი არ აშორებს ბოლო წერტილს, და ოპერატორის საკუთარი დოკუმენტაცია ერთადერთი სანდო განაცხადია იმაზე, თუ რას ინახავს ეს ბოლო წერტილი.
როცა კონფიდენციალურობის შესახებ მტკიცება „VPN“-ზე კეთდება, მის მიღებამდე დაშალეთ კომპონენტებად: გვირაბის ოპერატორი, რეზოლვერი, რომელსაც გვირაბი გასცემს, ნებისმიერი ზედა რეზოლვერი, რომელსაც ეს მოთხოვნები აღწევს, და მოწყობილობაზე არსებული აპლიკაციები. თითოეულს თავისი პასუხი აქვს და მტკიცება, რომელიც ერთისთვის ზუსტია, ჩვეულებრივ მეორდება ისე, თითქოს ოთხივეს ფარავდეს.
ხარვეზების მოძიებისთვის გამოიყენეთ იგივე დაყოფა. იკითხეთ რომელმა აპლიკაციამ შეასრულა მოთხოვნა და რომელმა რეზოლვერმა უპასუხა, შემდეგ შეხედეთ ჟურნალს, რომელიც ნამდვილად ფლობს ამ მოვლენას. სხვა ჟურნალიდან გამოცნობა წუთს ზოგავს და ნახევარ დღეს ხარჯავს.