StrongSwan აგზავნის DNS მისამართს, რომელსაც Mac ვერ აღწევს

ყველაფერი მუშაობს მანამ, სანამ ვინმე MacBook-ს გახსნის. გვირაბი დგება, შიდა ჰოსტები მისამართით პასუხობენ, და სახელების გარჩევა კვდება. iPhone-ზე იგივე პროფილი იგივენაირად იქცევა, მაშინ როცა Windows და Linux კლიენტები რიგზე არიან. ჩვეულებრივ დამნაშავე გაგზავნილი DNS ატრიბუტია: სერვერი თავის საჯარო ინტერფეისის მისამართს ავრცელებს, და Apple-ის IKEv2 კლიენტი გვირაბის გავლით იქ მოთხოვნებს არ აგზავნის. გადაიტანეთ resolver pool-ის შიგნით და სიმპტომი გაქრება კლიენტზე ხელის შეხების გარეშე.

სიმპტომი გაგზავნილ მისამართზე მიუთითებს

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

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

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

ამოჭერით resolver იჯარის დიაპაზონიდან

მიეცით გვირაბს მისამართების გეგმა, სადაც resolver pool-ის საკუთარი ქვექსელის წევრია, შემდეგ დაჯავშნეთ ეს მისამართი, რომ ის არასოდეს გაიცეს არცერთ კლიენტზე. ამ მაგალითში pool არის 10.180.7.0/24, სერვერი ინახავს 10.180.7.1-ს, და იჯარები იწყება 10.180.7.2-დან.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Pool-ის პრეფიქსი და resolver ერთ ქვექსელს იზიარებენ, ამიტომ მარშრუტი, რომელიც უკვე ატარებს გვირაბის ტრაფიკს, მოთხოვნებსაც ატარებს. სწორედ ეს ერთი თვისება ხდის გამოსწორებას კლიენტებს შორის გადატანადს. swanctl კონფიგურაციაში იგივე ორი ფაქტი ჩნდება როგორც pool-ის განსაზღვრება და DNS პარამეტრი კავშირზე, და არა ipsec.conf სინტაქსში.

სერვერს ამისთვის ახალი ფიზიკური ინტერფეისი არ სჭირდება. 10.180.7.1-ის loopback ინტერფეისზე დამატება საკმარისია, რომ resolver დაუკავშირდეს და უპასუხოს, რადგან კლიენტები მას უკვე არსებული pool-ის მარშრუტით აღწევენ. შეინახეთ მისამართი იჯარის დიაპაზონის გარეთ, რომ არცერთმა კლიენტმა შემთხვევით არ დაიკავოს ის. თუ pool-ს გარე DHCP ან RADIUS სერვისი მართავს, დაჯავშნეთ მისამართი იქაც, თორემ პირველი მკითხავი კლიენტი წაიღებს.

დაუკავშირეთ resolver და დახურეთ პორტი 53

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

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

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

შემდეგ firewall-ის წესები უნდა შეესაბამებოდეს თავად resolver-ის წვდომის კონტროლს. მიიღეთ პორტი 53 pool-იდან და ყველგან სხვაგან უარყავით, მაგრამ ჯერ ჯაჭვის რიგი შეამოწმეთ.

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

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

შეამოწმეთ, რა მიიღო კლიენტმა სინამდვილეში

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

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

პირდაპირი მოთხოვნა ამტკიცებს, რომ resolver პასუხობს pool-ის მისამართზე იმ ჰოსტიდან, რომელსაც შეუძლია მისი მიღწევა. ის არ ამტკიცებს, რომ Mac-მა სწორედ ის სერვერი აირჩია. macOS-ზე scutil --dns resolver-ებს ჩამოთვლის თითოეული შემოსაზღვრული სერვისისთვის და უფრო ინფორმაციულია, ვიდრე შემაჯამებელი პანელი; Windows-ზე Get-DnsClientServerAddress აჩვენებს, მიიღო თუ არა გვირაბის ადაპტერმა გაგზავნილი მნიშვნელობა.

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