OpenVPN-ის კარიბჭის ერთ LAN-ზე შემოფარგლვა UFW-ის წესებით

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

ჯერ ჩაწერეთ ტოპოლოგია და ნებართვა

მაგალითი იყენებს Community OpenVPN სერვერს მომხმარებლის სივრცის TUN მოწყობილობით სახელად tun0, კლიენტთა აუზით 10.77.0.0/24, და ერთი მიერთებული ქვექსელით 192.168.60.0/24 lan0-ზე. IPv4 გადაგზავნა უკვე მუშაობს და LAN-ს უკვე აქვს დაბრუნების მარშრუტი აუზისკენ, ამიტომ აქ არაფერი არ არის დამოკიდებული მათ შორის თარგმანზე.

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

მოათავსეთ დაცვები UFW-ის ადრეულ მიღებებამდე

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

ფაილის *filter სექციაში /etc/ufw/before.rules გამოაცხადეთ ორი ჯაჭვი არსებული გამოცხადებების გვერდით და ნებისმიერი წესის სტრიქონამდე.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

გამოცხადებების შემდეგ დაუყოვნებლივ და შეყვანისა და გადაგზავნის ნებართვებამდე გადახტით მათში და განსაზღვრეთ რას უშვებენ.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

წაიკითხეთ რას უშვებს და რას უარყოფს თითოეული დაცვა

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

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

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

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

ჯერ გადახედეთ მარშრუტის ნებართვას, შემდეგ მოხსენით გადახედვის დროშა მის გამოსაყენებლად: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. შემდეგ გადახედეთ მომხმარებლის წესების რიგს, რადგან ადრინდელი უარი კვლავ იმარჯვებს გვიან ნებართვაზე. მთელ ქვექსელზე ნებართვა ასევე არასწორი ფორმაა, როცა მხოლოდ ერთი ჰოსტის HTTPS პორტი უნდა იყოს ხელმისაწვდომი.

ყურადღება მიაქციეთ რას აკეთებს შეყვანის მოხსნა: გვირაბის კლიენტები ვერ აღწევენ არცერთ სერვისს თავად კარიბჭეზე, მათ შორის DNS მსმენელს, რომელიც მიბმულია მის LAN მისამართზე. იქ DNS-ის განთავსება მოითხოვს განზრახ გამონაკლისს მოხსნამდე და გადახედილ ნებართვის ხელშეკრულებას. თუ UFW მართავს IPv6-ს, დაამატეთ შესაბამისი მოხსნები tun0-სთვის before6.rules ფაილში, რადგან IPv4 დანიშნულებების სია არაფერს ამბობს IPv6 პაკეტებზე.

შეამოწმეთ ჩატვირთული პოლიტიკა და არა გადახედვა

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

sudo ufw --dry-run reload
sudo ufw show raw

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

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

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