VPN-ის შემდეგ ამოცანები გაუშვით დისპეტჩერიდან და არა if-up-იდან

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

NetworkManager-ის მიერ მართული VPN-ისთვის დისპეტჩერი სწორი ადგილია, და vpn-up სწორი მოქმედებაა.

გამოიყენეთ vpn-up და არა ინტერფეისის მოვლენა

დისპეტჩერი განასხვავებს up-ს vpn-up-სგან. პირველი აქტივირებულ ინტერფეისს აცნობებს; მეორე აქტივირებულ VPN კავშირს. Wi-Fi-ის აწევა მხოლოდ იმას ნიშნავს, რომ საფუძვლიანი რგოლი არსებობს; გვირაბი შეიძლება ჯერ კიდევ მოლაპარაკებოდეს, ან საერთოდ არასდროს ავთენტიფიცირდეს.

სკრიპტი იღებს ინტერფეისსა და მოქმედებას, ხოლო კავშირის დეტალები გარემოთი მოდის, მათ შორის პროფილის UUID და VPN-ის IP ინტერფეისი. წაიკითხეთ ეს ცვლადები იმის ნაცვლად, რომ იდენტობა მოწყობილობის სახელებიდან გამოიტანოთ.

შეზღუდეთ შესაბამისობა ერთ კავშირზე

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

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

იცოდეთ, რას არ ამტკიცებს აქტივაცია

vpn-pre-up მუშაობს მანამ, სანამ NetworkManager VPN-ის სრულ აქტივაციას შეატყობინებს, და მენეჯერი ამ სკრიპტებს ელოდება. დაბლოკვის ეტაპი გამოიყენეთ მხოლოდ მაშინ, როცა ამოცანა ნამდვილად იქ ეკუთვნის, რადგან ნელი შემოწმება აჭიანურებს აქტივაციას, რომელსაც ყველა სხვა კომპონენტი ელოდება სანახავად.

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

პატივი ეცით კონტექსტს, რომელშიც სკრიპტი მუშაობს

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

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

დაგეგმეთ გაწყვეტა, რომელიც არასდროს ამუშავდება

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

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