iptables ჰოსტი მხოლოდ VPN-ით: დაასახელეთ tun მოწყობილობა და არა tun+

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

ნაბიჯი 1: ჩაწერეთ წესები, რომლებიც ახლა გაქვთ

ნაგულისხმევი პოლიტიკის შეცვლამდე შეინახეთ მიმდინარე მდგომარეობა, რომ უკან დაბრუნება ბრძანება იყოს და არა მოგონება. iptables-save > /root/iptables.pre ყოველ ცხრილს წერს ფაილში, რომლის აღდგენაც შეგიძლიათ, და მეორე ტერმინალი ღია root სესიით არ არის პარანოია, როცა თქვენი დასაყენებელი პოლიტიკა თიშავს იმ კავშირს, რომელიც მას ზიდავს. თუ დისტანციურად მუშაობთ, დაგეგმეთ flush-იც, როგორც უსაფრთხოების გადამრთველი.

შემდეგ ჩამოთვალეთ ინტერფეისები, რადგან ვარაუდი სახელი ის სახელია, რომელიც უნდა წაგეკითხათ: ip -br link გვიჩვენებს, რა არსებობს ახლა, და გვირაბი არ გამოჩნდება, სანამ არ აიწევა. ჩაწერეთ მოწყობილობების სახელები კითხვისას.

ნაბიჯი 2: მიეცით გვირაბს საკუთარი სახელი

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

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

ნაბიჯი 3: დაწერეთ პოლიტიკა endpoint-ის გამონაკლისით წინ

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

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

ნაბიჯი 4: შეამოწმეთ თანმიმდევრობა და არა მხოლოდ არსებობა

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

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

ნაბიჯი 5: გახადეთ ის გამძლე ჩატვირთვისა და მისამართების ოჯახის მიმართ

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

შემდეგ შეამოწმეთ IPv6 ცალკე, რადგან IPv4-ისთვის კარგი ნაგულისხმევი უარის პოლიტიკა მეორე ოჯახზე არაფერს ამბობს. ip -6 route გეტყვით, აქვს თუ არა ჰოსტს მარშრუტი, რომელსაც შეუძლია ტრაფიკი მხოლოდ IPv4-ს მომსახურე გვირაბის გვერდის ავლით გადაიტანოს, და ip6tables-ს ან nftables-ს საკუთარი ეკვივალენტური წესები სჭირდება. სცადეთ IPv6-only დანიშნულებით, ნაცვლად იმისა, რომ წესების ნაკრების სიმეტრიას დაეყრდნოთ.

ნაბიჯი 6: გადაამოწმეთ და მზად იყავით აღსადგენად

აწიეთ გვირაბი, დაადასტურეთ, რომ თქვენი განზრახული სერვისი მუშაობს, შემდეგ სცადეთ ის, რაც პოლიტიკამ უნდა უარყოს. აღადგინეთ iptables-restore < /root/iptables.pre-ით, თუ პასუხი გაგიკვირდათ, და მხოლოდ ამის შემდეგ დაიწყეთ წესების რედაქტირება. გამძლეობა გამოცდილ აღდგენის გზასთან ერთად არის ის, რაც ამას ორჯერ გასაკეთებელ ცვლილებად აქცევს.