მიეცით თქვენს სახლის VPN-ს საკუთარი DNS ჩანაწერები nas.home.arpa-სთვის
გამოაქვეყნეთ ერთი სახელი dnsmasq-იდან, მარშრუტიზაცია გაუკეთეთ resolver-ს WireGuard-ის გავლით, შემდეგ აირჩიეთ მთელი კლიენტისთვის DNS-ის გაგზავნასა და მხოლოდ home.arpa-სთვის split-DNS-ს შორის.
როდესაც გვირაბი აწეულია, ბოლო ნაბიჯი, როგორც წესი, არის სახელი, რომელიც მუშაობს იმ მისამართის ნაცვლად, რომელსაც სანიშნეში აკრავთ. dnsmasq-ის ჰოსტის ჩანაწერი და resolver-ის მისამართი, რომელზეც კლიენტი აღწევს, ამას აკეთებს ორი ფაილით და multicast-ის გარეშე. გადაწყვეტილება, რომელიც ნამდვილად ფიქრს მოითხოვს, უფრო ვიწროა: აგზავნის კლიენტი მთელ DNS-ს სახლის resolver-ის გავლით, თუ მხოლოდ home.arpa-ის ქვეშ არსებულ სახელებს? ყველაფერი ქვემოთ გულისხმობს დამტკიცებულ WireGuard-ის კონფიგურაციას Linux კლიენტით და ლაბორატორიული resolver-ით, რომელსაც სახლის ადმინისტრატორი უკვე მართავს.
კლიენტისთვის resolver-ის მიცემის სამი გზა
| Approach | Scope | Cost |
|---|---|---|
DNS = in the wg-quick interface | the client's general DNS while the tunnel is up | every name in the house now depends on the tunnel |
Platform split-DNS for home.arpa | only that suffix | more configuration per client platform |
Manual dig @resolver | one query at a time | fine for testing, useless for applications |
ლეპტოპისთვის, რომელიც გვირაბს დროდადრო უერთდება, split-DNS უკეთესი ნაგულისხმევია: ის ჩვეულებრივ ინტერნეტ სახელებს ინახავს იმ resolver-ზე, რომელსაც მანქანა უკვე ენდობა. მანქანისთვის, რომელიც არსებობს სახლის სერვისებზე მისასვლელად, resolver-ის გაგზავნა უფრო მარტივია და მოცულობის ფასს მნიშვნელობა არ აქვს.
გამოაქვეყნეთ ჩანაწერი resolver-ზე, რომელიც ფლობს ზონას
კონფიგურაციის დაწერამდე როლები გამოყავით: VPN კლიენტის მისამართი, resolver და სერვისი სამი განსხვავებული ჰოსტია სამი განსხვავებული სამუშაოთი. ამ ლაბორატორიაში ისინი არიან 10.77.0.2 კლიენტისთვის, 192.168.50.53 dnsmasq-ისთვის და 192.168.50.20 NAS-ისთვის, ხოლო გვირაბი მარშრუტიზაციას უკეთებს სახლის LAN-ს.
listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20host-record ხაზი მისამართს აძლევს, ხოლო local= ხაზი უცნობ home.arpa კითხვებს ამ resolver-ის შიგნით ინახავს ზემოთ გაგზავნის ნაცვლად. ჯერ წაიკითხეთ თქვენი არსებული კონფიგურაცია და შეათანხმეთ ყველაფერი, რაც უკვე განსაზღვრავს სერვერს, ინტერფეისს ან იმავე ლოკალურ დომენს; წინააღმდეგობრივზე ფრაგმენტის დაწყობა ქმნის resolver-ს, რომელიც სიხარულით იტვირთება და არასწორად პასუხობს. dnsmasq-ის სახელმძღვანელო განსაზღვრავს ორივე დირექტივას და მოსმენის კონტროლს.
შემდეგ შეამოწმეთ მომუშავე სერვისი და არა ფაილი. კონფიგურაციის ტესტი და გადატვირთვა მინიმუმია, ხოლო ეფექტური პასუხი არის ის, რასაც მოთხოვნა აბრუნებს.
მარშრუტიზაცია გაუკეთეთ resolver-ს და არა მხოლოდ ვებ გვერდს
WireGuard-ის AllowedIPs განსაზღვრავს, რომელი დანიშნულებები შედის გვირაბში. თუ resolver-ის მისამართი მის გარეთ რჩება, მოთხოვნა ჩვეულებრივი მარშრუტით გადის და dnsmasq-ს არასოდეს აღწევს, მიუხედავად იმისა, რომ თავად NAS ხელმისაწვდომია. ჩართეთ resolver-ის მისამართი ან მისი შემცველი LAN პრეფიქსი და შეამოწმეთ კარიბჭის გადაცემის პოლიტიკა მეორე მხარეს.
დაუშვით UDP და TCP 53 პორტზე უფლებამოსილი გვირაბის დიაპაზონიდან, დაბრუნების გზით კლიენტის გვირაბის მისამართამდე. ნუ გადასცემთ 53 პორტს WAN-იდან ტესტირების გასაადვილებლად: ღია რეკურსიული resolver სახლის კავშირზე საათებში იპოვება. ინტერფეისზე მიბმა თავისთავად წვდომის პოლიტიკა არ არის.
შეამოწმეთ პასუხი აპლიკაციამდე
ჯერ ჰკითხეთ resolver-ს პირდაპირ, შემდეგ სისტემას, შემდეგ აპლიკაციას. თითოეული ნაბიჯი ჯაჭვის ერთ რგოლს იზოლირებს და მათ შორის სხვაობა დიაგნოზია.
dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'ღირს TCP მოთხოვნის გაშვება, რადგან შეწყვეტილი UDP პასუხი ხელახლა ცდას აიძულებს, ხოლო TCP 53-ის გადაგდების პოლიტიკა ქმნის ხარვეზებს, რომლებიც შეწყვეტილად გამოიყურება. getent ნაბიჯი აჩვენებს, რას აკეთებს სინამდვილეში მანქანის resolver კონფიგურაცია, რაც ყოველთვის არ არის ის, რაც თქვენ გაგზავნეთ.
გადაწყვიტეთ რა ხდება, როცა გვირაბი ჩამოშვებულია
თუ კლიენტის ზოგადი DNS მიუთითებს 192.168.50.53-ზე, ნებისმიერი სახელის გარჩევა წყვეტს მუშაობას, როცა გვირაბი არ არის აწეული. ეს მისაღებია მანქანაზე, რომელიც მხოლოდ გვირაბითაა გამოსადეგი, და მიუღებელია ლეპტოპზე, რომელიც ასევე იყენებს კაფეს Wi-Fi-ს. Split-DNS მთლიანად თავიდან იცილებს კითხვას, რადგან მხოლოდ home.arpa ძიებებია დამოკიდებული სახლის resolver-ზე.
გახსოვდეთ რა არის სახელი: home.arpa დაცულია საცხოვრებელი ქსელებისთვის და არ არის გლობალურად უნიკალური, ამიტომ სხვა ქსელს შეუძლია ლეგიტიმურად გამოიყენოს იგივე სახელი. ეს ლოკალური მოხერხებულობაა და არა სანდო იდენტიფიკატორი. შეინახეთ ჩანაწერი განახლებული, როცა სერვისი გადადის, და წაშალეთ resolver-ის პოლიტიკა, როცა ლაბორატორია გამოდის ექსპლუატაციიდან, იმის ნაცვლად, რომ დატოვოთ ლეპტოპი, რომელიც მიუთითებს მისამართზე, რომელზეც ის მხოლოდ აღარ არსებული გვირაბის გავლით აღწევს.