A Nebula tanúsítvány újratöltése nem változtatta meg az IP-t: ez az oka
Az újratöltés csak akkor olvassa újra a gazdagép hitelesítő adatait, ha az overlay-cím ugyanaz marad. A cím módosítása újraindítást és hálózati változtatást jelent, nem újrapróbálkozást.
Új gazdagép-tanúsítványt ad ki másik overlay-címmel, átmásolja a régi fájl fölé, elküldi az újratöltést, és a gazdagép továbbra is a korábbi címen válaszol. A reflex az, hogy azt feltételezi: az újratöltés meghiúsult, vagy rossz fájlt olvasott be. Általában egyik sem történt meg: a futó folyamat szándékosan megtartotta a már meglévő identitását, mert a csere olyasmit változtatott meg, amit az újratöltés nem tud alkalmazni.
A Nebula PKI újratöltési támogatása ezzel a korláttal együtt van dokumentálva, és könnyű elsiklani felette, amikor ugyanaz a dokumentáció azt mutatja, hogy az újratöltés más változtatásoknál működik.
Mit olvas újra valójában az újratöltés
A gazdagép-tanúsítvány nem csupán hitelesítő adat, ahogyan egy SSH-kulcs az. Hordozza az overlay-címet, a gazdagép nevét, a csoporttagságokat és az érvényességi ablakot, és mindezt a CA aláírása köti össze. A démon ezt az aláírt tartalmat használja annak eldöntésére, hogyan mutatkozik be, és milyen szabályok vonatkoznak rá.
Az újratöltés lehetővé teszi, hogy a folyamat a csatornái eldobása nélkül vegyen át megújított hitelesítő adatot, ami rutinszerű rotációhoz értékes: ugyanaz a cím, ugyanaz a név, ugyanazok a csoportok, későbbi lejárat. A megszorítás az, hogy az identitásnak ugyanannak kell maradnia. Változtassa meg az overlay-címet, és az újratöltési útvonal nem tudja alkalmazni, mert a cím része annak, amire a futó példány már elkötelezte magát.
A látott viselkedés tehát a dokumentált korlát, amely végzi a dolgát, nem csendes hiba. A lemezen lévő fájl új; a memóriában lévő identitás régi; a folyamatnak nincs támogatott módja ennek a különbségnek az összeegyeztetésére újraindítás nélkül.
A cím, a név és a csoportok egyetlen identitás
Segít a tanúsítványra egyetlen rekordként tekinteni, nem függetlenül szerkeszthető mezők halmazaként. A cím áthelyezése nem olyan, mint egy beállítás megváltoztatása, mert a cím megjelenik más gazdagépek peer-konfigurációiban, a szolgáltatáskötésekben és az identitás ellen írt házirendekben.
| 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 |
A csoportok saját sort érdemelnek, mert ugyanannak a zavarnak a halkabb változatát okozzák. Egy gazdagép, amely megtartja a címét, de csoportot vált, újraindítás után más szolgáltatásokat érhet el, és egy teszt, amely csak a régi címre pingel, teljesen egészségesnek látszik, miközben a hozzáférési döntések alatta megváltoztak. Egy szabály alá eső szolgáltatást ellenőrizzen, ne csak az elérhetőséget. Ez a különbség az alagút megerősítése és a házirend megerősítése között.
Hasonlítsa össze a betöltött tanúsítványt a cserével
Mielőtt feltételezné, hogy a démon figyelmen kívül hagyta a fájlt, olvassa el mindkettőt. Nyomtassa ki a betölteni kívánt tanúsítványt, és erősítse meg azokat a mezőket, amelyeket megváltoztatott, majd erősítse meg, hogy a futó konfiguráció arra az útvonalra mutat, nem egy máshol lévő másolatra.
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)A folyamat argumentumai fontosabbak, mint ahogy az emberek várják. Egy olyan unit, amely átadja a -config /etc/nebula/config.yml beállítást, annak a fájlnak a pki.cert bejegyzését olvassa, és az ideiglenes könyvtárba telepített tanúsítvány semmire sincs hatással. A futó parancssorban lévő útvonalat ellenőrizze, ne az általa követett dokumentációban lévőt. Ha a kettő eltér, a tanúsítvány megérintése nélkül megtalálta a problémát.
Ha az új tanúsítványnak más a címe, és a folyamat megtartotta a régit, most már magyarázata van rejtély helyett. Indítsa újra, ha ez elfogadható, és kezelje a címváltozást tervezett hálózati változásként, nem véletlenként.
A címváltozás hálózati változás
Úgy tervezze meg, ahogy egy gép áthelyezését tervezné. Más gazdagépek esetleg rögzítették a régi címet a konfigurációjukban, a szolgáltatások kifejezetten hozzá kötődhetnek, és a tűzfal-szabályok ellene lehetnek megírva. A tanúsítvány megváltoztatása áthelyezi a gazdagépet, a gazdagép áthelyezése pedig érvényteleníti a máshol élő feltevéseket.
Tartson elérhetően egy második felügyeleti útvonalat, miközben ezt teszi, mert lehet, hogy éppen az overlay-kapcsolatot szakítja meg. Ezt azon az alagúton keresztül megtenni, amelyet éppen el fog törni, klasszikus módja annak, hogy egy ötperces változtatásból helyszíni látogatás legyen.
Az, hogy elfogadható-e az újraindítás, attól függ, mit tesz a gazdagép, és ez ütemezési, nem technikai kérdés. Ami nem opcionális, az az újraindítási követelmény elismerése az újratöltés ötödik elküldése helyett.
A régi hitelesítő adatot külön vonja vissza
Egyetlen gépre telepített csere után minden peer továbbra is megbízik a már ismert hitelesítő adatban. Ha a változtatás oka kompromittálódás volt, a régi identitást a bizalmi vagy blokklista-eljárással kell visszavonni, hogy a peerok valóban elutasítsák.
Ez külön lépés, saját ellenőrzéssel: egy másik gazdagépről erősítse meg, hogy a régi identitás már nem működik, ahelyett hogy feltételezné, hogy az új fájl elvégezte a munkát. A Nebula PKI-konfigurációs dokumentációja kiterjed az újratölthető beállításokra és az itt leírt címkorlátra, és érdemes teljes egészében elolvasni, mielőtt bármit rotálna éles környezetben.