Omlasting av Nebula-sertifikatet endra ikkje IP-en: her er kvifor

Du gir ut eit nytt vertssertifikat med ei anna overlay-adresse, kopierer det over den gamle fila, sender omlastinga, og verten held fram med å svare på adressa han hadde før. Refleksen er å tru at omlastinga mislukkast eller at feil fil vart lesen. Vanlegvis skjedde ingen av delane: den køyrande prosessen heldt medvite på identiteten han allereie hadde, fordi erstatninga endra noko ei omlasting ikkje kan bruke.

Nebula sin støtte for omlasting av PKI er dokumentert med denne grensa, og det er lett å oversjå når den same dokumentasjonen viser at omlasting fungerer for andre endringar.

Kva ei omlasting faktisk les på nytt

Eit vertssertifikat er ikkje berre ein legitimasjon slik ein SSH-nøkkel er. Det ber overlay-adressa, vertsnamnet, gruppemedlemskapa og eit gyldigheitsvindauge, og alt dette er bunde saman av signaturen til CA-en. Daemonen brukar det signerte innhaldet til å avgjere korleis han presenterer seg og kva reglar som gjeld for han.

Omlasting lèt prosessen hente fornya legitimasjon utan å miste tunnelane sine, noko som er verdifullt ved rutinemessig rotasjon: same adresse, same namn, same grupper, seinare utløp. Skilnaden er at identiteten må halde seg lik. Endrar du overlay-adressa, kan ikkje omlastingsvegen bruke henne, fordi adressa er ein del av det den køyrande instansen allereie har forplikta seg til.

Så åtferda du såg er den dokumenterte grensa som gjer jobben sin, ikkje ein stille feil. Fila på disken er ny; identiteten i minnet er gammal; prosessen har ingen støtta måte å sameine den skilnaden på utan omstart.

Adresse, namn og grupper er éin identitet

Det hjelper å tenkje på sertifikatet som ein post i staden for eit sett felt du kan endre kvar for seg. Å flytte adressa er ikkje som å endre ei innstilling, fordi adressa finst i peer-konfigurasjonane til andre vertar, i tenestebindingar og i policyar skrivne mot identiteten.

Grupper fortener si eiga line fordi dei skapar ein stillare versjon av den same forvirringa. Ein vert som held på adressa men byter grupper, kan nå andre tenester etter ein omstart, og ein test som berre pingar den gamle adressa vil sjå heilt sunn ut medan tilgangsavgjerdene har endra seg under han. Kontroller éi teneste som er dekt av ei regel, ikkje berre tilgjenge. Det er skilnaden mellom å stadfeste tunnelen og å stadfeste policyen.

Samanlikn det innlasta sertifikatet med erstatninga

Før du trur at daemonen ignorerte fila, les båe. Skriv ut sertifikatet du vil laste inn, og stadfest felta du trur du endra, og stadfest deretter at den køyrande konfigurasjonen peikar på den vegen og ikkje på ein kopi ein annan stad.

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

Prosessargumenta tyder meir enn folk ventar. Ei eining som sender -config /etc/nebula/config.yml, les pki.cert-oppføringa i den fila, og eit sertifikat installert i ein mellombels mappe påverkar ingenting. Kontroller vegen i den køyrande kommandolinja, ikkje vegen i dokumentasjonen du følgde. Viss dei to er ulike, har du funne problemet utan å røre sertifikatet i det heile.

Viss det nye sertifikatet har ei anna adresse og prosessen heldt på den gamle, har du no ei forklaring i staden for eit mysterium. Start han på nytt om det er akseptabelt, og handsam adresseendringa som ei planlagd nettverksendring og ikkje ei tilfeldig.

Ei adresseendring er ei nettverksendring

Planlegg det slik du ville planlagt å flytte ein maskin. Andre vertar har kanskje festa den gamle adressa i konfigurasjonen sin, tenester kan binde seg eksplisitt til henne, og brannmurreglar kan vere skrivne mot henne. Å endre sertifikatet flyttar verten, og å flytte verten gjer antakingar andre stader ugyldige.

Hald ein andre administrasjonsveg tilgjengeleg medan du gjer dette, fordi overlay-sambandet kan vere nettopp det du avbryt. Å gjere dette over tunnelen du er i ferd med å bryte, er den klassiske måten å gjere ei fem minutts endring om til eit besøk på staden.

Om ein omstart er akseptabel avheng av kva verten gjer, og det er eit planleggingsspørsmål, ikkje eit teknisk. Det som ikkje er valfritt, er å anerkjenne omstartskravet i staden for å sende omlastinga ein femte gong.

Avvikle den gamle legitimasjonen separat

Å installere ein erstatning på éin maskin lèt kvar peer framleis stole på legitimasjonen han allereie kjenner. Viss årsaka til endringa var eit kompromiss, må den gamle identiteten avviklast gjennom tillits- eller blokklisteprosedyren, slik at peerane faktisk avviser han.

Det er eit eige steg med si eiga stadfesting: stadfest frå ein annan vert at den gamle identiteten ikkje lenger fungerer, i staden for å tru at den nye fila gjorde jobben. Nebula sin dokumentasjon for PKI-konfigurasjon dekkjer innstillingane som kan lastast på nytt og adresseavgrensinga som er skildra her, og han er verdt å lese i sin heilskap før du roterer noko produksjonsretta.