Statický klíč, nebo TLS pro dvoubodové spojení OpenVPN?

Dva stroje, které spolu mluví jen navzájem, mohou tuto topologii zachovat a přesto získat vyjednané provozní klíče. Tvar sítě a režim ochrany jsou nezávislé volby a právě jejich zaměňování vede lidi k tomu, že se snaží rotovat statické tajemství výměnou souboru, zatímco oba daemony běží dál. Výměna souboru s klíčem u běžící dvojice nic nerotuje. Statický režim, který OpenVPN 2.6 označuje za zastaralý, drží jeden klíč po celou dobu života tunelu, takže soubor na disku a klíč v paměti se znovu shodnou až po restartu obou stran. Pokud je požadavkem automatická obnova, musí se změnit režim ochrany.

Co statický režim nedokáže

V tajném režimu oba protějšky sdílejí předem sdílený klíč, který tunel přímo šifruje a autentizuje. Neexistuje handshake, takže neexistuje mechanismus, aby kterákoli strana navrhla nový klíčový materiál, prokázala identitu nebo se zotavila z neshody bez zásahu operátora. Obě vlastnosti vyplývají z absence řídicího kanálu, nikoli z chybějící volby, a žádný konfigurační přepínač jej do tohoto režimu nepřidá.

V manuálu OpenVPN 2.6 je výslovně uvedeno, že klíč přetrvává, dokud není vygenerován nový. To je přijatelné pro laboratorní spojení nebo pevnou dvojici zařízení s dokumentovaným postupem rotace a nepřijatelné všude tam, kde je dlouhodobé tajemství skutečným rizikem. Výměna souboru nevytváří nový klíč pro běžící dvojici; vytváří dva protějšky, které se neshodují. Nahrazení souboru tedy přidává výpadek, aniž by přidalo rotaci.

Neexistuje ani pojem identity protějšku mimo vlastnictví souboru. Kdokoli drží klíč, je protějšek, a nic v tunelu nezaznamenává, která strana je která, takže odvolání je vše, nebo nic.

Přechod na TLS bez přepracování spojení

Režim TLS přidává řídicí kanál a s ním schopnost vyjednávat klíče datového kanálu. V nasazení bod-bod přebírá jedna strana roli serveru a druhá roli klienta, ale topologie zůstává spojením dvou protějšků: každá strana zná koncový bod té druhé a neobjevuje se žádný fond ani víceuživatelská služba. Role jsou detail handshake, nikoli nová architektura.

Dejte každému stroji vlastní identitu. Každá strana potřebuje certifikát a soukromý klíč, kořen důvěry, který ověřuje druhou stranu, a pravidlo ověřování protějšku, které určuje, kdo se očekává. Neznovupoužívejte soukromý klíč jednoho protějšku na druhém, abyste ušetřili čas; přemění to dvě identity v jednu a odstraní možnost odvolat kteroukoli stranu samostatně. Registrace je místo, kde to udělat správně, protože pozdější oprava znamená opětovné vydání certifikátů.

Udržujte síťovou smlouvu nezměněnou, zatímco se ochrana mění. Stejné adresy tunelu, trasy a povolené služby by měly platit před i po, takže selhání během migrace je problém ochrany, nikoli převlečené překvapení v routování. Zapište si adresy a trasy před změnou; jejich pozdější porovnání je rychlejší než rekonstrukce z paměti.

Některá nasazení chrání řídicí kanál také vlastním statickým klíčem, který se neobnovuje spolu s datovým kanálem. Tento klíč střeží handshake, nikoli užitečné zatížení, takže jeho kompromitace odhalí vyjednávání, nikoli provoz. Uchovávejte jej odděleně od materiálu datového kanálu a dejte mu datum nahrazení, za které odpovídá jmenovaná osoba. Jeho rotace znamená restart obou protějšků v koordinovaném okně, a proto si zaslouží záznam v kalendáři, ne v paměti.

Kdo co obnovuje a kdy

V režimu TLS je obnova řízena nastavenými limity: časovým intervalem, počtem bajtů nebo počtem paketů. Dokumentovaná časová kontrola je to, na co se většina nasazení spoléhá, a nižší efektivní hodnota z obou protějšků může zahájit nahrazení, takže zvýšení jen na jedné straně událost nezdrží. Limity podle objemu existují proto, že vytížené spojení může klíč vyčerpat dávno před tím, než to udělají hodiny. Ani jeden limit není kontrola stavu a ani jeden vám neřekne, že obnova proběhla úspěšně.

Proto je diagnostika opakovaného opětovného vyjednávání z jediného konfiguračního souboru zavádějící. Přečtěte si nastavení na obou protějšcích a pak se podívejte na přechod v protokolu, místo abyste předpokládali poruchu. Obnova, která proběhne čistě, vypadá jako krátký výbuch provozu řídicího kanálu, nikoli jako odpojení.

Držte objekty odděleně v hlavě. Certifikát prokazuje dlouhodobou identitu a nahrazuje se podle harmonogramu, který kontrolujete. Klíč datového kanálu se obnovuje automaticky a samostatná autentizační výměna, pokud ji nasazení vyžaduje, se řídí politikou účtu a může potřebovat vlastní ujednání pro pozdější výměny.

Úplné vypnutí obnovy nastavením intervalu na nulu není opravou hlučného protokolu. Mění zdravou událost životního cyklu v trvalý klíč, což vás vrací k vlastnosti, kterou jste se snažili opustit.

Přijetí změny

Sestavte novou konfiguraci z podporovaného příkladu nainstalovaného vydání, nikoli ze starého minimálního úryvku, jehož algoritmy a cesty k souborům byly zděděny odjinud. Koordinujte přepnutí tak, aby se oba protějšky změnily společně, a mějte schválenou cestu obnovy pro případ, že jedna strana nenaběhne. Vědomě spojení přerušte, místo abyste čekali na výpadek kvůli testu rollbacku. Rollback, který jste nacvičili, má větší cenu než rollback, který jste popsali.

Otestujte tři věci: počáteční ověření identity uspěje, zamýšlený tok aplikace funguje a řízená obnova proběhne bez ztráty provozu. Potom si přečtěte přechod v protokolu kvůli tomu, co skutečně dokazuje: nový identifikátor klíče znamená, že protějšky dokončily nahrazení, nikoli že se tunel znovu připojil. Berte to jako důkaz jednoho kroku a před prohlášením migrace za hotovou zkontrolujte provozní čítače.

Co by slib nulového přerušení skryl: selhání, které jste ještě neviděli. Neúspěšná obnova, vypršelý certifikát nebo závada na cestě mohou spojení stále narušit a nic z toho nevylučuje čistý testovací běh. Vlastnost, kvůli které stojí za to navrhovat, je užší a užitečnější: rutinní výměna klíčů přestává být ruční výměnou souboru.