OpenWrt პოლიტიკური მარშრუტიზაცია: ჯაჭვი, რომელიც ლოკალურ DNS-ს იჭერს

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

ორი ნაკადი, ერთი ამომხსნელის მისამართი

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

მეორე ნაკადი არასდროს არსადიდან არ მოდის. როუტერი ქმნის მას, ამიტომ არც შემომავალი პაკეტია და არც შესადარებელი გადაგზავნის ნაბიჯი.

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

გადაგზავნილი და ლოკალურად შექმნილი პაკეტები სხვანაირად შედიან

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

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

ეს იმის თვისებაა, სად იბადებიან პაკეტები, და არა რომელიმე კონკრეტული პაკეტის. ერთი ჯაჭვისთვის დაწერილ წესს უბრალოდ არ აქვს აზრი მეორეზე. წესების ვერც ერთი დაყენება ამას არ ცვლის.

აირჩიეთ გამოსვლის ჯაჭვი, შემდეგ შეავიწროეთ დამთხვევა

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

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

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

გვირაბის საკუთარი ტრანსპორტი წესის გარეთ დატოვეთ

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

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

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

შეამოწმეთ ორივე პოპულაცია, არა ერთი

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

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

შეამოწმეთ პორტიც: წესი, რომელიც დანიშნულების პორტ 53-ს ემთხვევა, გამოტოვებს ამომხსნელს, რომელსაც 853-ზე DNS over TLS-ით ან HTTPS საბოლოო წერტილით აღწევენ. შეესაბამეთ იმ ტრანსპორტს, რომელსაც კონფიგურირებული upstream რეალურად იყენებს, და გაჟონვა სწორი მიზეზით იხურება.