Omladdningen av Nebula-certifikatet ändrade inte IP-adressen: här är varför

Du utfärdar ett nytt värdcertifikat med en annan overlay-adress, kopierar det över den gamla filen, skickar omladdningen, och värden fortsätter att svara på adressen den hade tidigare. Refleksen är att anta att omladdningen misslyckades eller att fel fil lästes. Vanligtvis hände inget av detta: den körande processen behöll medvetet den identitet den redan hade, eftersom ersättningen ändrade något som en omladdning inte kan tillämpa.

Nebulas stöd för PKI-omladdning är dokumenterat med den gränsen, och det är lätt att missa när samma dokumentation visar att omladdning fungerar för andra ändringar.

Vad en omladdning faktiskt läser om

Ett värdcertifikat är inte bara en autentiseringsuppgift så som en SSH-nyckel är. Det bär overlay-adressen, värdnamnet, gruppmedlemskapen och ett giltighetsfönster, och allt detta binds samman av CA:ns signatur. Daemonen använder det signerade innehållet för att avgöra hur den presenterar sig och vilka regler som gäller för den.

Omladdning låter processen hämta förnyade autentiseringsuppgifter utan att tappa sina tunnlar, vilket är värdefullt vid rutinmässig rotation: samma adress, samma namn, samma grupper, senare utgång. Begränsningen är att identiteten måste förbli densamma. Ändra overlay-adressen och omladdningsvägen kan inte tillämpa den, eftersom adressen är en del av det som den körande instansen redan har förbundit sig till.

Så beteendet du såg är den dokumenterade gränsen som gör sitt jobb, inte ett tyst fel. Filen på disken är ny; identiteten i minnet är gammal; processen har inget stött sätt att förena den skillnaden utan omstart.

Adress, namn och grupper är en identitet

Det hjälper att se certifikatet som en enda post i stället för en uppsättning fält du kan redigera oberoende. Att flytta adressen är inte som att ändra en inställning, eftersom adressen förekommer i andra värdars peer-konfigurationer, i tjänstebindningar och i policyer skrivna mot identiteten.

Grupper förtjänar en egen rad eftersom de orsakar en tystare version av samma förvirring. En värd som behåller adressen men byter grupper kan nå andra tjänster efter en omstart, och ett test som bara pingar den gamla adressen ser helt frisk ut medan åtkomstbesluten har ändrats under den. Kontrollera en tjänst som omfattas av en regel, inte bara nåbarheten. Det är skillnaden mellan att bekräfta tunneln och att bekräfta policyn.

Jämför det inlästa certifikatet med ersättningen

Innan du antar att daemonen ignorerade filen, läs båda. Skriv ut certifikatet du tänker läsa in och bekräfta fälten du tror du ändrade, bekräfta sedan att den körande konfigurationen pekar på den sökvägen och inte på en kopia någon annanstans.

nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)

Processargumenten spelar större roll än folk förväntar sig. En enhet som skickar -config /etc/nebula/config.yml läser posten pki.cert i den filen, och ett certifikat installerat i en tillfällig katalog påverkar ingenting. Kontrollera sökvägen i den körande kommandoraden, inte sökvägen i dokumentationen du följde. Om de två skiljer sig har du hittat problemet utan att ens röra certifikatet.

Om det nya certifikatet har en annan adress och processen behöll den gamla, har du nu en förklaring i stället för ett mysterium. Starta om den om det är acceptabelt, och behandla adressändringen som en planerad nätverksändring och inte en oavsiktlig.

En adressändring är en nätverksändring

Planera det som du skulle planera att flytta en maskin. Andra värdar kan ha fäst den gamla adressen i sin konfiguration, tjänster kan binda sig uttryckligen till den, och brandväggsregler kan vara skrivna mot den. Att ändra certifikatet flyttar värden, och att flytta värden ogiltigförklarar antaganden någon annanstans.

Håll en andra administrationsväg tillgänglig medan du gör detta, eftersom overlay-anslutningen kan vara precis den du avbryter. Att göra det över tunneln du är på väg att bryta är det klassiska sättet att förvandla en femminutersändring till ett besök på plats.

Om en omstart är acceptabel beror på vad värden gör, och det är en planeringsfråga, inte en teknisk. Det som inte är valfritt är att erkänna omstartskravet i stället för att skicka omladdningen en femte gång.

Avveckla den gamla autentiseringsuppgiften separat

Att installera en ersättning på en enda maskin lämnar varje peer fortfarande litande på den autentiseringsuppgift den redan känner till. Om orsaken till ändringen var en kompromiss måste den gamla identiteten avvecklas genom tillits- eller blockeringslistproceduren så att peerarna faktiskt avvisar den.

Det är ett eget steg med egen verifiering: bekräfta från en annan värd att den gamla identiteten inte längre fungerar, i stället för att anta att den nya filen gjorde jobbet. Nebulas dokumentation för PKI-konfiguration täcker inställningarna som kan laddas om och adressbegränsningen som beskrivs här, och den är värd att läsa i sin helhet innan du roterar något produktionsnära.