Cronometrul sesiunii VPN și tokenul de autentificare expiră separat

O întrerupere VPN poate apărea din motive care par identice din partea clientului și nu au nimic în comun dedesubt: sesiunea tunelului s-a încheiat, s-a declanșat un cronometru de inactivitate sau o acreditare pe care clientul o refolosea a devenit învechită. Fiecare are alt proprietar și altă soluție. Tocmai succesiunea erorilor din momentul întreruperii le separă, și de obicei este o singură linie.

Trei ceasuri merg împotriva unui singur tunel, și doar unul dintre ele este tunelul.

Trei ceasuri diferite pe un singur tunel

Ceasul sesiunii aparține gateway-ului: o durată maximă de conexiune, o limită de inactivitate sau ambele, și închide tunelul când este atins oricare dintre ele. Ceasul tokenului aparține sistemului de autentificare și decide cât timp o acreditare poate fi prezentată din nou fără un om. Ceasul căii aparține oricărui NAT sau firewall dintre client și gateway, și lasă să expire mapările fluxurilor pe care le consideră încheiate. Toate trei produc o deconectare, și niciunul nu produce aceeași linie de jurnal.

Doar primul este un concept VPN. Celelalte două sunt împrumutate din identitate și rețele, și sunt confundate cu el în mod obișnuit.

Cum este tokenul refolosit de fapt

Servere OpenVPN pot emite un token de autentificare după autentificarea inițială, astfel încât o renegociere a canalului de control nu mai cere acreditări de la utilizator. Clientul continuă să prezinte tokenul, iar serverul decide cât timp acesta rămâne acceptabil. Când durata de viață a tokenului este mai scurtă decât intervalul de renegociere, următoarea renegociere eșuează și clientul raportează o eroare de autentificare în loc de un timp limită. De aceea același profil funcționează o oră și apoi eșuează într-un punct fix.

Intervalul de renegociere este o setare separată. Modificarea lui mută momentul în care tokenul este prezentat, nu cât timp trăiește.

Cum arată fiecare expirare din partea clientului

O limită de timp a sesiunii sosește de obicei ca o deconectare curată cu un motiv din partea serverului, adesea după o durată previzibilă și fără nicio eroare de autentificare. O limită de inactivitate arată ca tăcere: tunelul nu mai transportă trafic, apoi mecanismul de menținere a conexiunii renunță. O expirare a tokenului sosește ca AUTH_FAILED în mijlocul unei sesiuni care funcționa cu o secundă înainte.

Citiți linia, apoi uitați-vă la ceas. O durată care corespunde unei valori configurate nu este o coincidență.

De ce o parolă salvată nu ajută

O parolă din cache răspunde la o provocare pentru o parolă. Nu prelungește durata de viață a unui token și nu satisface o provocare pentru un al doilea factor sau o verificare a stării dispozitivului. Creșterea frecvenței reîncercărilor, scurtarea limitelor de timp ale conexiunii sau reimportarea profilului nu schimbă nimic în privința cât timp sistemul de identitate va accepta acreditarea.

Remediile durabile sunt durata de viață corectă pe obiectul corect, sau un flux de client care poate finaliza provocarea necesară fără un om.

Ce trebuie documentat și testat

Notați toate trei valorile: limitele de sesiune și de inactivitate ale gateway-ului, durata de viață a tokenului și cea mai scurtă limită de timp de mapare relevantă pe cale. Apoi testați fiecare expirare în mod deliberat, scurtând o valoare, observând ce raportează clientul și restabilind-o. Confirmați ce trebuie să facă utilizatorul la fiecare graniță, deoarece a cere o autentificare completă la fiecare oră este o decizie de politică pe care cineva ar fi trebuit să o ia în mod deliberat.

O întrerupere care sosește fără niciun eveniment de autentificare aparține căii sau cronometrului de inactivitate, iar aceasta este o altă investigație cu alte dovezi.