Nebula-varmenneen uudelleenlataus ei muuttanut IP-osoitetta: tässä syy
Uudelleenlataus lukee isännän tunnistetiedot uudelleen vain, kun overlay-osoite pysyy samana. Osoitteen vaihtaminen tarkoittaa uudelleenkäynnistystä ja verkon muutosta, ei uutta yritystä.
Myönnät uuden isäntävarmenneen eri overlay-osoitteella, kopioit sen vanhan tiedoston päälle, lähetät uudelleenlatauksen, ja isäntä vastaa edelleen osoitteessa, joka sillä oli aiemmin. Vaistomainen oletus on, että uudelleenlataus epäonnistui tai että luettiin väärä tiedosto. Yleensä kumpikaan ei tapahtunut: käynnissä oleva prosessi säilytti tarkoituksella identiteetin, joka sillä jo oli, koska korvaava tiedosto muutti jotain, mitä uudelleenlataus ei voi soveltaa.
Nebulan PKI:n uudelleenlataustuki on dokumentoitu tämän rajan kanssa, ja se on helppo ohittaa, kun sama dokumentaatio näyttää uudelleenlatauksen toimivan muiden muutosten kohdalla.
Mitä uudelleenlataus todella lukee uudelleen
Isäntävarmenne ei ole vain tunnistetieto samalla tavalla kuin SSH-avain. Se kantaa overlay-osoitteen, isäntänimen, ryhmäjäsenyydet ja voimassaoloikkunan, ja kaikki nämä on sidottu yhteen CA:n allekirjoituksella. Daemon käyttää tätä allekirjoitettua sisältöä päättääkseen, miten se esittäytyy ja mitkä säännöt siihen pätevät.
Uudelleenlataus antaa prosessin ottaa käyttöön uusitun tunnistetiedon pudottamatta tunneleitaan, mikä on arvokasta rutiininomaisessa kierrätyksessä: sama osoite, sama nimi, samat ryhmät, myöhempi vanheneminen. Rajoitus on, että identiteetin on pysyttävä samana. Vaihda overlay-osoite, eikä uudelleenlatauspolku voi soveltaa sitä, koska osoite on osa sitä, mihin käynnissä oleva instanssi on jo sitoutunut.
Näkemäsi käytös on siis dokumentoitu raja työtään tekemässä, ei äänetön epäonnistuminen. Levyllä oleva tiedosto on uusi; muistissa oleva identiteetti on vanha; prosessilla ei ole tuettua tapaa sovittaa tätä eroa ilman uudelleenkäynnistystä.
Osoite, nimi ja ryhmät ovat yksi identiteetti
Auttaa ajatella varmennetta yhtenä tietueena eikä joukkona kenttiä, joita voi muokata erikseen. Osoitteen siirtäminen ei ole kuin asetuksen muuttaminen, koska osoite esiintyy muiden isäntien peer-kokoonpanoissa, palvelusidoksissa ja identiteettiä vastaan kirjoitetuissa käytännöissä.
| 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 |
Ryhmät ansaitsevat oman rivinsä, koska ne aiheuttavat hiljaisemman version samasta sekaannuksesta. Isäntä, joka pitää osoitteensa mutta vaihtaa ryhmiä, voi uudelleenkäynnistyksen jälkeen tavoittaa eri palveluja, ja testi, joka vain pingaa vanhaa osoitetta, näyttää täysin terveeltä, vaikka pääsypäätökset ovat muuttuneet sen alla. Tarkista yksi säännön piirissä oleva palvelu, älä vain tavoitettavuutta. Se on ero tunnelin vahvistamisen ja käytännön vahvistamisen välillä.
Vertaa ladattua varmennetta korvaavaan
Ennen kuin oletat daemonin jättäneen tiedoston huomiotta, lue molemmat. Tulosta varmenne, jonka aiot ladata, ja vahvista kentät, joiden uskot muuttuneen, ja vahvista sitten, että käynnissä oleva kokoonpano osoittaa tuohon polkuun eikä kopioon muualla.
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)Prosessin argumentit merkitsevät enemmän kuin ihmiset odottavat. Yksikkö, joka välittää -config /etc/nebula/config.yml, lukee kyseisen tiedoston pki.cert -merkinnän, eikä väliaikaiseen hakemistoon asennettu varmenne vaikuta mihinkään. Tarkista polku käynnissä olevasta komentorivistä, älä polkua dokumentaatiosta, jota seurasit. Jos ne eroavat, löysit ongelman koskematta varmenteeseen lainkaan.
Jos uudella varmenteella on eri osoite ja prosessi piti vanhan, sinulla on nyt selitys mysteerin sijaan. Käynnistä se uudelleen, jos se on hyväksyttävää, ja käsittele osoitteen muutosta suunniteltuna verkkomuutoksena eikä vahinkona.
Osoitteen muutos on verkkomuutos
Suunnittele se kuten suunnittelisit koneen siirtämistä. Muut isännät ovat ehkä kiinnittäneet vanhan osoitteen kokoonpanoonsa, palvelut saattavat sitoa siihen nimenomaisesti ja palomuurisäännöt saattavat olla kirjoitettu sitä vastaan. Varmenteen vaihtaminen siirtää isäntää, ja isännän siirtäminen mitätöi oletuksia muualla.
Pidä toinen hallintapolku käytettävissä tehdessäsi tätä, sillä overlay-yhteys saattaa olla juuri se, jonka keskeytät. Tämän tekeminen tunnelin yli, jonka aiot rikkoa, on klassinen tapa muuttaa viiden minuutin muutos käynnistä paikan päällä.
Onko uudelleenkäynnistys hyväksyttävää, riippuu siitä mitä isäntä tekee, ja se on aikataulukysymys, ei tekninen. Se, mikä ei ole valinnaista, on uudelleenkäynnistysvaatimuksen myöntäminen sen sijaan, että uudelleenlataus lähetetään viidennen kerran.
Poista vanha tunnistetieto erikseen
Korvaavan asentaminen yhteen koneeseen jättää jokaisen peerin yhä luottamaan tunnistetietoon, jonka se jo tuntee. Jos muutoksen syy oli tietomurto, vanha identiteetti on poistettava luottamus- tai estolistamenettelyn kautta, jotta peerit todella hylkäävät sen.
Se on erillinen vaihe omalla vahvistuksellaan: vahvista toiselta isännältä, ettei vanha identiteetti enää toimi, sen sijaan että olettaisit uuden tiedoston hoitaneen työn. Nebulan PKI-kokoonpanon dokumentaatio kattaa uudelleenladattavat asetukset ja tässä kuvatun osoiterajoituksen, ja se kannattaa lukea kokonaan ennen kuin kierrät mitään tuotantokäytössä.