Pritunl: კონტროლის მდგომარეობა და გენერირებული პროფილი

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

ორი ობიექტი სარეზერვო ასლს ჰგავს და მხოლოდ ერთი აღადგენს სერვისს

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

ჰოსტის კონფიგურაციის ასლი თანაბრად ნაწილობრივია. /etc/pritunl.conf შეიცავს ჰოსტის დონის პარამეტრებს, მათ შორის როგორ მივიდეთ მონაცემთა ბაზამდე, და არ შეიცავს თავად VPN ობიექტებს.

რას ფლობს მონაცემთა ბაზა და რას ფლობს ჰოსტი

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

ჰოსტი ამატებს უფრო მცირე, მაგრამ გადაუცემელ მნიშვნელობათა ერთობლიობას. ერთ-ერთი მათგანია /var/lib/pritunl/pritunl.uuid, იმ კონკრეტული კვანძის იდენტობა.

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

გააკეთეთ თანმიმდევრული დამპი და არა საქაღალდის ასლი

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

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

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

ივარჯიშეთ აღდგენაში სანამ დაგჭირდებათ

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

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

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

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