OpenVPN neskôr prerušuje OTP reláciu: čo si vyžaduje opätovná autentifikácia

Z pohľadu klienta to vyzerá ako náhodné odpojenie hodinu po začiatku pracovnej relácie. Ikona v oznamovacej oblasti zmizne, tunel sa znovu zostaví a log ukáže chybu autentifikácie namiesto sieťovej chyby. V skutočnosti relácia znovu vyjednala parametre a druhé podanie ruky potrebovalo prihlasovacie údaje, ku ktorým klient už nemal platnú kópiu. Jednorazový kód, ktorý fungoval pri prihlásení, nemôže fungovať znova, takže výmena kľúčov zlyhá presne tak, ako bolo navrhnuté.

Riešením je rozhodnutie, čo má druhé podanie ruky predložiť, nie dlhší časovač opakovaní.

Prejdite výmenu z pohľadu klienta

Pri prihlásení klient odošle používateľské meno, heslo a kód z tokenového zariadenia a server túto kombináciu prijme. Potom relácia beží, kým sa nespustí spúšťač opätovného vyjednávania, ktorý začne nové podanie ruky TLS v existujúcom tuneli. To podanie ruky znova žiada autentifikáciu. Ak cesta autentifikácie na serveri očakáva heslo a aktuálny jednorazový kód, klient nemá nový kód, ktorý by predložil, pokiaľ používateľ nie je prítomný a nezadá ho.

Väčšina klientov neotvára výzvu uprostred relácie, takže podanie ruky vyprší a tunel padne. Používateľ vidí opätovné pripojenie, nie výzvu na autentifikáciu, a preto prvý hlásenie zvyčajne obviňuje sieť.

auth-gen-token mení, kto odpovedá na druhú otázku

Voľba auth-gen-token umožňuje serveru vydať token po úspešnom prihlásení a neskoršie vyjednávania predkladajú tento token namiesto opakovania hesla a kódu. Príručka dokumentuje jeho životnosť a správanie pri obnovovaní, a token sa musí považovať za prihlasovací údaj s vlastnou platnosťou. Na predvolenej ceste server validuje token sám, namiesto toho aby znova volal externý autentifikátor hesiel.

S integráciou externej autentifikácie sa to rozdelenie mení. Plugin musí rozumieť stavu tokenu a uplatňovať vlastné kontroly, pretože server už nie je jediná komponenta, ktorá rozhoduje, či relácia pokračuje. Považovať token za ďalší číselný jednorazový kód nie je implementáciou tejto funkcie.

Rozhodnite, čo sa stane so stavom účtu

Token, ktorý prežije prístup účtu, je diera v politike. Rozhodnite, ako zakázaný účet, odstránené členstvo v skupine alebo odvolané zariadenie pôsobia, kým je token ešte platný. Krátka životnosť tokenu zmenšuje okno; explicitná cesta odvolania ho robí zámerným. Napíšte odpoveď pred zapnutím voľby, pretože predvolená cesta sa pri každom vyjednávaní neobracia na externý autentifikátor.

V nasadení s viacerými servermi musí byť tajomstvo podpisovania tokenov zdieľané, inak môže byť klient poslaný na uzol, ktorý nedokáže overiť jeho token.

Testujte vypršanie a opätovné pripojenie, nielen prihlásenie

Znížte interval vyjednávania v testovacom profile, aby druhé podanie ruky prebehlo pred vašimi očami, potom sledujte oba logy. Potvrďte, že token sa vydáva pri prihlásení, predkladá pri výmene kľúčov a obnovuje alebo znovu vydáva podľa nakonfigurovanej životnosti. Potom vynúťte vypršanie tokenu a úplné opätovné pripojenie, pretože klient, ktorý sa čisto pripojí znova, môže stále zlyhať na ceste výmeny kľúčov.

Odstránenie účtu otestujte nakoniec. Ten prípad vám povie, či sa napísaná politika presadzuje alebo je len zdokumentovaná.

Neopravujte to vypnutím obnovovania

Nastavenie intervalu vyjednávania na nulu na oboch stranách odstráni príznak a spolu s ním aj rotáciu kľúčov. To skrýva problém opakovaného použitia prihlasovacích údajov za zmenou politiky, ktorú nikto nepreskúmal. Zachovajte obnovovanie a vyberte medzi tokenom vydaným serverom a novou interaktívnou výzvou podľa toho, či je používateľ prítomný.

Dlhší časovač opakovaní neurobí spotrebovaný kód znova platným. Iba odloží odpojenie a sťaží čítanie logu.