OpenVPN poste forĵetas OTP-sesion: kion bezonas reaŭtentikigo

De la flanko de la kliento ĝi aspektas kiel hazarda malkonekto unu horon poste en funkcianta sesio. La piktogramo en la sistemopleto malaperas, la tunelo rekonstruiĝas, kaj la protokolo montras aŭtentikigan fiaskon anstataŭ retan eraron. Kio fakte okazis estas, ke la sesio renegocis kaj la dua manpremo bezonis akreditaĵojn, de kiuj la kliento jam ne havis validan kopion. Unufoja kodo, kiu funkciis ĉe ensaluto, ne povas funkcii denove, do la ŝlosilrenovigo fiaskas ĝuste tiel, kiel ĝi estis projektita.

La solvo estas decido pri tio, kion la dua manpremo prezentu, ne pli longa reprova tempigilo.

Spuru la interŝanĝon el la vidpunkto de la kliento

Ĉe ensaluto la kliento sendas la uzantnomon, la pasvorton kaj kodon el la ĵetona aparato, kaj la servilo akceptas la kombinaĵon. Poste la sesio funkcias ĝis ekfunkcias renegoca ellasilo, kiu komencas novan TLS-manpremon ene de la ekzistanta tunelo. Tiu manpremo denove postulas aŭtentikigon. Se la aŭtentikiga vojo de la servilo atendas pasvorton plus aktualan unufojan kodon, la kliento ne havas novan kodon por proponi, krom se la uzanto ĉeestas por tajpi unu.

Plej multaj klientoj ne malfermas inviton meze de sesio, do la manpremo senvalidiĝas kaj la tunelo falas. La uzanto vidas rekonekton, ne aŭtentikigan inviton, kaj tial la unua raporto kutime kulpigas la reton.

auth-gen-token ŝanĝas, kiu respondas la duan demandon

auth-gen-token estas la opcio, kiu permesas al la servilo eldoni ĵetonon post sukcesa ensaluto, kaj postaj renegocoj prezentas tiun ĵetonon anstataŭ ripeti la pasvorton kaj la kodon. La manlibro dokumentas ĝian vivdaŭron kaj renovigan konduton, kaj la ĵetono devas esti traktata kiel akreditaĵo kun propra limdato. En la defaŭlta vojo la servilo mem validigas la ĵetonon anstataŭ revoki la eksteran pasvortan aŭtentikigilon.

Kun ekstera aŭtentikiga integriĝo tiu divido ŝanĝiĝas. La kromaĵo devas kompreni la staton de la ĵetono kaj apliki proprajn kontrolojn, ĉar la servilo ne plu estas la sola komponanto, kiu decidas, ĉu la sesio daŭras. Trakti la ĵetonon kiel alian ciferecan unufojan kodon ne estas efektivigo de la funkcio.

Decidu, kio okazas al la konta stato

Ĵetono, kiu postvivas la aliron de konto, estas truo en la politiko. Decidu, kiel malŝaltita konto, forigita grupano aŭ revokita aparato efektiviĝas dum la ĵetono ankoraŭ validas. Mallongaj ĵetonaj vivdaŭroj malgrandigas la fenestron; eksplicita revoka vojo igas ĝin intenca. Skribu la respondon antaŭ ol ebligi la opcion, ĉar la defaŭlta vojo ne konsultas la eksteran aŭtentikigilon ĉe ĉiu renegoco.

En plurservila deplojo la ĵetona subskriba sekreto devas esti kunhavigata, alie la kliento povas esti sendita al nodo, kiu ne povas validigi ĝian ĵetonon.

Testu limdaton kaj rekonekton, ne nur ensaluton

Malaltigu la renegocan intervalon en testa profilo, por ke la dua manpremo okazu dum vi observas, poste sekvu ambaŭ protokolojn. Konfirmu, ke la ĵetono eldoniĝas ĉe ensaluto, prezentiĝas ĉe ŝlosilrenovigo, kaj renoviĝas aŭ reeldoniĝas laŭ la agordita vivdaŭro. Poste devigu ĵetonan limdaton kaj plenan rekonekton, ĉar kliento, kiu rekonektas pure, ankoraŭ povas fiaski sur la ŝlosilrenoviga vojo.

Testu kontan forigon laste. Tiu kazo diras al vi, ĉu la politiko, kiun vi skribis, estas plenumata aŭ nur dokumentata.

Ne riparu ĝin per malŝalto de renovigo

Agordi la renegocan intervalon al nulo ĉe ambaŭ flankoj forigas la simptomon kaj la ŝlosilrotacion kun ĝi. Tio kaŝas problemon de akreditaĵa reuzado malantaŭ politika ŝanĝo, kiun neniu reviziis. Konservu la renovigon kaj elektu inter servile eldonita ĵetono kaj freŝa interaga defio laŭ tio, ĉu uzanto ĉeestas.

Pli longa reprova tempigilo ne igas elspezitan kodon denove valida. Ĝi nur prokrastas la malkonekton kaj malfaciligas legi la protokolon.