OpenVPN kasnije prekida OTP sesiju: šta reautentikacija zahteva

Sa strane klijenta to izgleda kao slučajan prekid sat vremena nakon početka radne sesije. Ikona u sistemskoj traci nestaje, tunel se ponovo gradi, a dnevnik pokazuje grešku autentikacije umesto mrežne greške. Ono što se zaista dogodilo jeste da je sesija ponovo pregovarala i da su drugom rukovanju trebali kredencijali za koje klijent više nije imao važeću kopiju. Jednokratni kod koji je radio pri prijavi ne može ponovo da radi, pa ponovna razmena ključeva pada tačno kako je projektovano.

Rešenje je odluka o tome šta drugo rukovanje treba da predstavi, a ne duži tajmer ponovnih pokušaja.

Prođite kroz razmenu iz ugla klijenta

Pri prijavi klijent šalje korisničko ime, lozinku i kod sa token uređaja, a server prihvata tu kombinaciju. Zatim sesija traje dok se ne aktivira okidač za ponovno pregovaranje, koji pokreće novo TLS rukovanje unutar postojećeg tunela. To rukovanje ponovo traži autentikaciju. Ako put autentikacije na serveru očekuje lozinku i trenutni jednokratni kod, klijent nema novi kod da ponudi osim ako korisnik nije prisutan da ga unese.

Većina klijenata ne otvara upit usred sesije, pa rukovanje istekne i tunel padne. Korisnik vidi ponovno povezivanje, a ne upit za autentikaciju, i zato prvi izveštaj obično okrivljuje mrežu.

auth-gen-token menja ko odgovara na drugo pitanje

Opcija auth-gen-token dozvoljava serveru da izda token nakon uspešne prijave, a kasnija pregovaranja predstavljaju taj token umesto da ponavljaju lozinku i kod. Uputstvo dokumentuje njegov životni vek i ponašanje pri obnavljanju, a token se mora tretirati kao kredencijal sa sopstvenim rokom trajanja. Na podrazumevanom putu server sam validira token umesto da ponovo poziva spoljni autentifikator lozinki.

Sa integracijom spoljne autentikacije, ta podela se menja. Priključak mora da razume stanje tokena i primeni sopstvene provere, jer server više nije jedina komponenta koja odlučuje da li se sesija nastavlja. Tretiranje tokena kao još jednog numeričkog jednokratnog koda nije implementacija ove funkcije.

Odlučite šta se dešava sa statusom naloga

Token koji nadživi pristup naloga je rupa u politici. Odlučite kako onemogućen nalog, uklonjeno članstvo u grupi ili opozvan uređaj deluju dok je token još važeći. Kratak životni vek tokena sužava prozor; eksplicitna putanja opoziva čini ga namernim. Zapišite odgovor pre nego što uključite opciju, jer podrazumevani put ne konsultuje spoljni autentifikator pri svakom pregovaranju.

U postavci sa više servera, tajna za potpisivanje tokena mora biti deljena, inače klijent može biti poslat na čvor koji ne može da validira njegov token.

Testirajte istek i ponovno povezivanje, ne samo prijavu

Smanjite interval pregovaranja u testnom profilu da drugo rukovanje prođe dok gledate, pa pratite oba dnevnika. Potvrdite da se token izdaje pri prijavi, predstavlja pri razmeni ključeva i obnavlja ili ponovo izdaje prema konfigurisanom životnom veku. Zatim prinudno izazovite istek tokena i potpuno ponovno povezivanje, jer klijent koji se čisto ponovo povezuje i dalje može da padne na putu razmene ključeva.

Uklanjanje naloga testirajte na kraju. Taj slučaj vam kaže da li se napisana politika sprovodi ili je samo dokumentovana.

Ne popravljajte to isključivanjem obnavljanja

Postavljanje intervala pregovaranja na nulu na oba partnera uklanja simptom i zajedno sa njim rotaciju ključeva. To skriva problem ponovne upotrebe kredencijala iza promene politike koju niko nije pregledao. Zadržite obnavljanje i izaberite između tokena koji izdaje server i novog interaktivnog izazova na osnovu toga da li je korisnik prisutan.

Duži tajmer ponovnih pokušaja ne čini iskorišćen kod ponovo važećim. On samo odlaže prekid i otežava čitanje dnevnika.