macOS-ის pf დამცავი გადამრთველი OpenVPN-ისთვის: წესები, რომლებიც იხურება

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

რა შეიძლება გადაწყვიტოს პაკეტების ფილტრმა და რა არა

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

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

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

ჯერ წაიკითხეთ ინტერფეისისა და საბოლოო წერტილის ფაქტები

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

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

route -n get default
ifconfig -l
scutil --nc list

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

დაწერეთ წესების ნაკრები გვირაბის გზის გარშემო

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

set skip on lo0
block all
pass out quick on utun0
# maintain this line when the server address changes
pass out quick on en1 inet proto udp to 203.0.113.10 port 1194
# only the resolver the client uses before the tunnel exists
pass out quick on en1 inet proto udp to 192.0.2.53 port 53
pass out quick on en1 inet proto udp from any port 68 to any port 67
pass out quick on en1 inet proto udp to 224.0.0.251 port 5353

DHCP სტრიქონი იმიტომ არსებობს, რომ Mac მისამართს სთხოვს მანამ, სანამ ის აქვს, ამიტომ მოთხოვნა პორტ 68-დან პორტ 67-ისკენ გადის გამოსადეგი წყაროს მისამართის გარეშე. multicast სტრიქონი სისტემას აძლევს საშუალებას განსაჯოს, ღირს თუ არა უსადენო კავშირის გამოყენება, და მისი მოცილება ქმნის მანქანას, რომელიც მომუშავე ქსელში კავშირის არარსებობას იტყობინება. საბოლოო წერტილის სტრიქონი არის ის, რაც OpenVPN-ს საერთოდ აძლევს საშუალებას მიაღწიოს თავის სერვერს; მის გარეშე block all გარე ხელის ჩამორთმევას აგდებს და გვირაბი არასოდეს ამოდის. გადამწყვეტის სტრიქონი ვიწროა ზოგად DNS ნებართვაზე, რადგან ასახელებს ერთ მისამართს და ერთ პორტს და არა ყოველ შეკითხვას, რომელსაც მანქანა აკეთებს.

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

ჩამოუშვით გვირაბი, შემდეგ გადატვირთეთ

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

sudo pfctl -n -v -f /etc/pf.conf
sudo pfctl -f /etc/pf.conf
sudo pfctl -e
sudo pfctl -s rules
sudo pfctl -s Anchors
sudo pfctl -a <anchor> -s rules
sudo pfctl -s info

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

გადატვირთვა ის ნაწილია, რომელსაც ხალხი გამოტოვებს. macOS ჩატვირთვისას კითხულობს /etc/pf.conf-ს, მაგრამ ფაილის კითხვა იგივე არ არის, რაც ფილტრის ჩართვა, ამიტომ ახლა მომუშავე წესების ნაკრები გადატვირთვის შემდეგ შეიძლება უმოქმედო იყოს. ამის შემდეგ გაუშვით sudo pfctl -s info და დაადასტურეთ, რომ მდგომარეობის სტრიქონი ფილტრს ჩართულად იტყობინება.

შეინარჩუნეთ გასასვლელი და გადატვირთვის გზა პატიოსნად

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

sudo pfctl -d
sudo pfctl -f /etc/pf.conf.previous
sudo pfctl -s rules

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

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