Statický kľúč alebo TLS pre spojenie OpenVPN medzi dvoma uzlami?

Dva stroje, ktoré hovoria len navzájom, môžu zachovať túto topológiu a napriek tomu získať vyjednané prevádzkové kľúče. Tvar siete a režim ochrany sú nezávislé voľby a práve ich zamieňanie vedie ľudí k tomu, že sa pokúšajú rotovať statické tajomstvo výmenou súboru, kým oba démoni bežia ďalej. Výmena súboru s kľúčom pri bežiacej dvojici nič nerotuje. Statický režim, ktorý OpenVPN 2.6 označuje za zastaraný, drží jeden kľúč po celý čas života tunela, takže súbor na disku a kľúč v pamäti sa znova zhodujú až po reštarte oboch strán. Ak je požiadavkou automatická obnova, musí sa zmeniť režim ochrany.

Čo statický režim nedokáže

V tajnom režime obe strany zdieľajú vopred zdieľaný kľúč, ktorý tunel priamo šifruje a autentifikuje. Neexistuje podanie ruky, takže neexistuje mechanizmus, ktorým by ktorákoľvek strana navrhla nový kľúčový materiál, preukázala identitu alebo sa zotavila z nezhody bez zásahu operátora. Obe vlastnosti vyplývajú z absencie riadiaceho kanála, nie z chýbajúcej možnosti, a žiadny konfiguračný prepínač ju do tohto režimu nepridá.

V manuáli OpenVPN 2.6 sa výslovne uvádza, že kľúč pretrváva, kým sa nevygeneruje nový. To je prijateľné pre laboratórne spojenie alebo pevnú dvojicu zariadení s dokumentovaným postupom rotácie a neprijateľné všade tam, kde je dlhodobé tajomstvo skutočným rizikom. Výmena súboru nevytvára nový kľúč pre bežiacu dvojicu; vytvára dva uzly, ktoré sa nezhodujú. Nahradenie súboru teda pridáva výpadok bez toho, aby pridalo rotáciu.

Neexistuje ani pojem identity uzla mimo vlastníctva súboru. Kto má kľúč, je uzlom, a nič v tuneli nezaznamenáva, ktorá strana je ktorá, takže odvolanie je všetko alebo nič.

Prechod na TLS bez prepracovania spojenia

Režim TLS pridáva riadiaci kanál a s ním schopnosť vyjednávať kľúče dátového kanála. V nasadení bod-bod preberá jedna strana rolu servera a druhá rolu klienta, ale topológia zostáva spojením dvoch uzlov: každá strana pozná koncový bod tej druhej a neobjavuje sa žiadny fond ani viacpoužívateľská služba. Roly sú detailom podania ruky, nie novou architektúrou.

Dajte každému stroju vlastnú identitu. Každá strana potrebuje certifikát a súkromný kľúč, koreň dôvery, ktorý overuje druhú stranu, a pravidlo overovania uzla, ktoré určuje, kto sa očakáva. Nepoužívajte znova súkromný kľúč jedného uzla na druhom, aby ste ušetrili čas; premení to dve identity na jednu a odstráni možnosť odvolať ktorúkoľvek stranu samostatne. Registrácia je miesto, kde to urobiť správne, pretože neskoršia oprava znamená opätovné vydanie certifikátov.

Udržujte sieťovú zmluvu nezmenenú, kým sa ochrana mení. Rovnaké adresy tunela, trasy a povolené služby by mali platiť pred aj po, takže zlyhanie počas migrácie je problém ochrany, nie prezlečené prekvapenie v smerovaní. Zapíšte adresy a trasy pred zmenou; ich neskoršie porovnanie je rýchlejšie ako rekonštrukcia z pamäti.

Niektoré nasadenia chránia aj riadiaci kanál vlastným statickým kľúčom, ktorý sa neobnovuje spolu s dátovým kanálom. Tento kľúč stráži podanie ruky, nie užitočné zaťaženie, takže jeho kompromitácia odhalí vyjednávanie, nie prevádzku. Uchovávajte ho oddelene od materiálu dátového kanála a dajte mu dátum nahradenia, za ktorý zodpovedá menovaná osoba. Jeho rotácia znamená reštart oboch uzlov v koordinovanom okne, preto si zaslúži záznam v kalendári, nie v pamäti.

Kto čo obnovuje a kedy

V režime TLS je obnova riadená nastavenými limitmi: časovým intervalom, počtom bajtov alebo počtom paketov. Dokumentovaná časová kontrola je to, na čo sa spolieha väčšina nasadení, a nižšia efektívna hodnota z oboch uzlov môže začať nahradenie, takže zvýšenie len na jednej strane udalosť nezdrží. Limity podľa objemu existujú preto, lebo vyťažené spojenie môže kľúč vyčerpať dávno pred tým, ako to urobia hodiny. Ani jeden limit nie je kontrola stavu a ani jeden vám nepovie, že obnova bola úspešná.

Preto je diagnostika opakovaného opätovného vyjednávania z jedného konfiguračného súboru zavádzajúca. Prečítajte si nastavenia na oboch uzloch a potom sa pozrite na prechod v protokole, namiesto toho, aby ste predpokladali poruchu. Obnova, ktorá sa čisto dokončí, vyzerá ako krátky výbuch prevádzky riadiaceho kanála, nie ako odpojenie.

Držte objekty oddelene v hlave. Certifikát preukazuje dlhodobú identitu a nahrádza sa podľa harmonogramu, ktorý kontrolujete. Kľúč dátového kanála sa obnovuje automaticky a samostatná autentifikačná výmena, ak ju nasadenie vyžaduje, sa riadi politikou účtu a môže potrebovať vlastné ujednania pre neskoršie výmeny.

Úplné vypnutie obnovy nastavením intervalu na nulu nie je opravou hlučného protokolu. Mení zdravú udalosť životného cyklu na trvalý kľúč, čo vás vracia k vlastnosti, ktorú ste sa snažili opustiť.

Prijatie zmeny

Zostavte novú konfiguráciu z podporovaného príkladu nainštalovaného vydania, nie zo starého minimálneho úryvku, ktorého algoritmy a cesty k súborom boli zdedené odinakiaľ. Koordinujte prepnutie tak, aby sa oba uzly zmenili spolu, a majte schválenú cestu obnovy pre prípad, že jedna strana nenabehne. Vedome prerušte spojenie, namiesto toho, aby ste čakali na výpadok kvôli testu rollbacku. Rollback, ktorý ste nacvičili, má väčšiu cenu než rollback, ktorý ste opísali.

Otestujte tri veci: počiatočné overenie identity uspeje, zamýšľaný tok aplikácie funguje a riadená obnova prebehne bez straty prevádzky. Potom si prečítajte prechod v protokole kvôli tomu, čo skutočne dokazuje: nový identifikátor kľúča znamená, že uzly dokončili nahradenie, nie že sa tunel znova pripojil. Berte to ako dôkaz jedného kroku a pred vyhlásením migrácie za hotovú skontrolujte prevádzkové počítadlá.

Čo by sľub nulového prerušenia skryl: zlyhanie, ktoré ste ešte nevideli. Neúspešná obnova, expirujúci certifikát alebo porucha na ceste môžu spojenie stále narušiť a nič z toho nevylučuje čistý testovací beh. Vlastnosť, kvôli ktorej sa oplatí navrhovať, je užšia a užitočnejšia: rutinná výmena kľúčov prestáva byť ručnou výmenou súboru.