რატომ ვერ მუშაობს პირადი DNS სახელები VPN კლიენტებზე და სად უნდა შემოწმდეს

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

ნებისმიერი პროფილის რედაქტირებამდე დაადასტურეთ, რას აკეთებს კლიენტი სახელთან. Linux-ზე resolvectl query files.corp.example გიჩვენებთ, რომელმა კავშირმა და რომელმა გადამწყვეტმა შექმნა პასუხი. Windows-ზე Resolve-DnsName files.corp.example გიჩვენებთ, რომელმა სერვერმა უპასუხა და რომელი მისამართი დააბრუნა.

წაიკითხეთ პასუხი, სანამ რამეს შეცვლით

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

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

დაარიგეთ გადამწყვეტი გვირაბის შიგნიდან

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

OpenVPN პირველ ჯგუფშია. სერვერზე push "dhcp-option DNS 10.8.0.53" და push "dhcp-option DOMAIN corp.example" საკონტროლო არხით ჩამოდის, მაგრამ მხოლოდ მაშინ, როცა კლიენტის კონფიგურაციაში pull კვლავ ჩართულია. ხელით რედაქტირებული კლიენტი, რომელსაც pull-filter ignore "dhcp-option" მიჰქონდა, ვერასოდეს დაინახავს მათ, და სწორედ ეს ერთი ხაზი ხსნის გასაოცრად ბევრ შემთხვევას, როცა «სერვერი უბიძგებს, მაგრამ ჩემი ლეპტოპი არ ეთანხმება».

WireGuard მეორე ჯგუფშია, რადგან პროტოკოლს ოპციების მოლაპარაკება საერთოდ არ აქვს. გადამწყვეტი და საძიებო დომენი კლიენტის საკუთარ [Interface] ბლოკში შედის DNS = 10.8.0.53, corp.example-ის სახით. wg-quick ამას resolvconf-ისა და systemd-resolved-ის მეშვეობით ახორციელებს, ხოლო Windows-ზე ოფიციალური კლიენტი აყენებს NRPT წესებს, რომლებიც მხოლოდ მანამ არსებობს, სანამ გვირაბი აწეულია: Get-DnsClientNrptPolicy ჩამოთვლის მათ, რაც მას სწრაფ გზად აქცევს იმის სანახავად, ოდესმე გამოიყენა თუ არა კლიენტმა თქვენი ფაილი.

IPsec/IKEv2 შუაშია. strongSwan-ის attr დანამატს შეუძლია აუზიდან აღებული DNS სერვერი დააბრუნოს, და Windows კლიენტი ჩვეულებრივ იღებს მას, მაგრამ პროფილი, რომელიც საკუთარ სახელთა სერვერს ამაგრებს, სძლევს ყველაფერს, რასაც კარიბჭე შესთავაზებს. Linux კლიენტზე ეკვივალენტური ხელით ნაბიჯია resolvectl dns wg0 10.8.0.53 და შემდეგ resolvectl domain wg0 '~corp.example'; ორივე ინტერფეისთან ერთად ქრება, რაც ზუსტად ის არის, რაც გვირაბით შეზღუდულ პარამეტრს სჭირდება.

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

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

შიგნით მხოლოდ პირადი სუფიქსი გაგზავნეთ. systemd-resolved-ში ~-ით დაწყებული დომენი მხოლოდ მარშრუტიზაციისთვისაა, ამიტომ ~corp.example ნიშნავს, რომ ამ სუფიქსის ქვეშ მოთხოვნები იმ კავშირის სერვერებზე გადადის, სანამ დანარჩენი ყველაფერი ფიზიკურ ქსელს აგრძელებს. Windows იგივეს აკეთებს სახელთა სივრცეზე შეზღუდული NRPT წესებით, ხოლო macOS /etc/resolver/-ის ქვეშ დამატებითი გადამწყვეტის ფაილით.

მულტიკასტური სახელები საკუთარ პასუხს იმსახურებენ. .local სახელები კონსტრუქციით link-local არიან (RFC 6762) და წერტილ-წერტილ tun ინტერფეისი ამ მულტიკასტურ ჯგუფს არ ატარებს, ამიტომ საჯარო გადამწყვეტის დამატება მათ არ გამოაქვეყნებს, და შიდა unicast გადამწყვეტისთვის მათ შესახებ კითხვა NXDOMAIN-ს აბრუნებს. avahi-ს მსგავს ამრეკლს ასახვის რეჟიმში შეუძლია ორი სეგმენტის დაკავშირება, მაგრამ ეს სერვერის მხარის გადაწყვეტილებაა, რომელსაც ვერც ერთი კლიენტი ვერ მოითხოვს. თუ პრინტერი ან NAS სახელით უნდა იყოს ხელმისაწვდომი, ნაცვლად ამისა მიეცით მას A ჩანაწერი თქვენს ზონაში.

დაამტკიცეთ, რომ პასუხს შეუძლია უკან დაბრუნება

მიუწვდომელ მისამართზე მიმანიშნებელი სწორი პასუხი ზუსტად გადამწყვეტის პრობლემას ჰგავს, სანამ მარშრუტს არ შეამოწმებთ. ჰკითხეთ ბირთვს, სად წავა პასუხი: ip route get 10.20.5.20 ასახელებს ინტერფეისს და, უფრო სასარგებლოდ, იმ წყაროს მისამართს, რომელსაც გამოიყენებს.

თვალყური ადევნეთ თავად გადამწყვეტის მისამართს. კლიენტი, რომლის DNS = 10.8.0.53-ის გვერდით AllowedIPs = 10.20.0.0/16 არის, მოთხოვნებს ფიზიკური NIC-ით გარეთ აგზავნის, სადაც ისინი ჩუმად იღუპება, რადგან გადამწყვეტი გვირაბის მოთხოვნილ არც ერთ პრეფიქსში არ არის. სწორედ ეს შეუთავსებლობაა ამ მთელ სფეროში ყველაზე გავრცელებული ერთმიზეზიანი ხარვეზი, და ის უხილავია, თუ DNS პარამეტრს დაშვებულ პრეფიქსებს ხაზ-ხაზ არ შეადარებთ.

გადაფარებული დიაპაზონები საპირისპირო ხარვეზს იწვევს. პასუხი სწორია, მარშრუტი არსებობს და ის არასწორ ჰოსტზე მიუთითებს, რადგან სახლში 192.168.0.0/24 უფრო კონკრეტულია, ვიდრე გვირაბის მარშრუტი იმავე დიაპაზონზე. გადანომრეთ ერთი მხარე ან გაატარეთ უფრო ვიწრო მარშრუტი, შემდეგ დაადასტურეთ სერვისის ჰოსტის firewall-ი და დაბრუნების გზა; strongSwan-ის ჩანაწერები გადაცემის შესახებ მოიცავს ამ გზის sysctl მხარეს.

სერთიფიკატები ცალკე იდენტობის შემოწმებაა, რომელსაც ადამიანები DNS-ს აბრალებენ. თუ ბრაუზერი იტყობინება სახელის შეუთავსებლობას და არა გადაწყვეტის შეცდომას, ძებნა უკვე იმუშავა და გამოსასწორებელი სერთიფიკატის SAN-ია. სცადეთ HTTPS სახელზე, არასოდეს შიშველ IP-ზე.

ხელახლა სცადეთ კლიენტიდან, და არა კარიბჭიდან

სცადეთ იმ აპლიკაციაში, რომელზეც მომხმარებელი ჩივის, რადგან ბრძანების სტრიქონიდან ძებნა არ ამტკიცებს, რომ ბრაუზერი იმავე გზას გადის. Chrome-ის უსაფრთხო DNS და Firefox-ის network.trr.mode შეიძლება სრულიად აუარონ სისტემის გადამწყვეტს, და როცა ასე ხდება, პირადი სახელი ან ვარდება, ან საჯარო გადამწყვეტზე ჟონავს. resolvectl query-ის შედარება ხელით გაშვებულ dig @10.8.0.53 files.corp.example-თან გეტყვით, რომელი მოხდა.

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

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