De ce o reconectare VPN cere din nou date de autentificare

Un tunel care a funcționat ore întregi cere o parolă în momentul în care laptopul se trezește, iar nimic din configurație nu s-a schimbat. Ce s-a schimbat este starea credențialei pe care reconectarea a încercat să o refolosească. Trei tipuri de material guvernează asta, și doar unul dintre ele supraviețuiește unui interval arbitrar.

Citiți pe care a cerut-o clientul, pentru că toate trei expiră după ceasuri diferite și eșuează cu mesaje diferite.

Trei tipuri de material reutilizabil

O parolă din cache este un secret ținut de client și rămâne valabilă până când contul o schimbă. Un token de sesiune este emis de server după o autentificare reușită, are propria durată de viață și poate fi revocat în orice moment. Un bilet de sesiune TLS sau o asociere de securitate IKE este stare de protocol, ieftin de reluat și complet independent de parola dumneavoastră. Fiecare este emis de o componentă diferită și fiecare expiră în condițiile sale.

Primul supraviețuiește unei reporniri, al doilea supraviețuiește de obicei unei suspendări, iar al treilea poate să nu supraviețuiască deloc unei schimbări de rețea. Confundarea lor produce soluția greșită, cum ar fi resetarea unei parole care nu a fost niciodată respinsă.

Promptul în sine este diagnosticul. O fereastră de browser sau un cod de al doilea factor înseamnă că serverul a cerut autentificare interactivă, în timp ce o eșuare silențioasă fără prompt înseamnă că clientul nu a ajuns niciodată suficient de departe pentru a fi întrebat.

Reînnoirea cheilor nu este reautentificare

O reînnoire a cheilor înlocuiește cheile păstrând identitatea autentificată, de aceea se întâmplă silențios din când în când pe un tunel sănătos. Reautentificarea repetă însăși verificarea identității, iar acesta este evenimentul care are nevoie de dumneavoastră. IKEv2 le separă explicit, iar un peer poate cere o reautentificare completă la un interval configurat, indiferent câte reînnoiri de chei au avut loc între timp. Cele două evenimente arată identic din exterior până când citiți pe care îl numește jurnalul.

OpenVPN se comportă la fel în propriul vocabular: un interval de renegociere reîmprospătează canalul de date, iar un token de autentificare poate fi returnat clientului pentru a evita o autentificare completă la următoarea conexiune. Acel token are o durată de viață, iar serverul decide dacă îl acceptă din nou.

Astfel, o reconectare după opt ore poate eșua acolo unde o reconectare după opt minute a reușit, fără nicio modificare de configurație de ambele părți. Aceasta este întreaga explicație pentru un prompt care apare doar după prânz.

Când clientul nu poate finaliza noua provocare

O politică ce cere un pas în browser va eșua pe un client care nu are cum să afișeze unul. Servere fără interfață, scripturi de pornire și profiluri vechi construite pentru autentificare doar cu parolă lovesc toate acel zid, iar eșuarea apare adesea ca un timeout generic și nu ca o eroare de autentificare.

Tranzițiile de dispozitiv și rețea pot cădea și ele într-o fereastră de evaluare a politicii, așa că o migrare de la Wi-Fi la un hotspot coincide cu o verificare care s-ar fi întâmplat oricum. Coincidența face rețeaua să pară vinovată când cauza este temporizatorul.

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

Prima linie arată evenimente de renegociere și autentificare în jurnalul propriu al clientului, iar a doua arată asocierile de securitate pe care un peer strongSwan le deține acum. Comparați marcajele de timp cu momentul în care a apărut promptul; o potrivire confirmă temporizatorul, nu rețeaua.

Ce trebuie raportat și ce nu trebuie dezactivat

Dacă o autentificare manuală reușește și refolosirea automată eșuează constant, spuneți exact asta operatorului. Aceasta numește componenta: calea de refolosire, nu credențiala. Includeți ora eșuării, contul folosit și tipul de prompt pe care l-ați văzut.

Nu dezactivați al doilea factor, nu săriți peste validarea certificatului și nu lipiți credențiale într-un script pentru a face reconectarea silențioasă. Fiecare dintre acestea elimină verificarea pe care politica există să o impună, și fiecare transformă un prompt de autentificare într-un incident.

Cereți în schimb fluxul acceptat: un client care poate finaliza provocarea, o durată de viață a tokenului potrivită pentru ziua de lucru, sau un profil neinteractiv aprobat pentru mașina care nu poate întreba. Toate sunt decizii de configurare pe care cineva le poate aproba, ceea ce o soluție ocolitoare nu este.