keepalive OpenVPN-ში თუ restart systemd-ში: რომელი აღადგენს კავშირს?
ჩუმი პარტნიორი, მკვდარი პროცესი და გამოუსადეგარი აპლიკაცია სამი განსხვავებული ხარვეზია. მიეცით keepalive OpenVPN-ს, პროცესი systemd-ს და გამოსცადეთ თითოეული შემთხვევა.
გვირაბთან სამი განსხვავებული რამ შეიძლება არასწორად წარიმართოს და ისინი სამ სხვადასხვა რეაქციას მოითხოვენ. პარტნიორი პასუხს წყვეტს, დემონის პროცესი იღუპება, ან გვირაბის უკან მდგარი აპლიკაცია სერვისს წყვეტს. კონფიგურაცია, რომელიც რომელიმე მათგანზე სერვისს გადააყენებს, ყურადღებიანი ზედამხედველობა არ არის; ეს ერთი უხეში მოქმედებაა, რომელიც დაუკავშირებელ ხარვეზებზე გამოიყენება. იმის შედარება, თუ რისი დაკვირვება შეუძლია თითოეულ მექანიზმს სინამდვილეში, შრომის დანაწილებას აშკარას ხდის.
სამი ხარვეზი, რომლებიც ერთს ჰგავს
პარტნიორის სიჩუმე ნიშნავს, რომ მეორე ბოლომ გაგზავნა შეწყვიტა და OpenVPN-ს ეს თავად შეუძლია გამოავლინოს, რადგან გულისცემა მისია. პროცესის სიკვდილი ნიშნავს, რომ დემონი გავიდა, რასაც სერვისის მმართველი ამჩნევს და OpenVPN ვერ ამჩნევს. აპლიკაციის ხარვეზი ნიშნავს, რომ გვირაბი რიგზეა და მის უკან რაღაც არ არის, და დარჩენილი ორი მექანიზმიდან არც ერთს არ აქვს ამის გაგების გზა. თითოეულს განსხვავებული რეაქცია სჭირდება და არც ერთი მათგანი არ არის იგივე, რაც გვირაბის მუშაობის შემჩნევა.
ეს სხვადასხვა ფენის სხვადასხვა სიგნალებია და თითოეულს ჰყავს მფლობელი, რომელსაც შეუძლია გამოცნობის გარეშე იმოქმედოს. მათი შერევა ქმნის სისტემას, რომელიც იმ სიმპტომებზე გადაიტვირთება, რომელთა ინტერპრეტაციაც არ შეუძლია.
ჩაწერეთ სამივე შემთხვევა სანამ რომელიმე ტაიმერს შეცვლით. თავად სია ჩვეულებრივ აჩვენებს, რომ ერთ მექანიზმს სამივეს დაფარვას სთხოვენ.
რაში ვრცელდება keepalive სინამდვილეში
keepalive ინსტრუქცია შემოკლებაა და გაშლა რეჟიმის მიხედვით განსხვავდება. სერვერზე keepalive 10 60 ხდება ლოკალური ping ყოველ ათ წამში, 120 წამის ლოკალური გადატვირთვის ვადა და 10 და 60 მნიშვნელობები, რომლებიც კლიენტებს ეგზავნება. სერვერის ვადა განზრახ გაორმაგებულია, რათა კლიენტმა გადატვირთვის შანსი მიიღოს სანამ სერვერი დანებდება. წაიკითხეთ გაშლილი ფორმა მოქმედ კონფიგურაციაში და არა პროფილის შემოკლება.
სწორედ ეს გაორმაგებაა მიზეზი, რომ ნებისმიერი აღწერა, რომელიც აცხადებს, რომ ორივე ბოლო სამოცი წამის შემდეგ გადაიტვირთება, მცდარია. ის ასევე ხსნის, რატომ არ რხევა ორივე ბოლო ერთად, როცა გზა უარესდება.
გულისცემა OpenVPN-ის პარტნიორული ტრაფიკია და არა რომელიმე საჯარო ჰოსტის ICMP შემოწმება. პასუხი მხოლოდ იმას ამტკიცებს, რომ გვირაბის შორეული ბოლო ცოცხალია. ის არაფერს ამბობს იმ მონაცემთა ბაზაზე ან ვებ სერვისზე, რომელიც მომხმარებელს ნამდვილად სჭირდება.
რას არ აკვირდება Restart=on-failure
წაიკითხეთ დაყენებული ერთეული სანამ გადაფარვას დაამატებთ. Restart=on-failure დოკუმენტირებულ პროცესის ხარვეზის პირობებზე რეაგირებს, რაც არ არის იგივე, რაც კავშირის მდგომარეობაზე დაკვირვება. ის არ ირთვება იმიტომ, რომ შიდა ხელახალი დაკავშირება დაიწყო, და სუფთა გასვლას განსხვავებული მნიშვნელობა აქვს, ვიდრე ავარიას.
ეს განსხვავება მნიშვნელოვანია, რადგან შიდა გადატვირთვა იგივე პროცესს ცოცხლად ინახავს. ერთეული ვერაფერს ხედავს, გვირაბი თავისით აღდგება და სწორედ ეს არის სწორი შედეგი.
დააყენეთ RestartSec და გაშვების ლიმიტები განზრახ, თორემ ავარიების ციკლი კარიბჭეს დაარტყამს და ნამდვილ შეცდომას გადატვირთვის შეტყობინებების ქვეშ დამარხავს. ამოქმედებული გადატვირთვის ლიმიტი ერთეულს ხარვეზში ტოვებს, რაც ჩანს, ხოლო უსაზღვრო ციკლი არ ჩანს.
ping-restart და ping-exit ურთიერთშემცვლელი არ არის
ping-restart OpenVPN-ის შიდა გადატვირთვას იწყებს და პროცესს ინახავს. ping-exit პროცესს იმავე ტიპის ვადაზე ამთავრებს, რაც გადაწყვეტილებას სერვისის მმართველს გადასცემს. ისინი ურთიერთგამომრიცხავია და მეორის არჩევა ცვლის იმას, თუ ვის ეკუთვნის აღდგენა. განსხვავება იმაშია, თუ ვინ წყვეტს ხელახლა ცდას და რამდენი მდგომარეობა გადაურჩება ცდას.
თუ ვადის ამოწურვაზე გასვლას აირჩევთ, ერთეულს სჭირდება შესაბამისი გადატვირთვის პოლიტიკა და გასვლის სტატუსის დამუშავება, თორემ სიცოცხლისუნარიანობის ხარვეზი მუდმივ გაჩერებას ჰგავს. მდგრადობის პარამეტრებს ასევე შეუძლიათ ინტერფეისებისა და მარშრუტების შენარჩუნება შიდა გადატვირთვის განმავლობაში, მაგრამ არა პროცესის გასვლის განმავლობაში.
აირჩიეთ ერთი სიცოცხლის ციკლი თითოეული განლაგებისთვის და ჩაწერეთ რატომ. პროფილი, რომელსაც ორივე ინსტრუქცია აქვს, პროფილია, რომელსაც არ უწყვეტია.
გამოსცადეთ თითოეული ხარვეზი როგორც მისი საკუთარი შემთხვევა
დამტკიცებულ ფანჯარაში გაახილეთ ჩუმი პარტნიორი, მოკლული დემონი და მიუწვდომელი აპლიკაცია, შემდეგ შეამოწმეთ რომელი აღდგენა ამოქმედდა. ჩუმმა პარტნიორმა უნდა მოგვცეს შიდა ხელახალი დაკავშირება, მოკლულმა პროცესმა ერთეულის გადატვირთვა, ხოლო აპლიკაციის შეწყვეტამ არც ერთი მათგანი. როცა ორი შემთხვევა ერთსა და იმავე მოქმედებას იძლევა, მფლობელობა ჯერ კიდევ შერეულია.
განმეორებითი აღდგენა არც შეკეთებაა. უარყოფილი სერთიფიკატები ან ორი კლიენტი, რომლებიც ერთ ეფექტურ სახელს იზიარებენ, გააგრძელებენ ერთმანეთის ჩანაცვლებას და უფრო სწრაფი ტაიმერები მხოლოდ ამ რხევას აჩქარებს.