Azure VPN Client 3.4 si disconnette ogni ora: frequenza di accesso

Un utente si connette, lavora, poi viene disconnesso una volta all’ora con un messaggio che l’autenticazione con Microsoft Entra è scaduta. La riconnessione funziona e il ciclo si ripete come un cronometro. Su un gateway da punto a sito dove non è stato distribuito nulla, questo schema indica la credenziale e non il tunnel. Azure VPN Client 3.4.0 ha iniziato ad applicare la frequenza di accesso dell’Accesso condizionale durante una sessione già stabilita, una polizza che i client precedenti valutavano solo al momento dell’accesso.

Esegui i sei controlli seguenti in ordine. Ognuno conferma o esclude la cadenza, e fermarsi troppo presto è il modo per ricostruire un gateway senza motivo.

Passo 1: leggere il messaggio esatto

La formulazione separa i livelli. Un messaggio sulla scadenza dell’autenticazione Entra riguarda il token; un errore di tunnel o di associazione di sicurezza no. Annota anche il tempo trascorso, misurato dalla connessione alla disconnessione e non dall’inizio della giornata lavorativa.

Se l’utente riesce a riconnettersi subito e il gateway mostra ancora un tunnel sano, si tratta di scadenza del token, non di un peer morto.

Passo 2: ricavare la versione del client

Leggi la versione dall’app, non dal registro di distribuzione. La modifica è arrivata con 3.4.0, quindi 3.3.1 e precedenti mantengono vivo un tunnel stabilito indipendentemente dalla polizza. Un portatile non gestito con una build più vecchia si comporta perfettamente mentre il resto del team cade ogni ora: è il tipo di spaccatura che riporta le persone al gateway. La versione è una proprietà del client, e il gateway non sa quale build sia connessa.

Aggiorna prima un dispositivo di prova e osserva l’orologio. Un dispositivo che inizia a cadere nell’intervallo della polizza dopo l’aggiornamento conferma il meccanismo senza toccare la polizza di produzione.

Passo 3: trovare dove risiede la polizza

La frequenza di accesso è un’impostazione di Accesso condizionale nella polizza che punta all’applicazione aziendale Azure VPN. Non si trova sulla risorsa gateway VPN, né nella configurazione da punto a sito, né nel profilo client. Cerca l’app Azure VPN nell’elenco delle polizze e leggi i controlli di sessione.

Due polizze possono applicarsi a un utente e vince la più severa, quindi un valore che non hai mai impostato può essere quello in vigore. Controlla sia una polizza di base a livello di tenant sia quella specifica dell’app. Anche l’ambito del report conta: una polizza che esclude un gruppo produce una popolazione con comportamento diverso e senza spiegazione evidente.

Passo 4: fare i conti

La disconnessione arriva un’ora dopo il valore di frequenza di accesso, nel comportamento che Microsoft documenta per questo client: una frequenza di sette ore dà circa otto ore di connettività. Questo scostamento spiega perché un valore scelto per una giornata di otto ore sembri rotto nel pomeriggio mentre un test di nove ore va bene. Converti la lamentela in numeri prima di cambiare qualcosa: ora di connessione, ora di disconnessione, differenza, poi confronto con il valore della polizza più un’ora.

Se la differenza non corrisponde a quella somma, l’ipotesi della cadenza è sbagliata e devi smettere di ritoccare la polizza.

Passo 5: distinguere una cadenza da un rekey

Il rekey IPsec, il rilevamento del peer morto e i timeout di inattività producono interruzioni irregolari legate al volume di traffico o al silenzio, non a un cronometro. Un utente interrotto a metà trasferimento e uno interrotto dopo un pranzo inattivo descrivono meccanismi diversi. Chiedi cosa stava facendo l’utente nel minuto prima della disconnessione.

I problemi di certificato hanno un altro aspetto: il client non riesce a connettersi invece di perdere una sessione attiva, e il guasto è immediato. Una richiesta MFA che non si completa mai si presenta come un blocco, non come un taglio orario pulito seguito da una riconnessione riuscita.

Passo 6: distribuire senza sorprese

Annuncia l’aggiornamento del client prima che raggiunga gli utenti tramite lo store, perché la modifica di comportamento viaggia con il client. Scegli la frequenza in base al requisito: un valore che copra la giornata lavorativa per l’usabilità, o un valore breve se un portatile smarrito deve perdere l’accesso rapidamente. Registra quale requisito ha vinto, poiché la stessa impostazione produce sia la protezione sia la lamentela. Poi conferma la scelta su un dispositivo con la nuova build invece di estrapolare da un pilota con la vecchia.

Conserva messaggio, versione, valore della polizza e intervallo misurato in un’unica nota. Quel registro risponde al prossimo avviso in un minuto invece che con una ricostruzione.