VPS-ის ფაირვოლი: გახსენით მხოლოდ VPN პორტი და შემდეგ დაამტკიცეთ

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

ერთადერთი პორტი, რომლის დახურვაც შეუძლებელია

VPN მსმენელმა უნდა მიიღოს კავშირები მისამართებიდან, რომელთა წინასწარ განსაზღვრაც შეუძლებელია, ამიტომ ის განსაზღვრებით საჯარო სერვისია. ეს არის ერთადერთი გამონაკლისი, რომელზეც დიზაინი აგებულია: ერთი UDP პორტი OpenVPN-ისთვის, ერთი UDP პორტი WireGuard-ისთვის, ერთი TCP პორტი SSL VPN-ისთვის. დანარჩენი ყველაფერი გვირაბის მიღმაა, ანუ აპლიკაციის სერვისებმა უნდა მიაბას თავი გვირაბის მისამართს ან loopback-ს და არა ყველა ინტერფეისს.

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

შემავალი, გადამისამართება და NAT სხვადასხვა კითხვას პასუხობს

შემავალი ტრაფიკი თავად ჰოსტისთვის არის განკუთვნილი, ამიტომ სწორედ იქ ცხოვრობენ VPN მსმენელი და ადმინისტრაციული გზა. გადამისამართების ტრაფიკი ჰოსტში გადის და გვირაბის კლიენტებს ის სჭირდებათ net.ipv4.ip_forward=1-თან ერთად. კლასიკური ნახევრად გატეხილი კონფიგურაცია უშვებს გამავალ ნაკადს და ივიწყებს დაბრუნების მიმართულებას, ამიტომ კლიენტი ხელის ჩამორთმევას ასრულებს და შემდეგ არაფერი იტვირთება; დამკვიდრებული და დაკავშირებული ტრაფიკისთვის conntrack წესი ფარავს ამ მიმართულებას.

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

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

საფუძველი, რომელიც ერთი გავლით იკითხება

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

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

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

ბოლო პორტის დახურვა ჰოსტის დაკარგვის გარეშე

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

ცვლილება გაატარეთ უკვე დამყარებული სესიიდან და არა იმ კავშირიდან, რომლის გაფილტვრასაც აპირებთ. დაგეგმეთ დაბრუნება, რათა შეცდომას ვადა გაუვიდეს და არ გახდეს მუდმივი, მაგალითად systemd-run --on-active=10min დავალება, რომელიც აღადგენს წინა წესების ნაკრებს, და პირველის გამოცდის დროს მეორე SSH სესია ღიად გქონდეთ. შემდეგ შეამოწმეთ, რომ დაბრუნების დავალება ნამდვილად ირთვება, რადგან გამოუცდელი აღდგენა იგივეა, რაც აღდგენის არარსებობა.

შეამოწმეთ გზა და არა სკრიპტი

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

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

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

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