Azure VPN Client 3.4 se deconectează la fiecare oră: frecvenţa de autentificare

Un utilizator se conectează, lucrează, apoi este deconectat o dată pe oră, cu mesajul că autentificarea la Microsoft Entra a expirat. Reconectarea funcţionează, iar ciclul se repetă ca un cronometru. Pe un gateway point-to-site unde nu s-a implementat nimic, acest model indică credenţialele, nu tunelul. Azure VPN Client 3.4.0 a început să aplice frecvenţa de autentificare din Accesul condiţionat în timpul unei sesiuni deja stabilite, o politică pe care clienţii anteriori o evaluau doar la autentificare.

Parcurgeţi cele şase verificări de mai jos în ordine. Fiecare confirmă sau elimină programul, iar oprirea prematură este modul în care un gateway este reconstruit degeaba.

Pasul 1: citiţi mesajul exact

Formularea separă straturile. Un mesaj despre expirarea autentificării Entra este o afirmaţie despre token; o eroare de tunel sau de asociere de securitate nu este. Notaţi şi timpul scurs, măsurat de la conectare la deconectare, nu de la începutul zilei de lucru.

Dacă utilizatorul se poate reconecta imediat şi gateway-ul arată în continuare un tunel sănătos, aveţi de-a face cu expirarea tokenului, nu cu un peer mort.

Pasul 2: aflaţi versiunea clientului

Citiţi versiunea în aplicaţie, nu în evidenţa implementării. Schimbarea a venit cu 3.4.0, aşa că 3.3.1 şi versiunile mai vechi menţin un tunel stabilit indiferent de politică. Un laptop neadministrat cu o versiune mai veche se comportă perfect în timp ce restul echipei cade la fiecare oră: exact genul de scindare care trimite oamenii înapoi la gateway. Versiunea este o proprietate a clientului, iar gateway-ul nu ştie ce versiune este conectată.

Actualizaţi mai întâi un dispozitiv de test şi urmăriţi ceasul. Un dispozitiv care începe să cadă la intervalul politicii după actualizare confirmă mecanismul fără să atingă politica de producţie.

Pasul 3: găsiţi unde locuieşte politica

Frecvenţa de autentificare este o setare de Acces condiţionat în politica ce vizează aplicaţia enterprise Azure VPN. Nu se află pe resursa gateway-ului VPN, nici în configuraţia point-to-site, nici în profilul clientului. Căutaţi aplicaţia Azure VPN în lista de politici şi citiţi controalele de sesiune.

Două politici pot viza un singur utilizator, iar cea mai strictă câştigă, aşa că o valoare pe care nu aţi setat-o niciodată poate fi cea în vigoare. Verificaţi atât o politică de bază la nivel de tenant, cât şi pe cea specifică aplicaţiei. Contează şi sfera raportului: o politică ce exclude un grup produce o populaţie cu comportament diferit şi fără explicaţie evidentă.

Pasul 4: faceţi calculul

Deconectarea apare la o oră după valoarea frecvenţei de autentificare, în comportamentul pe care Microsoft îl documentează pentru acest client, aşa că o frecvenţă de şapte ore oferă aproximativ opt ore de conectivitate. Acest decalaj explică de ce o valoare aleasă pentru o zi de lucru de opt ore pare defectă după-amiaza, în timp ce un test de nouă ore pare în regulă. Transformaţi reclamaţia în cifre înainte de a schimba ceva: ora conectării, ora deconectării, diferenţa, apoi comparaţi cu valoarea politicii plus o oră.

Dacă diferenţa nu corespunde acelei sume, ipoteza programului este greşită şi ar trebui să opriţi ajustarea politicii.

Pasul 5: separaţi un program de un rekey

Rekey-ul IPsec, detectarea peer-ului mort şi time-out-urile de inactivitate produc căderi neregulate legate de volumul de trafic sau de linişte, nu de un cronometru. Un utilizator căzut în mijlocul unui transfer şi unul căzut după o pauză de masă inactivă descriu mecanisme diferite. Întrebaţi ce făcea utilizatorul în minutul dinaintea deconectării.

Problemele de certificat arată din nou altfel: clientul nu reuşeşte să se conecteze în loc să piardă o sesiune funcţională, iar eşecul este imediat. O solicitare MFA care nu se încheie niciodată apare ca o blocare, nu ca o cădere orară curată urmată de o reconectare reuşită.

Pasul 6: implementaţi fără surprize

Anunţaţi actualizarea clientului înainte ca ea să ajungă la utilizatori prin magazin, deoarece schimbarea de comportament vine cu clientul. Alegeţi frecvenţa în funcţie de cerinţă: o valoare care acoperă ziua de lucru pentru uzabilitate, sau o valoare scurtă dacă un laptop pierdut trebuie să piardă rapid accesul. Notaţi care cerinţă a câştigat, fiindcă aceeaşi setare produce şi protecţia, şi reclamaţia. Apoi confirmaţi alegerea pe un dispozitiv cu noua versiune, în loc să extrapolaţi dintr-un pilot care rula versiunea veche.

Păstraţi mesajul, versiunea, valoarea politicii şi intervalul măsurat într-o singură notă. Acea evidenţă răspunde următorului raport înntr-un minut, nu printr-o reconstrucţie.