OpenVPN-ის DNS კარიბჭეზე: dnsmasq და ფაირვოლის ფარგლები

გაუშვით dnsmasq გვირაბის მისამართზე, დაუშვით DNS მხოლოდ კლიენტების აუზიდან, გაუშვით გამხსნელი და შემდეგ შეამოწმეთ პირდაპირი მოთხოვნები და თავად აპის ძიება.

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

მსმენელი ორმიმართულებიანი ლოკალური სერვისია

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

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

შეაკავეთ გვირაბის მისამართი და არა ყველა მისამართი

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

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic აკავშირებს ცალკეულ მისამართებს და უმკლავდება, როცა tun0 მოგვიანებით ჩნდება, რაც მნიშვნელოვანია ჰოსტზე, სადაც VPN სერვისი გადაიტვირთება. loopback-ის ჩამოთვლა ლოკალურ ინსტრუმენტებს მუშა მდგომარეობაში ინახავს საჯარო მსმენელის დამატების გარეშე. no-resolv ხელს უშლის დემონს ჰოსტის გამხსნელის კონფიგურაციიდან ზემო დინების მემკვიდრეობით მიღებაში, ხოლო no-hosts ხელს უშლის ამ ეგზემპლარს კარიბჭის hosts ფაილის გამოქვეყნებაში. ამ არც ერთი ვარიანტი არავის აძლევს სერვისზე მოთხოვნის ნებართვას.

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

დაუშვით DNS-ის შემავალი, და არა გვირაბის ტრანზიტი

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

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

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

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

ზემო დინების ნახევარი ცალკე გზაა

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

ნუ დაამატებთ შეუზღუდავ გვირაბის გამავალს პასუხების გასამუშავებლად; თვალთვალის ქვეშ მყოფ პასუხებს ეს არ სჭირდებათ.

გაუშვით ოფცია, შემდეგ შეამოწმეთ გადაცემა

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

push "dhcp-option DNS 10.90.0.1"

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

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

შეამოწმეთ ის, რაც ნამდვილად ააშენეთ

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

თუ პირდაპირი მოთხოვნები მუშაობს და აპი მაინც ფუჭდება, გაუმართაობა გადაცემაშია და არა სერვერზე:

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

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

დაკავშირებული სტატიები