საერთო CA, ცალკე კარები: ერთი სერვისი ერთ მისაღებ ფაილზე

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

სანდო ჯაჭვი სერვისის წევრობაზე არაფერს ამბობს

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

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

აქციეთ არასავალდებულო გადაფარვები მიღების ჭიშკრად

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

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

საზოგადოებრივი გამოცემა OpenVPN 2.6 ccd-exclusive თავის სახელმძღვანელოს გვერდზე ზუსტად ამ პირობას აღწერს, და დასახელებული ფაილის ძიება კლიენტის რეალურ იდენტობაზეა დამოკიდებული. სხვა build-ები და პროდუქტის მიერ მართული სერვერები შეიძლება განსხვავდებოდეს, ამიტომ დაადასტურეთ დაყენებული ვერსია სანამ სხვაგან იმავე სემანტიკას დაეყრდნობით.

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

ერთი საქაღალდე სერვისზე, და არა ერთი საერთო სია

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

DEFAULT ჩანაწერი ის შემთხვევაა, რომელიც ხალხს აბრკოლებს. ის სათადარიგო პარამეტრებს იძლევა, როცა დასახელებული ფაილი არ მოიძებნა, მაგრამ ეს არ არის ის დასახელებული ფაილი, რომელსაც ჭიშკარი მოითხოვს, ამიტომ მარტო კლიენტს ვერ შეუშვებს. გამოცადეთ კლიენტი, რომელსაც საერთოდ არ აქვს ჩანაწერი და დაადასტურეთ უარი; თუ ეს კლიენტი შეშვებულია, სათადარიგო მოქმედებს და ccd-exclusive ამ ეგზემპლარში ძალაში არ არის.

რეალური იდენტობა წყვეტს, რომელი ფაილი იკითხება

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

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

დააკვირდით უარს, მიღებასა და გაუქმებას ცალ-ცალკე

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

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

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