გამორთვის სკრიპტი თუ firewall წესი: რომელი აჩერებს გაჟონვას?
ინტერფეისების ჩამოშვება გათიშვისას უხეშია და ხშირად უფლებების გარეშე მუშაობს. შეადარეთ ის firewall წესს, რომელიც ვარდნას გადაურჩება და ხარვეზს კეტავს.
ორი დიზაინი ერთსა და იმავეს გვპირდება: როცა გვირაბი ვარდება, არაფერი გადის გარეთ ღიად. ერთი გათიშვისას სკრიპტს უშვებს და ინტერფეისებს წყვეტს. მეორე firewall წესს ძალაში ტოვებს და VPN კლიენტს არაფერს სთხოვს. ისინი განსხვავდებიან იმით, ვის აქვს მოქმედების უფლება, რა ხდება ხარვეზის დროს და როგორ ბრუნდება მანქანა შემდეგ ონლაინში. ამ სამ პუნქტზე მათი შედარება უფრო სასარგებლოა, ვიდრე კამათი იმაზე, რომელია მკაცრი.
ერთი და იგივე სამუშაო ორი მექანიზმით
კლიენტს შეუძლია კაუჭები გაუშვას გვირაბის აწევისას და გათიშვისას, თუ პროფილი სკრიპტის შესრულებას ნებას რთავს. ეს კაუჭი კლიენტის სასიცოცხლო ციკლის შიგნით მუშაობს, იმ მომენტში, როცა კავშირი იხურება. firewall წესი, პირიქით, სისტემას ეკუთვნის და არ აინტერესებს, კლიენტი მუშაობს, ჩამოიშალა თუ მოკლეს.
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
ეს ცხრილი მთელი არგუმენტია. სკრიპტი, რომელიც მხოლოდ გამართული დახურვისას მუშაობს, ფარავს იმ შემთხვევას, რომელიც ყველაზე ნაკლებად გაწუხებდათ; მთავარი შემთხვევაა ავარია ან ქსელის გაქრობა და არც ერთი მათგანი სუფთა გათიშვას არ იძლევა.
რა შეუძლია და რა არ შეუძლია გათიშვის კაუჭს
დოკუმენტირებული ნიმუში ქსელის ინტერფეისებს გადის და ყველაფერს ჩამოშლის loopback-ის გარდა. როცა ფიზიკური მოწყობილობა ჩამოშვებულია, ვერაფერი გაიქცევა გვირაბის გარეთ და ეს ზუსტად არის განზრახვა.
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
doneის ჩამოშლის ლოკალურ ქსელსაც, ნებისმიერ სერვისს, რომელსაც მანქანა მასპინძლობს, და იმ გზას, რომელსაც პრობლემის გამოსასწორებლად გამოიყენებდით. ლეპტოპზე უსადენო მოწყობილობას ხანდახან შემდეგ ხელით გადართვა სჭირდება, ასე რომ ხანმოკლე შეფერხება სარემონტო სესიად იქცევა. უარესი, კაუჭს შეიძლება ამის არაფრის უფლება არ ჰქონდეს: როცა კლიენტი უფლებებზე უარს ამბობს, გათიშვის სკრიპტი არაპრივილეგირებული ანგარიშით მუშაობს და ინტერფეისის ყოველი ცვლილება უფლების შეცდომით ვარდება, რომელიც იმ მომენტში იწერება, როცა არავინ კითხულობს ჟურნალს.
შეამოწმეთ, როგორ ირთვება კლიენტი, სანამ კაუჭს ენდობით. სკრიპტი, რომელიც root-ით ხელით გაშვებისას მუშაობს, არაფერს ამტკიცებს იმ სერვისზე, რომელიც ჩატვირთვისას იწყება.
რას აკეთებს firewall წესი სხვანაირად
წესი, რომელიც მხოლოდ გვირაბის ტრაფიკს უშვებს, აგრძელებს მუშაობას, როცა კლიენტის პროცესი გაქრა, რადგან ბირთვი ამ პროცესზე არ არის დამოკიდებული. წესი უფრო ვიწროცაა: ზუსტად იმ ნაკადებს ბლოკავს, რომლებსაც ემთხვევა, და loopback-ს, ლოკალურ ქვექსელსა და აღდგენის გზას მარტო ტოვებს, ამიტომ მანქანას ჩიხში არ ტოვებს.
ფასი ისაა, რომ წესი უნდა დაწეროს და შეინარჩუნოს ჰოსტის firewall-ის მფლობელმა, და მან უნდა დაასახელოს გვირაბის მოწყობილობა, რომელსაც კლიენტი რეალურად ქმნის. ეს ნიშნავს, რომ წესი და პროფილი ერთად უნდა შენარჩუნდეს; გადარქმეული ინტერფეისი ტოვებს firewall-ს, რომელიც ყველაფერს ბლოკავს და არაფერს ხსნის.
არც ერთი მექანიზმი მეორეს ზედმეტს არ ხდის. firewall წესი, რომელიც რედაქტირების შემდეგ არასოდეს გადაიტვირთება, ისეთივე გამოგონილია, როგორც სკრიპტი, რომელიც არასოდეს მუშაობს.
persist-tun წყვეტს, არის თუ არა ხარვეზი
როცა გვირაბის მოწყობილობა გათიშვას გადაურჩება, გადარჩება მისკენ მიმავალი მარშრუტებიც. ტრაფიკი მაშინ იშლება და არ გადამისამართდება, ამიტომ ნაგულისხმევი მარშრუტი ფიზიკურ კარიბჭეს არ უბრუნდება. სწორედ ეს ქცევა ხდის გაჟონვას ნაკლებად სავარაუდოს ჯერ კიდევ მანამ, სანამ რომელიმე firewall წესი ჩაერთვება.
ამ პარამეტრის გარეშე მოწყობილობა და მასთან ერთად მარშრუტები იშლება და ნაგულისხმევი მარშრუტი შეიძლება კვლავ ფიზიკურ კარიბჭეზე მიუთითოს. გააკეთებს თუ არა ამას, დამოკიდებულია პლატფორმასა და კლიენტზე და სწორედ ამიტომ მდგომარეობა უნდა დაკვირვებულ იქნას და არა ვარაუდით მიღებულ იქნას. მოეპყარით პარამეტრს როგორც kill switch-ის ნაწილს და არა როგორც წარმადობის ვარიანტს.
შეინარჩუნეთ ხელახალი დაკავშირების გზა ცოცხალი, შემდეგ გამოსცადეთ ოთხი მდგომარეობა
მკაცრმა ბლოკმა შეიძლება კლიენტს ხელახლა დაკავშირებაც აუკრძალოს, რადგან კლიენტს კვლავ სჭირდება მარშრუტი სერვერამდე ფიზიკური კარიბჭის გავლით, მაშინ როცა დანარჩენი ყველაფერი უარყოფილია. დააყენეთ ჰოსტის მარშრუტი იმ ერთ მისამართზე სანამ გვირაბი ამოვა, და ჯერ სახელი გადაწყვიტეთ, რადგან DNS შეიძლება დაბლოკილი იყოს იმ დროისთვის, როცა დაგჭირდებათ.
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0შემდეგ გადაამოწმეთ მდგომარეობები და არა იარლიყი. განზრახ გაიარეთ ოთხი მომენტი: ცივი გაშვება გვირაბის გარეშე, ჯანსაღი სესია, არავის მოთხოვნილი ვარდნა და სესია აღდგენის შემდეგ. ყოველ მომენტში წაიკითხეთ ნაგულისხმევი მარშრუტი და გააკეთეთ ერთი მოთხოვნა, რომლის გასასვლელი მისამართიც ჩანს. აპლიკაცია, რომელიც ნებდება, სანამ გვირაბი ჩამოშვებულია, არაფერს ამბობს საფოსტო კლიენტზე ან განახლების პროგრამაზე, ამიტომ გაიმეორეთ ბოლო შემოწმება ერთი ფონური აპლიკაციით. ჩაწერეთ წესი, ინტერფეისების სახელები და აღდგენის ნაბიჯები, რადგან kill switch, რომლის გადამოწმებაც არავის შეუძლია, ჭორია.