მართლა გამოიყენება თქვენი VPN-ის DNS? დაიჭირეთ პორტი 53 და ნახეთ

ჰკითხეთ ადამიანების უმეტესობას, რას აკეთებს VPN კლიენტი DNS-თან და გეტყვიან, რომ ის აყენებს გადამწყვეტს, ამიტომ მოთხოვნები გვირაბის შიგნით მოძრაობს. მიწოლა რეალურია; ვარაუდი, რომ ის მოთხოვნად იქცევა, არა. მიწოლილ პარამეტრსა და მავთულზე არსებულ პაკეტს შორის სამი ეტაპი დგას და თითოეული დამოუკიდებლად ისე ფუჭდება, რომ ყველა გატეხილ DNS სერვერს ჰგავს. ამიტომ გაჟონვის ტესტის გვერდი და მომუშავე ბრაუზერი შეიძლება ერთსა და იმავე მომენტში ერთსა და იმავე მანქანაზე არ დაეთანხმონ.

მიწოლილი პარამეტრი მოთხოვნა არ არის

პირველი ეტაპია, რომ სერვერი სთავაზობს პარამეტრებს, მაგალითად მიწოლილ DNS პარამეტრს, რომელიც გვირაბის შიგნით გადამწყვეტს ასახელებს. მეორე ეტაპია, რომ კლიენტი ამ პარამეტრებს ინტერფეისზე იყენებს. მესამე ეტაპია, რომ პროგრამა ნამდვილად აგზავნის მოთხოვნას ამ მისამართზე. მეორე ეტაპზე მარცხი პარამეტრს კავშირის ჟურნალში ხილულად ტოვებს, სანამ გადამწყვეტების სია უცვლელი რჩება, ხოლო მესამე ეტაპზე მარცხი სრულიად სწორ გადამწყვეტების სიას გამოუყენებელს ტოვებს.

ხარვეზების ძიების უმეტესობა ამ სამს ერთში აერთიანებს და VPN სერვერს ადანაშაულებს, რომელიც ჩვეულებრივ ერთადერთი მხარეა, რომელსაც შეუძლია დაამტკიცოს, რომ თავისი წილი შეასრულა. სამაგიეროდ წაიკითხეთ კლიენტის გადამწყვეტის რეალური მდგომარეობა, შემდეგ დააკვირდით ერთი მოთხოვნის გასვლას. ეს ორი დაკვირვება გამოყოფს კონფიგურაციას მარშრუტიზაციისგან და პოლიტიკისგან, და ხარჯავს დაახლოებით ხუთ წუთს. შეინახეთ ჩანაწერები, რადგან შემდეგ ინჟინერს სურს „ადრე“ და „შემდეგ“, და არა მათი აღწერა.

შეამოწმეთ რას ინახავს ინტერფეისი სინამდვილეში

Linux-ში სისტემის გადამწყვეტი შეიძლება იყოს უბრალო ფაილი, NetworkManager ან systemd-resolved, და რომელი მათგანი ფლობს მას, განსაზღვრავს სად დაჯდება მიწოლილი სერვერი. ბრძანების ხაზის OpenVPN პროცესი სისტემის გადამწყვეტს თავისით არ აახლებს, ამიტომ დოკუმენტირებული ინტეგრაცია არის up/down სკრიპტი ან კავშირების მმართველი, რომელმაც უკვე იცის პარამეტრების გამოყენება. ორივეს გაშვება რბოლის შექმნის ეფექტური გზაა.

resolvectl status
cat /etc/resolv.conf

Windows-ში სია თითოეული ადაპტერისთვისაა, ამიტომ გვირაბის ადაპტერს შეუძლია შიდა სერვერები შეინახოს, ხოლო ფიზიკური ადაპტერი ადგილობრივებს ინახავს და ზოგიერთ სახელზე იმარჯვებს. შეადარეთ ორივე ადაპტერი და არა ის, რომელსაც აქტიურად მიიჩნევთ.

თვალყური ადევნეთ ერთ მოთხოვნას მანქანის გარეთ

ერთდროულად დაიჭირეთ ორივე ინტერფეისი, შემდეგ გადაწყვიტეთ ერთი სახელი, რომელმაც შიდა გადამწყვეტი უნდა გამოიყენოს. ეს წყვილი ჩანაწერი პასუხობს იმას, რასაც ვერც ერთი კონფიგურაციის გამონატანი ვერ უპასუხებს.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

მოთხოვნა, რომელიც ფიზიკურ ინტერფეისზე ჩნდება და გვირაბში არასდროს, ნიშნავს, რომ კლიენტმა არასწორი გადამწყვეტი აირჩია. მოთხოვნა, რომელიც არც ერთზე არ ჩნდება, ნიშნავს, რომ პროგრამამ ქეშიდან უპასუხა, loopback-ზე მოსმენილ stub-ს ჰკითხა, ან გამოიყენა დაშიფრული გადამწყვეტი, რომლის ტრაფიკი არასდროს ჩნდება როგორც პორტი 53. დაიჭირეთ პასუხებიც და არა მხოლოდ მოთხოვნები, რადგან გვირაბიდან გასული მოთხოვნა საჯარო მისამართიდან პასუხით სხვა ხარვეზია, ვიდრე პასუხის საერთოდ არმოსვლა.

ცეცხლის კედელი, რომელიც მხოლოდ საკუთარ DNS-ს იღებს

კომერციული კლიენტები ზოგჯერ საკუთარ ფილტრის ჯაჭვებს აყენებენ. ერთი დოკუმენტირებული ნიმუში უშვებს DNS-ს კლიენტის საკუთარ გადამწყვეტამდე და ყრის დანარჩენ ყველა UDP ტრაფიკს პორტზე 53, რომელიც ცდილობს არა-loopback ინტერფეისის დატოვებას, მათ შორის იმ ტრაფიკს, რომელიც მომხმარებელმა განზრახ სხვაგან გადაამისამართა. დემონის მოთხოვნები უკვალოდ ქრება, რაც იკითხება როგორც გადამწყვეტის ხარვეზი და არა ფილტრი.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

თუ გადაგდების წესი თქვენს გამონაკლისამდე ფასდება, დამატებულ წესს ვერასდროს მიაღწევს, ამიტომ ჩასვით ის პირველ პოზიციაზე და შეზღუდეთ დანიშნულება იმ გადამწყვეტით, რომელიც ნამდვილად გულისხმობთ.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

ეს გამონაკლისი დიაგნოსტიკურია და არა პოლიტიკა. თუ მომწოდებლის წესი განზრახ არის, მხარდაჭერილი შეკეთებაა კლიენტის კონფიგურირება ამ გადამწყვეტის დასაშვებად და გადაწყვეტილების ჩაწერა, რადგან ჩასმული წესი შემდეგ კლიენტის განახლებას ვერ გადაურჩება.

რატომ ამტკიცებს გაჟონვის გვერდი ნაკლებს, ვიდრე ჩანს

რასაც გაჟონვის ტესტის გვერდი აჩვენებს, ის გადამწყვეტია, რომელმაც ტესტის ოპერატორს ესაუბრა და არა ის, რომელსაც თქვენი მანქანა მიმართა. ადგილობრივი გამტარი, რომელიც გარეთ რეკურსიას აკეთებს, თავის გასასვლელ მისამართს დებს ამ გვერდზე, და დაშიფრულმა მოთხოვნებმა შეიძლება გვერდი სრულიად ცარიელი დატოვოს. ორივე შედეგი არასწორად იკითხება, ერთი როგორც გაჟონვა და მეორე როგორც გარანტია, და არც ერთი წაკითხვა დაკვირვებიდან არ გამომდინარეობს.

დასაცავი მტკიცებულება ჩანაწერია: ინტერფეისი, დანიშნულების მისამართი, პასუხი და დროის ნიშა. აიღეთ ერთი გვირაბის აწევამდე და ერთიც შემდეგ, და შეადარეთ ისინი შემდეგ ჯერზე, როცა სახელი ვერ გადაწყდება. ეს წყვილი შემდეგ ადამიანს იმასაც ეუბნება, ხარვეზი გადაწყვეტაში, მარშრუტიზაციაში თუ თავად გადამწყვეტის წვდომის პოლიტიკაში იყო.