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

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

ორი გაცვლა ერთი და იგივე გაცვლა არ არის

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

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

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

უმდგომარეობო კიდე და მდგომარეობის მქონე ჰოსტის ფაირვოლი

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

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

ნებართვა ააგეთ პროტოკოლის გარშემო და არა პორტის ნომრის

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

შემდეგ დაადასტურეთ, თუ რომელი პროდუქტი ფილტრავს ტრაფიკს რეალურად ბილიკზე. დოკუმენტირებული IPv4 კიდის არე არ ადგენს IPv6 პოლიტიკას და პროვაიდერის შიდა ტრაფიკი შესაძლოა არასოდეს გაიაროს იმავე ფილტრში.

რატომ არ არის გამოსწორება ნებისმიერი წყარო პორტის 53 დაშვება

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

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

შეამოწმეთ სწორ საზღვარზე, სწორი მიმართულებით

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

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