Ringarkimi i certifikatës Nebula nuk e ndryshoi IP-në: ja pse

Ju lëshoni një certifikatë të re hosti me një adresë tjetër overlay, e kopjoni mbi skedarin e vjetër, dërgoni ringarkimin, dhe hosti vazhdon të përgjigjet në adresën që kishte më parë. Refleksi është të supozoni se ringarkimi dështoi ose se u lexua skedari i gabuar. Zakonisht nuk ndodhi asnjëra: procesi që po ekzekutohet mbajti qëllimisht identitetin që kishte tashmë, sepse zëvendësimi ndryshoi diçka që një ringarkim nuk mund ta zbatojë.

Mbështetja e ringarkimit të PKI-së në Nebula është dokumentuar pikërisht me këtë kufi, dhe është e lehtë ta anashkalosh kur i njëjti dokumentacion tregon se ringarkimi funksionon për ndryshime të tjera.

Çfarë rilexon në të vërtetë një ringarkim

Një certifikatë hosti nuk është thjesht një kredencial siç është një çelës SSH. Ajo mban adresën overlay, emrin e hostit, anëtarësimet në grupe dhe një dritare vlefshmërie, dhe të gjitha këto lidhen nga nënshkrimi i CA-së. Daemoni përdor atë përmbajtje të nënshkruar për të vendosur si paraqitet dhe cilat rregulla zbatohen për të.

Ringarkimi lejon procesin të marrë kredenciale të ripërtërira pa i hedhur tunelet e tij, gjë që është e vlefshme për rrotullimin rutinë: e njëjta adresë, i njëjti emër, të njëjtat grupe, skadim më i vonë. Kufizimi është se identiteti duhet të mbetet i njëjtë. Ndryshoni adresën overlay dhe rruga e ringarkimit nuk mund ta zbatojë atë, sepse adresa është pjesë e asaj që instanca që po ekzekutohet është angazhuar tashmë.

Pra sjellja që patë është kufiri i dokumentuar që bën punën e vet, jo një dështim i heshtur. Skedari në disk është i ri; identiteti në memorie është i vjetër; procesi nuk ka një mënyrë të mbështetur për ta pajtuar atë diferencë pa rinisje.

Adresa, emri dhe grupet janë një identitet i vetëm

Ndihmon ta shohësh certifikatën si një regjistrim të vetëm dhe jo si një grup fushash që mund t’i editosh veçmas. Zhvendosja e adresës nuk është si ndryshimi i një preference, sepse adresa shfaqet në konfigurimet e partnerëve të hosteve të tjera, në lidhjet e shërbimeve dhe në politikat e shkruara kundër identitetit.

Grupet meritojnë rreshtin e tyre sepse shkaktojnë një version më të qetë të së njëjtës konfuzion. Një host që mban adresën por ndryshon grupet mund të arrijë shërbime të tjera pas rinisjes, dhe një test që bën vetëm ping në adresën e vjetër do të duket plotësisht i shëndetshëm ndërsa vendimet e aksesit kanë ndryshuar poshtë tij. Kontrollo një shërbim të rregulluar nga një rregull, jo vetëm arritshmërinë. Ky është ndryshimi midis konfirmimit të tunelit dhe konfirmimit të politikës.

Krahasoni certifikatën e ngarkuar me zëvendësuesin

Përpara se të supozoni që daemoni e injoroi skedarin, lexoni të dyja. Printoni certifikatën që synoni të ngarkoni dhe konfirmoni fushat që mendoni se i ndryshuat, pastaj konfirmoni që konfigurimi që po ekzekutohet tregon atë rrugë dhe jo një kopje diku tjetër.

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

Argumentet e procesit kanë më shumë rëndësi sesa presin njerëzit. Një njësi që kalon -config /etc/nebula/config.yml lexon hyrjen pki.cert të atij skedari, dhe një certifikatë e instaluar në një drejtori të përkohshme nuk ndikon në asgjë. Kontrollo rrugën në rreshtin e komandës që po ekzekutohet, jo rrugën në dokumentacionin që ndoqët. Nëse të dyja ndryshojnë, e keni gjetur problemin pa e prekur fare certifikatën.

Nëse certifikata e re ka një adresë tjetër dhe procesi mbajti të vjetrën, tani keni një shpjegim dhe jo një mister. Rinisni atë nëse është e pranueshme, dhe trajtojeni ndryshimin e adresës si një ndryshim rrjeti të planifikuar dhe jo aksidental.

Ndryshimi i adresës është ndryshim rrjeti

Planifikojeni ashtu siç do të planifikonit zhvendosjen e një makine. Hostet e tjera mund ta kenë fiksuar adresën e vjetër në konfigurimin e tyre, shërbimet mund të lidhen në mënyrë eksplicite me të, dhe rregullat e murit të zjarrit mund të jenë shkruar kundër saj. Ndryshimi i certifikatës e zhvendos hostin, dhe zhvendosja e hostit i bën të pavlefshme supozimet diku tjetër.

Mbani një rrugë të dytë administrimi të disponueshme ndërsa e bëni këtë, sepse lidhja overlay mund të jetë pikërisht ajo që po ndërhyni. Ta bësh këtë përmes tunelit që jeni gati për ta thyer është mënyra klasike për ta kthyer një ndryshim pesëminutësh në një vizitë në vend.

Nëse një rinisje është e pranueshme varet nga ajo që po bën hosti, dhe ky është një problem planifikimi, jo teknik. Ajo që nuk është opsionale është ta pranosh kërkesën për rinisje në vend që të dërgosh ringarkimin për herë të pestë.

Tërhiqni kredencialet e vjetra veçmas

Instalimi i një zëvendësuesi në një makinë të vetme lë çdo partner të vazhdojë t’i besojë kredencialit që njeh tashmë. Nëse arsyeja e ndryshimit ishte një kompromis, identiteti i vjetër duhet të tërhiqet përmes procedurës së besimit ose listës së bllokimit, që partnerët ta refuzojnë vërtet.

Ky është një hap i veçantë me verifikimin e vet: konfirmo nga një host tjetër se identiteti i vjetër nuk funksionon më, në vend që të supozosh se skedari i ri e bëri punën. Dokumentacioni i konfigurimit të PKI-së së Nebula mbulon cilësimet e ringarkueshme dhe kufizimin e adresës të përshkruar këtu, dhe ia vlen ta lexosh plotësisht përpara se të rrotullosh çdo gjë në prodhim.