Omlastingen av Nebula-sertifikatet endret ikke IP-adressen: her er grunnen

Du utsteder et nytt vertssertifikat med en annen overlay-adresse, kopierer det over den gamle filen, sender omlastingen, og verten fortsetter å svare på adressen den hadde tidligere. Den intuitive reaksjonen er å tro at omlastingen feilet eller at feil fil ble lest. Som regel skjedde ingen av delene: den kjørende prosessen beholdt med vilje identiteten den allerede hadde, fordi erstatningen endret noe som en omlasting ikke kan anvende.

Nebulas støtte for PKI-omlasting er dokumentert med denne grensen, og den er lett å overse når den samme dokumentasjonen viser at omlasting virker for andre endringer.

Hva en omlasting egentlig leser på nytt

Et vertssertifikat er ikke bare en legitimasjon slik en SSH-nøkkel er. Det inneholder overlay-adressen, vertsnavnet, gruppemedlemskapene og et gyldighetsvindu, og alt dette er knyttet sammen av CA-ens signatur. Daemonen bruker det signerte innholdet til å avgjøre hvordan den presenterer seg og hvilke regler som gjelder for den.

Omlasting lar prosessen ta i bruk fornyet legitimasjon uten å miste tunnelene sine, noe som er verdifullt ved rutinemessig rotasjon: samme adresse, samme navn, samme grupper, senere utløp. Begrensningen er at identiteten må forbli uendret. Endrer du overlay-adressen, kan ikke omlastingsveien anvende den, fordi adressen er en del av det den kjørende instansen allerede har forpliktet seg til.

Atferden du observerte er altså den dokumenterte grensen som gjør jobben sin, ikke en stille feil. Filen på disken er ny; identiteten i minnet er gammel; prosessen har ingen støttet måte å forene denne forskjellen på uten omstart.

Adresse, navn og grupper er én identitet

Det hjelper å betrakte sertifikatet som én oppføring i stedet for et sett med felt du kan redigere uavhengig. Å flytte adressen er ikke som å endre en innstilling, fordi adressen forekommer i andre verters peer-konfigurasjoner, i tjenestebindinger og i retningslinjer skrevet mot identiteten.

Grupper fortjener sin egen linje fordi de forårsaker en stillere variant av den samme forvirringen. En vert som beholder adressen men bytter grupper, kan nå andre tjenester etter en omstart, og en test som bare pinger den gamle adressen vil se helt frisk ut mens tilgangsbeslutningene har endret seg under den. Kontroller én tjeneste som dekkes av en regel, ikke bare tilgjengeligheten. Det er forskjellen mellom å bekrefte tunnelen og å bekrefte retningslinjen.

Sammenlign det innleste sertifikatet med erstatningen

Før du antar at daemonen ignorerte filen, les begge. Skriv ut sertifikatet du vil laste inn, og bekreft feltene du tror du endret, og bekreft deretter at den kjørende konfigurasjonen peker på den stien og ikke på en kopi et annet sted.

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

Prosessargumentene betyr mer enn folk forventer. En enhet som sender -config /etc/nebula/config.yml, leser pki.cert-oppføringen i den filen, og et sertifikat som er installert i en midlertidig mappe påvirker ingenting. Kontroller stien i den kjørende kommandolinjen, ikke stien i dokumentasjonen du fulgte. Hvis de to er forskjellige, har du funnet problemet uten å berøre sertifikatet i det hele tatt.

Hvis det nye sertifikatet har en annen adresse og prosessen beholdt den gamle, har du nå en forklaring i stedet for et mysterium. Start den på nytt hvis det er akseptabelt, og behandle adresseendringen som en planlagt nettverksendring og ikke en tilfeldig.

En adresseendring er en nettverksendring

Planlegg det slik du ville planlagt å flytte en maskin. Andre verter har kanskje låst den gamle adressen i konfigurasjonen sin, tjenester kan binde seg eksplisitt til den, og brannmurregler kan være skrevet mot den. Å endre sertifikatet flytter verten, og å flytte verten gjør antakelser andre steder ugyldige.

Hold en andre administrasjonsvei tilgjengelig mens du gjør dette, fordi overlay-forbindelsen kan være nettopp den du avbryter. Å gjøre dette over tunnelen du er i ferd med å bryte, er den klassiske måten å gjøre en fem minutters endring om til et besøk på stedet.

Om en omstart er akseptabel avhenger av hva verten gjør, og det er et planleggingsspørsmål, ikke et teknisk. Det som ikke er valgfritt, er å anerkjenne omstartskravet i stedet for å sende omlastingen en femte gang.

Avvikle den gamle legitimasjonen separat

Å installere en erstatning på én maskin lar hver peer fortsatt stole på legitimasjonen den allerede kjenner. Hvis årsaken til endringen var et kompromiss, må den gamle identiteten avvikles gjennom tillits- eller blokklisteprosedyren, slik at peerne faktisk avviser den.

Det er et eget trinn med egen verifisering: bekreft fra en annen vert at den gamle identiteten ikke lenger fungerer, i stedet for å anta at den nye filen gjorde jobben. Nebulas dokumentasjon for PKI-konfigurasjon dekker innstillingene som kan lastes på nytt og adressebegrensningen som er beskrevet her, og den er verdt å lese i sin helhet før du roterer noe produksjonsrettet.