Nebula-ს სერტიფიკატის გადატვირთვამ IP არ შეცვალა: აი რატომ
გადატვირთვა ჰოსტის სერტიფიკატს ხელახლა კითხულობს მხოლოდ მაშინ, როცა overlay-მისამართი იგივე რჩება. მისამართის შეცვლა ნიშნავს გადატვირთვას და ქსელის ცვლილებას, და არა ხელახალ ცდას.
თქვენ გასცემთ ახალ ჰოსტის სერტიფიკატს სხვა overlay-მისამართით, აკოპირებთ მას ძველ ფაილზე, აგზავნით გადატვირთვას და ჰოსტი კვლავ პასუხობს იმ მისამართზე, რაც ადრე ჰქონდა. რეფლექსია ვიფიქროთ, რომ გადატვირთვა ჩავარდა ან არასწორი ფაილი წაიკითხა. ჩვეულებრივ არც ერთი მომხდარა: გაშვებულმა პროცესმა განზრახ შეინარჩუნა ის იდენტობა, რომელიც უკვე ჰქონდა, რადგან ჩანაცვლებამ შეცვალა ის, რასაც გადატვირთვა ვერ გამოიყენებს.
Nebula-ს PKI გადატვირთვის მხარდაჭერა სწორედ ამ საზღვრითაა დოკუმენტირებული და ადვილი გამოსაშვებია, როცა იგივე დოკუმენტაცია გვიჩვენებს, რომ გადატვირთვა სხვა ცვლილებებზე მუშაობს.
რას კითხულობს გადატვირთვა სინამდვილეში ხელახლა
ჰოსტის სერტიფიკატი მხოლოდ სერტიფიკატი არ არის ისე, როგორც SSH გასაღები. ის ატარებს overlay-მისამართს, ჰოსტის სახელს, ჯგუფურ წევრობას და მოქმედების ფანჯარას, და ეს ყველაფერი CA-ს ხელმოწერითაა დაკავშირებული. დემონი იყენებს ამ ხელმოწერილ შიგთავსს იმის გადასაწყვეტად, როგორ წარმოადგინოს თავი და რომელი წესები ვრცელდება მასზე.
გადატვირთვა საშუალებას აძლევს პროცესს მიიღოს განახლებული სერტიფიკატი თავისი გვირაბების დაკარგვის გარეშე, რაც ღირებულია ჩვეულებრივი როტაციისთვის: იგივე მისამართი, იგივე სახელი, იგივე ჯგუფები, უფრო გვიანი ვადა. შეზღუდვა ის არის, რომ იდენტობა უნდა დარჩეს იგივე. შეცვალეთ overlay-მისამართი და გადატვირთვის გზა ვერ გამოიყენებს მას, რადგან მისამართი იმის ნაწილია, რაზეც გაშვებულმა ინსტანციამ უკვე აიღო ვალდებულება.
ამრიგად, თქვენ მიერ ნანახი ქცევა დოკუმენტირებული შეზღუდვაა, რომელიც თავის საქმეს აკეთებს, და არა ჩუმი ჩავარდნა. დისკზე ფაილი ახალია; მეხსიერებაში იდენტობა ძველია; პროცესს გადატვირთვის გარეშე ამ სხვაობის შესათანხმებლად მხარდაჭერილი გზა არ აქვს.
მისამართი, სახელი და ჯგუფები ერთი იდენტობაა
სასარგებლოა სერტიფიკატზე ვიფიქროთ როგორც ერთ ჩანაწერზე და არა როგორც დამოუკიდებლად რედაქტირებადი ველების ერთობლიობაზე. მისამართის გადატანა არ ჰგავს პარამეტრის შეცვლას, რადგან მისამართი ჩნდება სხვა ჰოსტების peer-კონფიგურაციებში, სერვისების მიბმებში და იდენტობის საწინააღმდეგოდ დაწერილ პოლიტიკებში.
| Field | What changes when you replace it |
|---|---|
| Overlay address | Peers that pinned the old address, service bindings, and any rule written against it |
| Host name | Name-based policy and the identities other hosts expect to see |
| Groups | Which access rules match, even if the address stays identical |
| Validity window | Nothing structural, which is why renewal reloads cleanly |
ჯგუფები ცალკე ხაზს იმსახურებენ, რადგან იწვევენ იმავე დაბნეულობის უფრო ჩუმ ვერსიას. ჰოსტი, რომელიც ინარჩუნებს მისამართს, მაგრამ ჯგუფს იცვლის, გადატვირთვის შემდეგ შეიძლება სხვა სერვისებს მიაღწიოს, და ტესტი, რომელიც მხოლოდ ძველ მისამართს pings, სრულიად ჯანმრთელად გამოჩნდება, თუმცა ქვემოთ წვდომის გადაწყვეტილებები შეიცვალა. შეამოწმეთ წესით დაფარული ერთი სერვისი და არა მხოლოდ ხელმისაწვდომობა. ეს არის განსხვავება გვირაბის დადასტურებასა და პოლიტიკის დადასტურებას შორის.
შეადარეთ ჩატვირთული სერტიფიკატი ჩანაცვლებას
სანამ იფიქრებთ, რომ დემონმა ფაილი უგულებელყო, წაიკითხეთ ორივე. დაბეჭდეთ სერტიფიკატი, რომლის ჩატვირთვასაც აპირებთ, და დაადასტურეთ ის ველები, რომლებიც, თქვენი აზრით, შეცვალეთ, შემდეგ დაადასტურეთ, რომ გაშვებული კონფიგურაცია სწორედ ამ გზაზე მიუთითებს და არა სხვაგან არსებულ ასლზე.
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)პროცესის არგუმენტებს უფრო დიდი მნიშვნელობა აქვს, ვიდრე ხალხი ელის. ერთეული, რომელიც გადასცემს -config /etc/nebula/config.yml-ს, კითხულობს იმ ფაილის pki.cert ჩანაწერს, და დროებით საქაღალდეში ჩადგმული სერტიფიკატი არაფერზე გავლენას არ ახდენს. შეამოწმეთ გზა გაშვებულ ბრძანების სტრიქონში და არა იმ დოკუმენტაციაში, რომელსაც მიჰყევით. თუ ორივე განსხვავდება, თქვენ იპოვეთ პრობლემა სერტიფიკატზე ხელის შეხების გარეშე.
თუ ახალ სერტიფიკატს სხვა მისამართი აქვს და პროცესმა ძველი შეინარჩუნა, ახლა განმარტება გაქვთ და არა გამოცანა. გადატვირთეთ ის, თუ ეს მისაღებია, და მისამართის ცვლილებას მოეპყარით როგორც დაგეგმილ ქსელურ ცვლილებას და არა შემთხვევითს.
მისამართის ცვლილება ქსელის ცვლილებაა
დაგეგმეთ ისე, როგორც მანქანის გადატანას დაგეგმავდით. სხვა ჰოსტებმა შეიძლება ძველი მისამართი ჩაამაგრეს თავიანთ კონფიგურაციაში, სერვისები შეიძლება ცხადად მიბმული იყოს მასზე, და firewall-ის წესები შეიძლება მის საწინააღმდეგოდ იყოს დაწერილი. სერტიფიკატის შეცვლა ჰოსტს გადაადგილებს, ხოლო ჰოსტის გადაადგილება სხვაგან არსებულ ვარაუდებს ბათილად აქცევს.
ამის კეთებისას ხელმისაწვდომად შეინახეთ მართვის მეორე გზა, რადგან შესაძლოა სწორედ overlay-კავშირი წყვეტდეთ. ამის გაკეთება იმ გვირაბის გავლით, რომლის გატეხვასაც აპირებთ, ხუთწუთიანი ცვლილების ადგილზე ვიზიტად გადაქცევის კლასიკური გზაა.
გადატვირთვის მისაღებობა დამოკიდებულია იმაზე, რას აკეთებს ჰოსტი, და ეს ტექნიკური კი არა, დაგეგმვის საკითხია. სავალდებულოა გადატვირთვის მოთხოვნის აღიარება იმის ნაცვლად, რომ გადატვირთვა მეხუთედ გააგზავნოთ.
ძველი სერტიფიკატი ცალკე გააუქმეთ
ერთ მანქანაზე ჩანაცვლების დაყენება ტოვებს იმას, რომ ყოველი peer კვლავ ენდობა იმ სერტიფიკატს, რომელიც უკვე იცის. თუ ცვლილების მიზეზი კომპრომიტირება იყო, ძველი იდენტობა უნდა გაუქმდეს ნდობის ან ბლოკ-სიის პროცედურით, რათა peer-ებმა ის ნამდვილად უარყონ.
ეს ცალკე ნაბიჯია თავისი შემოწმებით: სხვა ჰოსტიდან დაადასტურეთ, რომ ძველი იდენტობა აღარ მუშაობს, იმის ნაცვლად რომ იფიქროთ, თითქოს ახალმა ფაილმა საქმე გააკეთა. Nebula-ს PKI კონფიგურაციის დოკუმენტაცია მოიცავს გადატვირთვად პარამეტრებს და აქ აღწერილ მისამართის შეზღუდვას, და ღირს მისი სრულად წაკითხვა სანამ რაიმე საწარმოო გარემოში მოაბრუნებთ.