Statični ključ ili TLS za OpenVPN vezu između dva peera?

Dva računara koja razgovaraju samo jedan s drugim mogu zadržati tu topologiju i ipak dobiti pregovarane ključeve za promet. Oblik mreže i režim zaštite su nezavisni izbori, a njihovo miješanje je ono što navodi ljude da pokušaju rotirati statičnu tajnu zamjenom datoteke dok oba daemona nastavljaju raditi. Zamjena datoteke ključa ispod para koji radi ne rotira ništa. Statični režim, koji OpenVPN 2.6 označava kao zastario, drži jedan ključ za cijeli životni vijek tunela, pa se datoteka na disku i ključ u memoriji ponovo slažu tek nakon ponovnog pokretanja obje strane. Ako je automatska obnova uvjet, režim zaštite mora se promijeniti.

Šta statični režim ne može

U tajnom režimu oba peera dijele unaprijed podijeljeni ključ koji direktno šifrira i autentificira tunel. Nema rukovanja, pa nema mehanizma da bilo koja strana predloži novi ključni materijal, dokaže identitet ili se oporavi od neslaganja bez intervencije operatora. Oba svojstva proizlaze iz odsustva kontrolnog kanala, a ne iz nedostajuće opcije, i nijedna konfiguracijska zastavica ga ne dodaje ovom režimu.

OpenVPN 2.6 priručnik izričito navodi da ključ ostaje dok se ne generiše novi. To je prihvatljivo za laboratorijsku vezu ili fiksni par uređaja s dokumentiranim postupkom rotacije, a neprihvatljivo svuda gdje je dugotrajna tajna stvarni rizik. Zamjena datoteke ne stvara novi ključ za par koji radi; ona stvara dva peera koji se ne slažu. Zato zamjena datoteke dodaje prekid rada bez dodavanja rotacije.

Također nema pojma o identitetu peera izvan posjedovanja datoteke. Svako ko drži ključ je peer, i ništa u tunelu ne bilježi koja je strana koja, pa je opoziv sve ili ništa.

Prelazak na TLS bez redizajna veze

TLS režim dodaje kontrolni kanal, a s njim i mogućnost pregovaranja ključeva podatkovnog kanala. U punkt-na-punkt postavljanju jedna strana preuzima ulogu servera, a druga ulogu klijenta, ali topologija ostaje veza između dva peera: svaka strana zna krajnju točku one druge, i ne pojavljuje se nikakav bazen ni višekorisnička usluga. Uloge su detalj rukovanja, a ne nova arhitektura.

Dajte svakom računaru vlastiti identitet. Svaka strana treba certifikat i privatni ključ, sidro povjerenja koje provjerava drugu stranu, i pravilo provjere peera koje imenuje koga se očekuje. Ne koristite ponovo privatni ključ jednog peera na drugom radi uštede vremena; to pretvara dva identiteta u jedan i uklanja mogućnost da se bilo koja strana opozove zasebno. Upis je mjesto gdje se to ispravno rješava, jer kasnije ispravljanje znači ponovno izdavanje certifikata.

Držite mrežni ugovor nepromijenjenim dok se zaštita mijenja. Iste adrese tunela, rute i dozvoljene usluge trebaju važiti prije i poslije, tako da kvar tokom migracije bude problem zaštite, a ne prerušeno iznenađenje u rutiranju. Zapišite adrese i rute prije promjene; njihovo kasnije poređenje brže je od rekonstrukcije po sjećanju.

Neka postavljanja štite i kontrolni kanal vlastitim statičnim ključem, koji se ne rotira s podatkovnim kanalom. Taj ključ čuva rukovanje, a ne korisni teret, pa njegov kompromis izlaže pregovaranje, a ne promet. Čuvajte ga odvojeno od materijala podatkovnog kanala i dajte mu datum zamjene kojeg posjeduje imenovana osoba. Njegova rotacija znači ponovno pokretanje oba peera u koordiniranom prozoru, zato zaslužuje unos u kalendaru, a ne u sjećanju.

Ko obnavlja šta, i kada

U TLS režimu obnova je vođena konfiguriranim ograničenjima: vremenskim intervalom, brojem bajtova ili brojem paketa. Dokumentirana vremenska kontrola je ono na što se većina postavljanja oslanja, a niža efektivna vrijednost na dva peera može pokrenuti zamjenu, pa podizanje samo na jednoj strani neće zadržati događaj. Ograničenja po volumenu postoje zato što zauzeta veza može potrošiti ključ mnogo prije nego sat. Nijedno ograničenje nije provjera zdravlja i nijedno vam ne kaže da je obnova uspjela.

Zato je dijagnosticiranje ponavljajućeg ponovnog pregovaranja iz jedne konfiguracijske datoteke zavaravajuće. Pročitajte postavke na oba peera, pa pogledajte prijelaz u dnevniku umjesto da pretpostavite kvar. Obnova koja se čisto završi izgleda kao kratki izljev prometa kontrolnog kanala, a ne kao prekid veze.

Držite objekte odvojeno u glavi. Certifikat dokazuje dugoročni identitet i zamjenjuje se po rasporedu koji kontrolišete. Ključ podatkovnog kanala osvježava se automatski, a zasebna razmjena autentifikacije, ako je postavljanje zahtijeva, slijedi politiku računa i može trebati vlastite dogovore za kasnije razmjene.

Potpuno onemogućavanje obnove, postavljanjem intervala na nulu, nije rješenje za bučan dnevnik. Ono pretvara zdrav događaj životnog ciklusa u trajni ključ, što vas vraća na svojstvo koje ste pokušavali ostaviti za sobom.

Prihvatanje promjene

Izgradite novu konfiguraciju iz podržanog primjera instaliranog izdanja, a ne iz starog minimalnog isječka čiji su algoritmi i putanje datoteka naslijeđeni odnekud drugdje. Uskladite prebacivanje tako da se oba peera promijene zajedno, i držite odobren put oporavka u slučaju da jedna strana ne uspije startati. Spustite vezu namjerno umjesto da čekate prekid da biste testirali vraćanje. Vraćanje koje ste uvježbali vrijedi više od vraćanja koje ste opisali.

Testirajte tri stvari: početna provjera identiteta uspijeva, predviđeni tok aplikacije radi, i kontrolirana obnova se događa bez gubitka prometa. Zatim pročitajte prijelaz u dnevniku zbog onoga što stvarno dokazuje: novi identifikator ključa znači da su peeri završili zamjenu, a ne da se tunel ponovo povezao. Tretirajte to kao dokaz jednog koraka, i provjerite brojače prometa prije nego migraciju proglasite završenom.

Ono što bi obećanje nultog prekida sakrilo jest kvar koji još niste vidjeli. Obnova koja ne uspije, certifikat koji istekne ili kvar na putu još uvijek mogu poremetiti vezu, i nijedno od toga nije isključeno čistim testnim prolazom. Svojstvo za koje vrijedi projektirati uže je i korisnije: rutinska zamjena ključeva prestaje biti ručna zamjena datoteke.