რატომ გადის dnsmasq-ის მოთხოვნები VPN-ს გარეთ DNS გადამისამართების შემდეგ

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

ნიშანი მოთხოვნასთან ერთად არ მოგზაურობს

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

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

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

სად იქცევა გადამისამართება ლოკალურ გადაწყვეტად

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

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

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

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

მიეცით რეზოლვერს საკუთარი გასასვლელი პოლიტიკა

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

server=/corp.example/10.30.0.53@tun_work
log-queries

ზემოთ მოცემული დომენი, მისამართი და ინტერფეისი თქვენი მნიშვნელობების ჩანაცვლებებია. დომენის არჩევა და გასასვლელის კონტროლი ცალკე გადაწყვეტილებად რჩება: მარშრუტი უნდა არსებობდეს, წყაროს მისამართი ზედა რეზოლვერმა უნდა დაუშვას და firewall-მა პასუხი უნდა დაუშვას. მხოლოდ ინტერფეისით მიმართვა fail-closed არ არის, რადგან გაქრობილმა გვირაბმა რეზოლვერი შეიძლება სხვა გზაზე დაეცეს. ნებისმიერი საჯარო სარეზერვო გზა შორს დაიჭირეთ იმ სახელთა სივრცისგან, რომელიც კერძო უნდა დარჩეს.

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

რასაც საერთო ქეში ვერ შეინარჩუნებს

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

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

53-ე პორტის წესები არაფერს ამბობს იმ აპლიკაციებზე, რომლებიც DNS-ს HTTPS-ზე ან TLS-ზე საუბრობენ. ეს მოთხოვნები გადამისამართებას არასოდეს აღწევს, ამიტომ მხოლოდ 53-ე პორტზე აგებული პოლიტიკა ტრაფიკის ქვესიმრავლეს აღწერს და ქვესიმრავლედ უნდა იქნას დოკუმენტირებული.

შეამოწმეთ მეორე საუბარი და არა პირველი

გამოსცადეთ ერთი სახელით, რომელსაც თქვენ აკონტროლებთ, და დააკვირდით ორივე მხარეს. კლიენტის მხრიდან ჩაწერა ამტკიცებს, რომ მოთხოვნამ LAN დატოვა; მხოლოდ როუტერის მხარე ამტკიცებს, სად წავიდა იგი შემდეგ.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

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