OpenVPN client-connect-ის წარუმატებლობა: გარანტირებულია თუ არა გასუფთავება disconnect-ზე?
უარყოფილი კლიენტი არ აუქმებს firewall-ის წესს ან ჩაწერილ ჩანაწერს. შეადარეთ callback-ის კონტრაქტი იმ უკუქცევას, რომელიც თქვენმა hook-მა თავად უნდა შეასრულოს.
როდესაც client-connect სკრიპტი გამოდის არანულოვანი კოდით, OpenVPN უარყოფს კლიენტს და ოპერატორები ჩვეულებრივ ვარაუდობენ, რომ შესაბამისი client-disconnect სკრიპტი ყველაფერს მოაწესრიგებს. ხშირად ის საერთოდ არ ეშვება, რადგან disconnect-ის დამუშავება დამოკიდებულია იმაზე, რაც connect ეტაპმა შეძლო დაესრულებინა. უარყოფისა და უკუქცევის ერთ მექანიზმად განხილვაა ის, რაც წარუმატებელ შესვლას გაჟონილ firewall-ის წესად ან ობოლ ჩანაწერად აქცევს. ეს ორი ცალკე ვალდებულებაა და მხოლოდ ერთი მათგანია ავტომატური. წაიკითხეთ hook-ის საკუთარი გასვლის გზა, სანამ სერვერს დასდებთ ბრალს მდგომარეობის დატოვებაში.
არანულოვანი გასვლა უარყოფს კლიენტს, მაგრამ არ აუქმებს თქვენს სამუშაოს
client-connect-ის გასვლის სტატუსი მიღების გადაწყვეტილებაა. ნული ნიშნავს მიღებას, ნებისმიერი სხვა მნიშვნელობა ნიშნავს ინსტანსის დანგრევას სრულ დამკვიდრებამდე. ამ კონტრაქტში არაფერი ამოწმებს, რა გააკეთა სკრიპტმა უკვე გარე სამყაროში. თუ სკრიპტმა დაამატა iptables-ის წესი, დაწერა სტრიქონი ან გაზარდა მთვლელი, ეს ცვლილებები უარყოფას გადაურჩება.
იგივე ასიმეტრია ეხება დანამატებს, სადაც ერთი ინსტანსისთვის შეიძლება რამდენიმე connect ფუნქცია გაეშვას. გვიანდელი წარუმატებლობა უკუძალით არ აუქმებს ადრინდელ წარმატებას და ადრინდელ ფუნქციას არ აქვს გზა გაიგოს, რომ დობილი ფუნქცია ჩავარდა.
უარყოფა ავტომატურია, გასუფთავება არა
OpenVPN 2.6-ის სახელმძღვანელო client-disconnect-ის დამუშავებას აკავშირებს წინა connect-ის წარმატებულ დამუშავებასთან. დოკუმენტირებული გამონაკლისი მოიცავს კასკადურ ჯაჭვებს: თუ connect-ის ერთი ნაბიჯი უკვე დაბრუნდა წარმატებით, შესაბამისი disconnect-ის ნაბიჯები მაინც შესრულდება ინსტანსის დანგრევისას, მაშინაც კი, თუ გვიანდელი connect-ის ნაბიჯი ჩავარდა. ეს გამონაკლისი ვიწროა და დამოკიდებულია იმაზე, რამდენი callback არის კონფიგურირებული, ამიტომ ერთი shell სკრიპტის ტესტირება ჯაჭვზე არაფერს გეუბნებათ.
დახაზეთ რეალური კონფიგურაცია მის გარშემო დიზაინის შექმნამდე: რომელი სკრიპტი, რომელი დანამატი და რა თანმიმდევრობით ეშვება. ქვემოთ მოცემული ცხრილი ჩამოთვლის, რას ტოვებს ნახევრად დასრულებული კონფიგურაცია.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
თითოეული სტრიქონი ერთნაირად მთავრდება კლიენტისთვის და განსხვავებულად ჰოსტისთვის. კლიენტი ვერ გაიგებს, რომელი მათგანი მოხდა, ამიტომ hook-მა უნდა უკუაქციოს გაკეთებული, სანამ წარუმატებლობის სტატუსს დააბრუნებს.
კომპენსაცია მოახდინეთ იმ სკრიპტის შიგნით, რომელიც ჩავარდა
შეამოწმეთ ყველაფერი, რაც შესაძლებელია, სანამ საერთო მდგომარეობას შეეხებით: სერტიფიკატის ველები, მისამართის ხელმისაწვდომობა, ჯგუფი, რომელსაც კლიენტი მიეკუთვნება. ყველაზე იაფი უარყოფა ის არის, რაც ნებისმიერ განაწილებამდე ხდება. როცა კონფიგურაცია რამდენიმე გარე ოპერაციას მოიცავს, ჩაინიშნეთ, რომელი დასრულდა, და წარუმატებლობის სტატუსის დაბრუნებამდე უკუქცევით, საპირისპირო თანმიმდევრობით დააბრუნეთ ისინი.
კონკრეტული შემთხვევა: სკრიპტი ქმნის firewall-ის ჩანაწერს თითოეული კლიენტისთვის, შემდეგ კი ვერ ახერხებს მის აღწერილ მდგომარეობის სტრიქონის ჩაწერას. ჩავარდნილმა შტომ უნდა წაშალოს ახლახან შექმნილი ჩანაწერი და შემდეგ გავიდეს არანულოვანი კოდით. disconnect-ის მოვლენის ლოდინი, რომელიც შესაძლოა არასოდეს დაიგეგმოს, ის გზაა, რომლითაც წესი სესიაზე მეტხანს ცოცხლობს.
გახადეთ კომპენსაცია იდემპოტენტური და მესაკუთრიანი
გასუფთავება უნდა იყოს ორჯერ გაშვებისთვის უსაფრთხო და ზუსტი იმაში, თუ რისი წაშლა შეუძლია. ადრინდელი მცდელობის დაგვიანებული მოვლენა არ უნდა შლიდეს უფრო ახალი სესიის განაწილებას მხოლოდ იმიტომ, რომ ორივეს საერთო სახელი ან გადამუშავებული გვირაბის მისამართი აქვს. ჩაწერეთ კონკრეტული სახელური ან ოპერაციის id რესურსთან ერთად და წაშალეთ ამ გასაღებით და არა სახელით. მონაცემთა ბაზის ტრანზაქციები მხოლოდ თავად ბაზის ცვლილებებში გვეხმარება; ამ საზღვრის გარეთ მყოფი firewall-ის წესი მოითხოვს ცხად კომპენსაციის ნაბიჯს.
დაუშვით, რომ პროცესი შეიძლება მოკვდეს ცვლილებასა და გასუფთავებას შორის, და დაამატეთ შემთხვევების შემმოწმებელი, რომელიც გრაფიკის მიხედვით ადარებს გარე მდგომარეობას მიღებული კლიენტების სიას.
შეამოწმეთ სამი გზა, რომლებიც ნამდვილად განსხვავდება
ივარჯიშეთ სამ შემთხვევაზე: უარყოფა სანამ რამე განაწილდება, უარყოფა ნაწილობრივი განაწილების შემდეგ და ჩვეულებრივი მიღებული სესია, რომელიც მოგვიანებით მთავრდება. ეს სამი განსხვავებულ ლოგის სტრიქონებს და განსხვავებულ ნარჩენებს იძლევა. შეამოწმეთ გარე მდგომარეობა თითოეულის შემდეგ და არა მხოლოდ კლიენტის წარუმატებლობის შეტყობინება, რადგან კლიენტის წარუმატებლობა სამიდან ორში მოსალოდნელი შედეგია.
ჩაწერეთ hook-ის ეტაპი, გასვლის სტატუსი და რა განაწილდა ან გათავისუფლდა, სერტიფიკატების გარეშე. hook-ის ლოგი, რომელიც ასახელებს მის მიერ შექმნილ რესურსს, სწორედ ის არის, რაც გაჟონილ წესს ექვსი თვის შემდეგ საპოვნელს ხდის.