Azure VPN Client 3.4 es desconnecta cada hora: freqüència d’inici de sessió

Un usuari es connecta, treballa i després es desconnecta un cop per hora amb un missatge que l’autenticació amb Microsoft Entra ha caducat. La reconnexió funciona i el cicle es repeteix com un cronòmetre. En una passarel·la punt a lloc on no s’ha desplegat res, aquest patró apunta a la credencial i no al túnel. Azure VPN Client 3.4.0 va començar a aplicar la freqüència d’inici de sessió de l’accés condicional durant una sessió establerta, una política que els clients anteriors només avaluaven en iniciar sessió.

Recorreu les sis comprovacions següents en ordre. Cadascuna confirma o descarta el calendari, i aturar-se massa aviat é com es reconstrueix una passarel·la per res.

Pas 1: llegiu el missatge exacte

La redacció separa les capes. Un missatge sobre la caducitat de l’autenticació Entra és una afirmació sobre el testimoni; un error de túnel o d’associació de seguretat no ho és. Anoteu també el temps transcorregut, mesurat de la connexió a la desconnexió i no des de l’inici de la jornada.

Si l’usuari es pot reconnectar immediatament i la passarel·la encara mostra un túnel sa, esteu davant la caducitat del testimoni i no d’un parell mort.

Pas 2: obteniu la versió del client

Llegiu la versió a l’aplicació, no al registre de desplegament. El canvi va arribar amb 3.4.0, així que 3.3.1 i anteriors mantenen viu un túnel establert independentment de la política. Un portàtil no gestionat amb una compilació anterior es comporta perfectament mentre la resta de l’equip cau cada hora: és el tipus de divisió que fa tornar la gent a la passarel·la. La versió és una propietat del client, i la passarel·la no sap quina compilació hi ha connectada.

Actualitzeu primer un dispositiu de prova i vigileu el rellotge. Un dispositiu que comença a caure a l’interval de la política després de l’actualització confirma el mecanisme sense tocar la política de producció.

Pas 3: trobeu on viu la política

La freqüència d’inici de sessió és un paràmetre d’accés condicional de la política que apunta a l’aplicació empresarial Azure VPN. No és al recurs de passarel·la VPN, ni a la configuració punt a lloc, ni al perfil del client. Cerqueu l’aplicació Azure VPN a la llista de polítiques i llegiu els controls de sessió.

Dues polítiques poden aplicar-se a un usuari, i guanya la més estricta, així que un valor que mai heu definit pot ser el vigent. Reviseu tant una política base per a tot el tinent com la específica de l’aplicació. L’abast de l’informe també importa: una política que exclou un grup produeix una població amb un comportament diferent i sense una explicació evident.

Pas 4: feu els càlculs

La desconnexió arriba una hora després del valor de freqüència d’inici de sessió, en el comportament que Microsoft documenta per a aquest client, així que una freqüència de set hores dóna unes vuit hores de connectivitat. Aquest desfasament explica que un valor triat per a una jornada de vuit hores sembli espatllat a la tarda mentre una prova de nou hores sembla correcta. Convertiu la queixa en números abans de canviar res: hora de connexió, hora de desconnexió, diferència i després comparació amb el valor de la política més una hora.

Si la diferència no coincideix amb aquesta suma, la hipòtesi del calendari és falsa i hauríeu de deixar d’ajustar la política.

Pas 5: separeu un calendari d’una rekey

La rekey IPsec, la detecció de parell mort i els temps d’inactivitat produeixen talls irregulars lligats al volum de tràfic o al silenci, no a un cronòmetre. Un usuari tallat enmig d’una transferència i un altre tallat després d’un dinar inactiu descriuen mecanismes diferents. Pregunteu què feia l’usuari en el minut anterior a la desconnexió.

Els problemes de certificat tenen una altra cara: el client no aconsegueix connectar-se en lloc de perdre una sessió activa, i la fallada és immediata. Una petició MFA que no s’acaba mai es presenta com un bloqueig, no com un tall horari net seguit d’una reconnexió correcta.

Pas 6: desplegueu-ho sense sorpreses

Anuncieu l’actualització del client abans que arribi als usuaris per la botiga, perquè el canvi de comportament viatja amb el client. Trieu la freqüència segons el requisit: un valor que cobreixi la jornada per usabilitat, o un valor curt si un portàtil perdut ha de perdre l’accés ràpidament. Anoteu quin requisit ha guanyat, ja que el mateix paràmetre produeix tant la protecció com la queixa. Després confirmeu l’elecció en un dispositiu amb la nova compilació en lloc d’extrapolar d’un pilot que feia servir l’anterior.

Guardeu el missatge, la versió, el valor de la política i l’interval mesurat en una sola nota. Aquest registre respon al proper avís en un minut en lloc de demanar una reconstrucció.