Nebula-certifikatets genindlæsning ændrede ikke IP’en: her er hvorfor

Du udsteder et nyt værtscertifikat med en anden overlay-adresse, kopierer det over den gamle fil, sender genindlæsningen, og værten fortsætter med at svare på den adresse, den havde før. Refleksen er at antage, at genindlæsningen mislykkedes, eller at den forkerte fil blev læst. Normalt skete ingen af delene: den kørende proces beholdt bevidst den identitet, den allerede havde, fordi erstatningen ændrede noget, som en genindlæsning ikke kan anvende.

Nebulas PKI-genindlæsning er dokumenteret med den grænse, og det er let at overse, når den samme dokumentation viser, at genindlæsning virker for andre ændringer.

Hvad en genindlæsning faktisk læser igen

Et værtscertifikat er ikke bare en legitimationsoplysning på den måde, en SSH-nøgle er. Det bærer overlay-adressen, værtsnavnet, gruppemedlemskaber og et gyldighedsvindue, og alt dette er bundet sammen af CA’ens signatur. Daemonen bruger det signerede indhold til at afgøre, hvordan den præsenterer sig, og hvilke regler der gælder for den.

Genindlæsning lader processen hente en fornyet legitimationsoplysning uden at tabe sine tunneler, hvilket er værdifuldt ved rutinemæssig rotation: samme adresse, samme navn, samme grupper, senere udløb. Begrænsningen er, at identiteten skal forblive den samme. Ændr overlay-adressen, og genindlæsningsvejen kan ikke anvende den, fordi adressen er en del af det, den kørende instans allerede har forpligtet sig til.

Så den adfærd, du så, er den dokumenterede grænse, der gør sit arbejde, ikke en tavs fejl. Filen på disken er ny; identiteten i hukommelsen er gammel; processen har ingen understøttet måde at forene den forskel uden en genstart.

Adresse, navn og grupper er én identitet

Det hjælper at tænke på certifikatet som én post i stedet for et sæt felter, du kan redigere uafhængigt. At flytte adressen er ikke som at ændre en præference, fordi adressen optræder i andre værts peer-konfigurationer, i tjenestebindinger og i politikker skrevet mod identiteten.

Grupper fortjener deres egen linje, fordi de forårsager en mere stille version af den samme forvirring. En vært, der beholder sin adresse, men skifter grupper, kan nå andre tjenester efter en genstart, og en test, der kun pinger den gamle adresse, vil se helt sund ud, mens adgangsbeslutninger er ændret under den. Kontroller én tjeneste omfattet af en regel, ikke kun tilgængelighed. Det er forskellen mellem at bekræfte tunnelen og bekræfte politikken.

Sammenlign det indlæste certifikat med erstatningen

Før du antager, at daemonen ignorerede filen, så læs begge. Udskriv det certifikat, du vil indlæse, og bekræft de felter, du tror, du ændrede, og bekræft derefter, at den kørende konfiguration peger på den sti og ikke på en kopi et andet sted.

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

Procesargumenterne betyder mere, end folk forventer. En unit, der sender -config /etc/nebula/config.yml, læser den fils pki.cert-post, og et certifikat installeret i en midlertidig mappe påvirker intet. Kontroller stien i den kørende kommandolinje, ikke stien i den dokumentation, du fulgte. Hvis de to er forskellige, har du fundet problemet uden at røre certifikatet.

Hvis det nye certifikat har en anden adresse, og processen beholdt den gamle, har du nu en forklaring i stedet for et mysterium. Genstart den, hvis det er acceptabelt, og behandl adresseændringen som en planlagt netværksændring og ikke en tilfældig.

En adresseændring er en netværksændring

Planlæg det, som du ville planlægge at flytte en maskine. Andre værter har måske låst den gamle adresse i deres konfiguration, tjenester binder måske eksplicit til den, og firewall-regler er måske skrevet mod den. At ændre certifikatet flytter værten, og at flytte værten ugyldiggør antagelser andre steder.

Hold en anden administrationsvej åben, mens du gør det, fordi overlay-forbindelsen måske er den, du afbryder. At gøre det over den tunnel, du er ved at bryde, er den klassiske måde at forvandle en fem minutters ændring til et besøg på stedet.

Om en genstart er acceptabel afhænger af, hvad værten laver, og det er et planlægningsspørgsmål snarere end et teknisk. Det, der ikke er valgfrit, er at anerkende genstarts-kravet i stedet for at sende genindlæsningen en femte gang.

Afvikl den gamle legitimationsoplysning separat

At installere en erstatning på én maskine efterlader hver peer med tillid til den legitimationsoplysning, den allerede kender. Hvis årsagen til ændringen var et kompromis, skal den gamle identitet afvikles via tillids- eller bloklisteproceduren, så peers faktisk afviser den.

Det er et separat skridt med sin egen verifikation: bekræft fra en anden vært, at den gamle identitet ikke længere virker, i stedet for at antage, at den nye fil gjorde arbejdet. Nebulas dokumentation for PKI-konfiguration dækker de indstillinger, der kan genindlæses, og adressebegrænsningen beskrevet her, og den er værd at læse i fuld længde, før du roterer noget produktionsrettet.