LAN-ის NAT tun0-ით OpenBSD VPN კარიბღეზე

ორი ინჟინერი, რომელთაც ერთი და იგივე OpenBSD კარიბღე აქვთ, ხშირად დისტანციურ ქსელამდე მისასვლელად ორ სხვადასხვა წესების ერთობლიობას მოგცემთ და ორივეს დაცვა შეიძლება. არჩევანი წყაროს თარგმანსა და დაბრუნების მარშრუტს შორის სულაც არ არის სინტაქსის საკითხი. ეს დამოკიდებულია იმაზე, რა იცის მოპირდაპირე მხარემ უკვე 192.168.88.0/24-ზე და რა გრჯირდებათ შესანარჩუნებლად თქვენს ჟურნალებში. აქ შეცდომა და nat-to სტრიქონი სრულთად სწორედ გამოჩნდება, სანამ პასუხები დისტანციურ ნაგულისხმევ კარიბღეში გაქრება.

მარშრუტიზაცია და გადაწერა სხვადასხვა კითხვას პასუხობს

მარშრუტიზაციის ცხრილი წყვეტს, რომ 172.20.0.0/16 tun0-ის გავლით ხელმისაწვდომია და ეს გადაწყვეტილება მიიღება მანამ, სანამ რომელიმე pf თარგმანს ჰკითხავენ. შემდეგ წყაროს თარგმანი ცვლის პაკეტის თავსართს, რათა დისტანციურმა მხარემ LAN ჰოსტის ნაცვლად კარიბღის გვირაბის მისამართი დაინახოს. არც ერთი მექანიზმი არ ცვლის მეორეს: nat წესი ვერ შექმნის მარშრუტს და მარშრუტი ვერ დაარწმუნებს დისტანციურ როუტერს, რომელსაც თქვენს კერძო ქვექსელის შესახებ არასდროს სმენია. როცა დისტანციურ მხარეს დაბრუნების გზა არ აქვს, პასუხები იშლება ან მის ნაგულისხმევ კარიბღში გადადის და წესების არანაირი რეგულირება ამას არ ასწორებს.

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

სამი პირობა, რომელიც წყვეტს

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

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

ფრაგმენტი ისე მოათავსეთ, რომ pf მას ნამდვილად შეაფასოს

ქვემოთ მოცემული ფრაგმენტი ვარაუდობს, რო LAN არის 192.168.88.0/24, დისტანციური ქსელი — 172.20.0.0/16, ხოლო გვირაბის ინტერფეისი — tun0. მაში არაფერი არ ირჩევს შემდეგ ნახტომს. ის მხოლოდ წყაროს გადაწერს იმ პაკეტებში, რომელთაც უკვე გვირაბიდან გადიან.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

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

არ დაივიწყოთ ბირთვის მხარე. IPv4 გადამისამართება უნდა იყოს ჩართული და გვირაბისა და LAN-ის მდგომარეობის მქონე pass წესები უნდა არსებობდენ რომელიმე ამ ყველაფერს აზრი ექნება. აქ საკვანძო სიტყვების რიგისთვის OpenBSD FAQ-ის PF NAT განყოფილება სწორი მთითებაა.

წესების ერთობლიობა გადაამოწმეთ, სანამ ტრაფიკს ენდობთ

ჯერ სინტაქსი შეამოწმეთ pfctl -nf /etc/pf.conf-ით, რომელიც ფაილს ჩატვირთვის გარეშე აანალიზებს. შემდეგ ჩატვირთეთ პოლიტიკა და წაიკითხეთ, რას ინახავს ბირთვი სინამდვილეში, რადგან სუფთად გაანალიზებული წესი მაინც შეიძლება დაჩრდილული იყოს ან არასწორ ინტერფეისზე მიმაგრდეს. pfctl -sn თარგმანის წესებს ჩატვირთული სახით ბეჭდავს, ხოლო pfctl -sr ფილტრის წესებს შეფასების რიგით.

შემდეგ დააკვირდეთ მავთულს. კარიბღეზე tcpdump -ni tun0 'host 172.20.0.10' გვიჩვენებს, გვირაბიდან გამომავალი წყაროს მისამართი გვირაბის მისამართია თუ LAN ჰოსტის. სწრაფი netstat -rn -f inet ადასტურებს, რომელ ინტერფეისზე იხსნება დანიშნულება. როგორც ტრაფიკი დაიწყებს დინებას, pfctl -ss მდგომარეობის ჩანაწერებს ჩამოთვლით გაამოთვლებს; თუ ნაკადმა მდგომარეობა არ შექმნა, პაკეტი არასდროს შეხვედრა წესს, რომელიც ერთს ქმნიდა.

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

როცა თარგმანი უფრო ძვირია, ვიდრე ის ზოგავს

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

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

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