OpenVPN подоцна ја прекинува OTP сесијата: што бара повторната автентикација

Од страната на клиентот изгледа како случајно прекинување на врската по еден час работа. Иконата во системскиот дел за известувања исчезнува, тунелот се обновува, а дневникот покажува грешка при автентикација наместо мрежна грешка. Она што навистина се случило е дека сесијата повторно преговарала и второто ракување барало акредитиви за кои клиентот веќе немал валидна копија. Еднократниот код што работел при најавувањето не може повторно да работи, затоа повторното разменување клучеви паѓа точно како што е предвидено.

Решението е одлука за тоа што треба да претстави второто ракување, а не подолг тајмер за повторување.

Поминете ја размената од гледна точка на клиентот

При најавувањето клиентот го испраќа корисничкото име, лозинката и код од уредот за токени, а серверот ја прифаќа комбинацијата. Потоа сесијата трае додека не се активира тригерот за повторно преговарање, кој започнува ново TLS ракување во постоечкиот тунел. Тоа ракување повторно бара автентикација. Ако патеката за автентикација на серверот очекува лозинка плус тековен еднократен код, клиентот нема нов код да понуди, освен ако корисникот е присутен за да го внесе.

Повеќето клиенти не отвораат барање среде сесија, па ракувањето истекува и тунелот паѓа. Корисникот гледа повторно поврзување, а не барање за автентикација, и затоа првиот извештај обично ја обвинува мрежата.

auth-gen-token менува кој одговара на второто прашање

Опцијата auth-gen-token му дозволува на серверот да издаде токен по успешно најавување, а подоцнежните повторни преговори го претставуваат тој токен наместо да ја повторуваат лозинката и кодот. Прирачникот го документира неговиот животен век и однесувањето при обновување, а токенот мора да се третира како акредитив со сопствен рок на траење. На стандардната патека серверот самиот го валидира токенот наместо повторно да го повикува надворешниот автентикатор на лозинката.

Со интеграција на надворешна автентикација, таа поделба се менува. Приклучокот мора да ја разбере состојбата на токенот и да примени свои проверки, бидејќи серверот веќе не е единствената компонента што одлучува дали сесијата продолжува. Третирањето на токенот како уште еден бројчен еднократен код не е имплементација на оваа функција.

Одлучете што се случува со состојбата на сметката

Токен што го надживува пристапот на сметката е дупка во политиката. Одлучете како оневозможена сметка, отстрането членство во група или отповикан уред делуваат додека токенот е сѐ уште валиден. Краткиот животен век на токенот ја намалува можноста; експлицитна патека за отповикување го прави тоа намерно. Запишете го одговорот пред да ја вклучите опцијата, бидејќи стандардната патека не го консултира надворешниот автентикатор при секое повторно преговарање.

Во распоредување со повеќе сервери, тајната за потпишување на токенот мора да биде споделена, инаку клиентот може да биде испратен на јазол што не може да го валидира неговиот токен.

Тестирајте истекување и повторно поврзување, не само најавување

Намалете го интервалот за повторно преговарање во тест профил за второто ракување да се случи додека гледате, потоа следете ги двата дневника. Потврдете дека токенот се издава при најавување, се претставува при повторно разменување клучеви и се обновува или издава повторно според конфигурираниот животен век. Потоа насилно предизвикајте истекување на токенот и целосно повторно поврзување, бидејќи клиент што чисто се поврзува повторно сѐ уште може да падне на патеката за повторно разменување клучеви.

Тестирајте го отстранувањето на сметка накрај. Тој случај ви кажува дали напишаната политика се спроведува или само се документира.

Не го поправајте со онеспособување на обновувањето

Поставувањето на интервалот за повторно преговарање на нула на двата партнери го отстранува симптомот и заедно со него ротацијата на клучевите. Тоа крие проблем со повторување на акредитивите зад промена на политиката што никој не ја прегледал. Задржете го обновувањето и изберете меѓу токен што го издава серверот и нов интерактивен предизвик врз основа на тоа дали корисникот е присутен.

Подолг тајмер за повторување не го прави повторно валиден веќе потрошен код. Тој само го одложува прекинувањето и го прави дневникот потежок за читање.