სად უნდა იყოს თვიური მონაცემთა კვოტა OpenVPN ანგარიშზე

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

კვოტა ანგარიშზე მიამაგრეთ, გვირაბზე არა

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

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

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

დააფიქსირეთ ერთეული, მიმართულება და განულების საზღვარი

ოთხი განმარტება წერილობით უნდა დაფიქსირდეს ნებისმიერი შეგროვების დაწყებამდე. კვოტა ითვლის კლიენტის მიერ გაგზავნილ ბაიტებს, მიღებულ ბაიტებს, თუ ორივეს ჯამს? გიგაბაიტი 10^9 ბაიტია თუ 2^30? რომელ ადგილობრივ საათში და რომელ დროის სარტყელში იბრუნება პერიოდი? და რას ზომავს მთვლელი ზუსტად, თუ გვირაბის ზედნადები ხარჯები და გადაგზავნები შედის, ხოლო აპლიკაციის ფაილის ზომა და პროვაიდერის ინვოისი არა?

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

ბაიტების ჯამები აქციეთ ერთ ჩამოწერილ სხვაობად

მართვის ინტერფეისი აცხადებს პერიოდულ BYTECOUNT_CLI ხაზებს, რომლებიც ატარებენ კლიენტის ID-ს და თითოეულ მიმართულებაში დაგროვილ ბაიტების ჯამებს, ხოლო bytecount ბრძანება ადგენს, რამდენად ხშირად მოდიან ისინი. სერვერის თვალსაზრისით, მიღებული რიცხვი ითვლის კლიენტის მიერ გაგზავნილ ბაიტებს, ხოლო გაგზავნილი რიცხვი — მისთვის მიწოდებულ ბაიტებს. ინტერვალი დააყენეთ ისე, რომ წიგნმა შეძლოს მისი შეთვისება; ძალიან მოკლე ინტერვალი ყიდულობს სიზუსტეს, რომელსაც რეალურად არ იღებთ.

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

rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge  = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now

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

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

ამოწურვამ შესვლა უარყოს, და არა მხოლოდ გვირაბი მოკლას

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

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

ტოკენზე დაფუძნებული ხელახალი დაკავშირებები საკუთარ გამოცდას იმსახურებენ. OpenVPN 2.6-ს შეუძლია სესიის ტოკენის შიდა ვალიდაცია auth-gen-token-ით, გვერდს უვლის რა გარე ავთენტიფიკაციის გამოძახებას, რომელსაც თქვენი კონტროლერი ზღვრის აღსრულებისთვის იყენებდა. ამიტომ ჯერ კიდევ ძალაში მყოფი ტოკენი ადასტურებს იდენტობას და არა დარჩენილ კვოტას, და ყოველმა ახალმა კლიენტის ინსტანციამ მაინც უნდა გაითვალისწინოს წიგნი. თუ ნაცვლად ჩართავთ management-client-auth-ს, კონტროლერი თავად ხდება ავთენტიფიკატორი და მემკვიდრეობით იღებს ვალდებულებას, თავად გააანალიზოს სესიის მდგომარეობა და უარყოს ვადაგასული ან არასწორი ტოკენები.

მიიღეთ გადაჭარბება, რომელსაც ნიმუშაღება ქმნის

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

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

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