VPN კავშირების ლიმიტები: ცოცხალი მდგომარეობა თუ შენახული ისტორია
სამი კავშირის ლიმიტს სჭირდება სლოტების ცოცხალი მდგომარეობა და არა დათვალიერების ისტორია: რა უნდა შეინახოს მექანიზმმა, რა შეიძლება გააუქმოს და სად მიდის ეს მდგომარეობა შემდეგ.
სამი ერთდროული კავშირი მიღების გადაწყვეტილებაა და მასზე პასუხის გასაცემად საჭიროა ვიცოდეთ, რომელი სლოტებია ახლა დაკავებული და არა ის, რაც გასულ თვეში მოხდა. სერვისს შეუძლია მეოთხე სესია უარყოს აქტიური ჩანაწერების პატარა ცხრილიდან და არასდროს ააგოს დროითი ხაზი. ეს მექანიზმზეა ნათქვამი და არა ოპერატორზე, და განსხვავებას მნიშვნელობა აქვს, როცა კონფიდენციალურობის პოლიტიკას კითხულობ. ქვემოთ მოცემული მოდელი აჩვენებს, რა სჭირდება გადაწყვეტილებას და რა შეიძლება გააუქმოს.
მექანიზმი: სლოტების ცხრილი და არა ჟურნალი
უმარტივესი განხორციელება გამოწერას უკავშირებს სამამდე აქტიურ სესიის ჩანაწერს. ყოველი მიღებული სესია იკავებს ერთ სლოტს და სლოტი თავისუფლდება, როცა სერვისი გადაწყვეტს, რომ ეს სესია დასრულდა. ჩანაწერს სჭირდება ისეთი სპეციფიკური იდენტობა, რომ ერთი კავშირის გათავისუფლებამ არ გაათავისუფლოს სხვა კავშირის სლოტი; ამიტომ სესიის იდენტიფიკატორი ანგარიშის სახელზე მნიშვნელოვანია.
დაკავებულობა და ისტორია სხვადასხვა მონაცემთა სტრუქტურაა. დაკავებულობა პასუხობს დიახ-თუ-არა კითხვას აწმყოზე და შეიძლება გაუქმდეს იმ მომენტში, როცა სესია სრულდება. ისტორია მხოლოდ დასამატებელი მოვლენების ნაკადია და ის რჩება იმიტომ, რომ ვიღაცამ აირჩია მისი შენახვა. სერვისს შეიძლება ჰქონდეს ერთი, ორივე ან არცერთი.
განსხვავება გარედან უხილავია. ხილული კავშირების ლიმიტი თავსებადია მეხსიერებაში არსებულ პაწაწინა მთვლელთან, საერთო მონაცემთა ბაზის ცხრილთან და სრული მოვლენების არქივთან საინფორმაციო პანელით. ლიმიტზე არაფერი გეუბნებათ, რომელი მათგანი მუშაობს.
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
რატომ სჭირდება ცოცხალ მოდელს მაინც კოორდინაცია
შეიძლება დაკარგული კავშირი მაშინვე არ იქნას აღიარებული დასრულებულად. კარიბჭე ელოდება დროის ლიმიტს, keepalive-ის ჩავარდნას ან აღრიცხვის გაჩერებას და სანამ ერთ-ერთი მათგანი არ მოვა, სლოტი დაკავებული რჩება. მომხმარებელი, რომელიც ამ ფანჯარაში ხელახლა უკავშირდება, ხედავს უარის თქმას, რომელსაც მეოთხე მოწყობილობასთან არაფერი აქვს საერთო.
გადატვირთულ სერვერს თავისი მდგომარეობის შეჯერება სჭირდება, ხოლო რამდენიმე კარიბჭეს, რომელიც ერთსა და იმავე ანგარიშს ემსახურება, საერთო გადაწყვეტილება სჭირდება. წინააღმდეგ შემთხვევაში ანგარიშმა შეიძლება გადააჭარბოს თავის კვოტას სხვადასხვა მდებარეობაზე დაკავშირებით. საერთო ან აღდგენადი მდგომარეობა ამას წყვეტს, და საერთო მდგომარეობა დიზაინის მოთხოვნაა და არა მეთვალყურეობის მტკიცებულება.
ამ კოორდინაციის არცერთ ნაწილს არ სჭირდება დათვალიერების ისტორია. პაკეტების გადამცემ კარიბჭეს სესიების დასათვლელად არ სჭირდება იცოდეს, რომელი საიტები მოინახულა სესიამ, და ეს ორი მონაცემთა ნაკადი ჩვეულებრივ სრულიად სხვადასხვა კომპონენტებით მუშავდება.
მთვლელის მეხსიერებაში შენახვა დაკავშირებულ ფაქტებს ანონიმურად არც აქცევს. სანამ სერვისი მუშაობს, გამოწერაზე მიბმული ჩანაწერი ავლენს, რომ ანგარიშს აქტიური კავშირები აქვს, და როგორც ამ მდგომარეობაზე წვდომა, ისე მისი სიცოცხლის ხანგრძლივობა კითხვას იმსახურებს.
სად მიდის მდგომარეობა შემდეგ
კონფიდენციალურობის კითხვა არ არის ის, შეუძლია თუ არა სერვერს დათვლა. იკითხეთ, რა ემართება დასრულებულ სესიას: ჩანაწერი იშლება თუ იქცევა მოვლენად მონიტორინგის სერიაში? შემდეგ იკითხეთ, რომელმა სხვა კომპონენტებმა ნახეს იგივე მოვლენა, რადგან ავთენტიფიკაციის ჟურნალებს, აღრიცხვის ჩანაწერებსა და სარეზერვო ასლებს შეიძლება თითოეულს ჰქონდეს ასლი, რომელიც აღსრულების გზამ გააუქმა.
RADIUS აღრიცხვა ყველაზე ნათელი მაგალითია. Start და Stop წყვილი არსებობს გადახდისა და სესიების კონტროლის მხარდასაჭერად და ის ქმნის კავშირის ჩანაწერს, მიუხედავად იმისა, ეკითხება თუ არა მას ვინმე ოდესმე ისტორიის სახით. ამიტომ აღრიცხვის მეშვეობით ლიმიტების აღმსრულებელი სერვისი აგებულების მიხედვით ინახავს უფრო მეტს, ვიდრე სლოტების ცხრილი.
წაშლასაც აქვს ფორმა. ცოცხალი ცხრილიდან წაშლილი ჩანაწერი შეიძლება შენარჩუნდეს ერთი საათით ადრე აღებულ სარეზერვო ასლში, და ამ ასლის შენახვის ვადა თავისთავად პოლიტიკის განცხადებაა. მხოლოდ პირველადი საცავის კითხვა არასრულ პასუხს იძლევა.
დასვით კითხვა ველების მიხედვით
RFC 6973-ის მონაცემთა მინიმიზაციის სახელმძღვანელო აკავშირებს შეგროვილ და შენახულ მონაცემებს მომსახურე მიზანს. აქ გამოყენებისას სასარგებლო კითხვაა, რომელი ველები სჭირდება რეალურად ერთდროული მიღების ამოცანას და რომელი მიზანი ამართლებს თითოეულის შენახვას ამ ამოცანის დასრულების შემდეგ.
სერვისის ზუსტი განცხადება ჰყოფს კვოტის აღსრულებისთვის გამოყენებულ ცოცხალ კავშირის მდგომარეობას შეწყვეტის შემდეგ შენახული ნებისმიერი ჩანაწერისგან და ასახელებს სხვა სისტემებს დაპირების ფარგლებში. წინადადება, რომელიც მხოლოდ ამბობს, რომ სამი კავშირი აღსრულდება, არ ადგენს არც არქივის არსებობას და არც მის არარსებობას.
როცა ცხოვრების ციკლი გაურკვეველია, ჩაწერეთ ის უპასუხო შენახვის კითხვად და არა განაჩენად. ლიმიტის არსებობა ფარული ისტორიის მტკიცებულება არ არის, და ცოცხალი მდგომარეობის დამაჯერებელი ახსნა პროვაიდერის აუდიტი არ არის.