OpenVPN auth-nocache: mi történik a következő bejelentkezéskor

Kapcsolja be az auth-nocache-t, és eltűnik a jelszó gyorsítótárazására figyelmeztető üzenet, valamint a következő újratárgyaláshoz tárolt hitelesítő adatok másolata is, amelyet OpenVPN tartott. Az, hogy ebből kérés, csendes újrapróbálkozás vagy megszakadt alagút lesz, attól függ, honnan jönnek a hitelesítő adatok másodszor. Ezért ez a telepítési formák összehasonlítása, nem pedig ítélet az opcióról. Olvassa el azt a formát, amelyet valóban futtat, mielőtt bármelyik profilt szerkesztené.

Honnan kell jönnie a második hitelesítőadat-készletnek

Az OpenVPN az auth-nocache-t az auth-user-pass és az askpass által gyűjtött titkokra alkalmazza: használat után a folyamat eldobja őket ahelyett, hogy a következő kézfogáshoz megtartaná. Az újratárgyalás időzítő szerint érkezik, alapértelmezés szerint óránként egyszer, így a második kérés jóval azután érkezik, hogy a jelszót beíró személy továbblépett. Ez a rés az egész történet. Ha a gyorsítótár be van kapcsolva, a kliens a tárolt másolatot játssza le anélkül, hogy bárkit megkérdezne; ha ki van kapcsolva, máshol kell megtalálnia a titkot, vagy meghiúsul.

Sorolja fel tehát minden helyet, ahonnan a titok abban a pillanatban jöhet, és legyen őszinte, melyek léteznek a gazdagépen. Egy ember a terminálnál, egy fájl, amelyet az auth-user-pass vagy az askpass olvashat, vagy a kiszolgáló által kiadott munkamenet-token az a három, amely itt számít. Ha egyik sem érhető el, az újratárgyalás egy órával a változtatás után meghiúsul, nem abban a pillanatban, amikor végrehajtotta.

Három forma, három hibahely

Az asztali kliens, amely előtt ember ül, az enyhe eset: a kérés visszatér, valaki újra beírja a jelszót, és az ár a figyelem. A terminál nélkül OpenVPN-t futtató szolgáltatás, konténer vagy útválasztó a kemény eset, mert nincs, aki válaszoljon, és az egykor csendes újracsatlakozás most lezárja az alagutat. A hibrid a kettő között van, és az asztali esethez hasonlóan viselkedik, amíg el nem tűnik a munkamenet, amely válaszolhatott volna a kérésre. Nem az választja el őket, hogy van-e telepítve GUI, hanem hogy létezik-e hitelesítőadat-forrás az újratárgyalás idején.

Rendelje telepítését a három közül az egyikhez, mielőtt bármit megváltoztat, mert az interneten talált tanács szinte mindig az elsőhöz íródott. Az asztali válasz alkalmazása terminál nélküli szolgáltatásra az az út, ahogy egy hónapokig működő alagút óránként elkezd leesni.

Direktíva vagy kapcsoló: válasszon egyet, és tudja, melyiket használta

Egy profilon belül az auth-nocache külön sor; a profil nevét kifejezetten megadó hívásban kapcsoló azon a parancssoron, és az OpenVPN kézikönyve mindkét formát felsorolja. Mindkettő ugyanazt teszi a hitelesítő adatok megtartásával, és egyik sem nyúl az interfész típusához, és nem javít egy nem kapcsolódó figyelmeztetést ugyanabban a naplóban. A különbség a tartósság: a kapcsoló csak arra a futásra vonatkozik, így az unit-fájlból vagy becsomagoló szkriptből újraindított szolgáltatás nem kapja meg, hacsak a csomagoló is át nem adja.

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

Döntse el, melyik összetevő birtokolja a beállítást, ott változtassa meg, és sehol másutt. A laptopon szerkesztett profil és az azt kapcsolóval felülíró systemd unit az a páros, amely újraindítás után ellentmondásos viselkedést okoz.

A hitelesítőadat-fájl áthelyezi a titkot ahelyett, hogy törölné

Az auth-user-pass fájlra irányítása minden későbbi újratárgyalásnak forrást ad, és a jelszót olyan helyre teszi, amely túléli az újraindításokat. Kérdezze meg, ki olvashatja a fájlt, tudja-e még olvasni a démon, miután lemondott a jogosultságairól, és mi történik, ha a fájlrendszer csak olvashatóként van csatolva, vagy egy konténer-nézet elrejti az útvonalat. A lemezen lévő titok és a memóriában lévő titok különböző problémák, és az egyik megoldása a másikat a helyén hagyja. A rotáció az a lépés, amelyet kihagynak: a kiszolgálón megváltoztatott, de a fájlban nem szereplő jelszó hálózati hibának látszó hibát okoz.

Tartsa a fájlt a démont futtató fiók tulajdonában, senki más ne olvashassa, és a gazdagépet elhagyó biztonsági mentéseken kívül. Az OpenVPN kiszolgálóoldali auth-gen-token opciója sikeres bejelentkezés után munkamenet-tokent ad a kliensnek, ami kisebb dolog heverni hagyni, mint a fiók jelszava. Írja le a rotációs lépést a fájl mellé mindenképpen, mert a fájl általában túléli a létrehozóját.

Az újratárgyalás nyújtása áthelyezi a költséget, nem szünteti meg

A másik javaslat a reneg-sec növelése, amíg a kérés elég ritka nem lesz a figyelmen kívül hagyáshoz. Ez újraírja a munkamenet kulcsrotációs ütemtervét, és ugyanazt a hitelesítőadat-problémát későbbi, kevésbé kiszámítható pillanatra tolja; nem hoz létre hitelesítőadat-forrást. Egy szabályzatot, amely okkal újítja meg a kulcsokat ütemterv szerint, nem szabad csak a jelszó beírásának elkerülése miatt lazítani.

Az újracsatlakozást tesztelje, ne a munkamenetet, amelyben ül, mert az élő munkamenet semmit sem bizonyít. Ejtsük el az alagutat a kiszolgáló oldaláról, vagy indítsa újra a kliens szolgáltatást, és figyelje, mit tesz a következő újratárgyalás, amikor senki sincs a billentyűzetnél. Ha újracsatlakozik, nevezze meg a titkot szolgáltató mechanizmust; ha nem, megtalálta az opció valódi költségét ezen a gazdagépen. Mindkét eredmény olyan választ ad, amely kimaradás idején is érvényes, nem pedig olyat, amely a tesztelés idején érvényes volt.

Egy kezelt flottán a telepítés tulajdonosának három dolgot kell meg tudnia nevezni: honnan jönnek a hitelesítő adatok, hol tárolják őket, és ki rotálja őket. Ha ezek bármelyikének a válasza az a személy, aki a gazdagépet beállította, az opció ott még nem biztonságos.