Statikus kulcs vagy TLS a két fél közötti OpenVPN-kapcsolathoz?

Két gép, amely csak egymással beszél, megtarthatja ezt a topológiát, és mégis tárgyalt forgalmi kulcsokat kaphat. A hálózat formája és a védelmi mód független döntések, és ezek összekeverése az, ami arra készteti az embereket, hogy egy statikus titkot fájl cseréjével próbáljanak rotálni, miközben mindkét démon tovább fut. A kulcsfájl cseréje egy futó pár alatt semmit sem rotál. A statikuskulcs-mód, amelyet az OpenVPN 2.6 elavultnak jelöl, egyetlen kulcsot tart az alagút teljes élettartama alatt, ezért a lemezen lévő fájl és a memóriában lévő kulcs csak mindkét vég újraindítása után egyezik meg újra. Ha az automatikus megújítás a követelmény, a védelmi módnak változnia kell.

Amit a statikuskulcs-mód nem tud

Titkos módban mindkét fél egy előre megosztott kulcsot használ, amely közvetlenül titkosítja és hitelesíti az alagutat. Nincs kézfogás, ezért nincs mechanizmus arra, hogy bármelyik oldal új kulcsanyagot javasoljon, személyazonosságot bizonyítson, vagy üzemeltetői beavatkozás nélkül kilábaljon egy eltérésből. Mindkét tulajdonság a vezérlőcsatorna hiányából fakad, nem egy hiányzó beállításból, és egyetlen konfigurációs kapcsoló sem ad hozzá ilyet ehhez a módhoz.

Az OpenVPN 2.6 kézikönyve egyértelműen kimondja, hogy a kulcs addig marad, amíg újat nem generálnak. Ez elfogadható laboratóriumi kapcsolat vagy dokumentált rotációs eljárással rendelkező, rögzített eszközpár esetében, és elfogadhatatlan ott, ahol a hosszú életű titok valódi kockázat. A fájlcsere nem hoz létre új kulcsot egy futó pár számára; két olyan felet hoz létre, amelyek nem értenek egyet. Ezért a fájl lecserélése kiesést ad hozzá rotáció nélkül.

Nincs fogalma a fél személyazonosságáról sem a fájl birtoklásán túl. Aki a kulcsot birtokolja, az fél, és semmi sem rögzíti az alagútban, melyik oldal melyik, ezért a visszavonás mindent vagy semmit jelent.

Áttérés TLS-re a kapcsolat újratervezése nélkül

A TLS-mód vezérlőcsatornát ad hozzá, és ezzel az adatcsatorna kulcsainak tárgyalását. Pont-pont telepítésben az egyik oldal a kiszolgáló, a másik az ügyfél szerepét veszi át, de a topológia két fél közötti kapcsolat marad: mindkét oldal ismeri a másik végpontját, és nem jelenik meg semmilyen készlet vagy többfelhasználós szolgáltatás. A szerepek a kézfogás részletei, nem új architektúra.

Adjon minden gépnek saját személyazonosságot. Mindkét oldalnak tanúsítványra és privát kulcsra van szüksége, a másikat hitelesítő bizalmi horgonyra, valamint egy félellenőrzési szabályra, amely megnevezi, kit várunk. Ne használja újra az egyik fél privát kulcsát a másikon időt spórolva; ez két személyazonosságot eggyé tesz, és megszünteti annak lehetőségét, hogy bármelyik oldalt külön vonjuk vissza. A regisztráció az a hely, ahol ezt helyesen kell elvégezni, mert a későbbi javítás a tanúsítványok újrakibocsátását jelenti.

Tartsa a hálózati szerződést változatlanul, miközben a védelem változik. Ugyanazoknak az alagútcímeknek, útvonalaknak és engedélyezett szolgáltatásoknak kell érvényesülniük előtte és utána, hogy a migráció alatti hiba védelmi probléma legyen, ne álcázott útválasztási meglepetés. Írja fel a címeket és útvonalakat a változás előtt; későbbi összehasonlításuk gyorsabb, mint memóriából újraépíteni őket.

Néhány telepítés a vezérlőcsatornát is saját statikus kulccsal védi, amely nem rotálódik az adatcsatornával. Ez a kulcs a kézfogást őrzi, nem a hasznos terhet, ezért kompromittálódása a tárgyalást fedi fel, nem a forgalmat. Tárolja az adatcsatorna anyagától elkülönítve, és adjon neki olyan csere dátumot, amelyért egy megnevezett személy felel. Rotálása mindkét fél újraindítását jelenti egy összehangolt ablakban, ezért naptárbejegyzést érdemel, nem emlékezetet.

Ki mit újít meg, és mikor

TLS-módban a megújítást konfigurált korlátok vezérlik: időintervallum, bájtszám vagy csomagszám. A dokumentált idővezérlés az, amire a legtöbb telepítés támaszkodik, és a két fél közötti alacsonyabb effektív érték indíthatja el a cserét, ezért az egyoldalú emelés nem tartja vissza az eseményt. A mennyiségi korlátok azért léteznek, mert egy forgalmas kapcsolat jóval az óra előtt kimeríthet egy kulcsot. Egyik korlát sem állapotellenőrzés, és egyik sem mondja meg, hogy a megújítás sikerült.

Ezért félrevezető egy ismétlődő újratárgyalást egyetlen konfigurációs fájlból diagnosztizálni. Olvassa el a beállításokat mindkét félen, majd nézze meg az átmenetet a naplóban ahelyett, hogy hibát feltételezne. A tisztán lezáruló megújítás rövid vezérlőcsatorna-forgalmi sorozatnak látszik, nem megszakadásnak.

Tartsa az objektumokat külön a fejében. A tanúsítvány hosszú távú személyazonosságot bizonyít, és az Ön által irányított ütemterv szerint cserélődik. Az adatcsatorna kulcsa automatikusan frissül, és egy külön hitelesítési csere, ha a telepítés megköveteli, a fiók szabályzatát követi, és saját intézkedésekre lehet szüksége a későbbi cserékhez.

A megújítás teljes kikapcsolása, az intervallum nullára állításával, nem megoldás egy zajos naplóra. Egy egészséges életciklus-eseményt állandó kulccsá alakít, ami visszavezeti ahhoz a tulajdonsághoz, amelyet el akart hagyni.

A változás elfogadása

A telepített kiadás támogatott példájából építse fel az új konfigurációt, ne egy régi minimális töredékből, amelynek algoritmusai és fájlútvonalai máshonnan öröklődtek. Hangolja össze a váltást, hogy mindkét fél együtt változzon, és tartson fenn jóváhagyott helyreállítási útvonalat arra az esetre, ha az egyik oldal nem indul el. Szándékosan vigye le a kapcsolatot, ahelyett hogy kiesésre várna a visszaállítás teszteléséhez. A begyakorolt visszaállítás többet ér a leírt visszaállításnál.

Teszteljen három dolgot: a kezdeti személyazonosság-ellenőrzés sikerül, a tervezett alkalmazásfolyamat működik, és egy ellenőrzött megújítás forgalomvesztés nélkül megtörténik. Ezután olvassa el az átmenetet a naplóban azért, amit valóban bizonyít: az új kulcsazonosító azt jelenti, hogy a felek befejezték a cserét, nem azt, hogy az alagút újra csatlakozott. Egy lépés bizonyítékaként kezelje, és ellenőrizze a forgalomszámlálókat, mielőtt késznek nyilvánítja a migrációt.

Amit a nulla megszakítás ígérete elrejtene, az a hiba, amelyet még nem látott. Egy sikertelen megújítás, egy lejáró tanúsítvány vagy egy útvonalhiba továbbra is zavarhatja a kapcsolatot, és egyiket sem zárja ki egy tiszta tesztfutás. A tulajdonság, amiért érdemes tervezni, szűkebb és hasznosabb: a rutin kulcscsere megszűnik kézi fájlcserének lenni.