Il timer di inattività della VPN conta il traffico, non la tastiera

Il timer che disconnette una sessione VPN inattiva conta i pacchetti, non le battute di tastiera. Osserva l'assenza di comunicazione sul tunnel, quindi un portatile con posta, un agente di backup o un client di chat in background non gli sembra mai inattivo. Questo unico fatto spiega entrambe le direzioni della lamentela abituale: una sessione che sopravvive a un pranzo lungo e una sessione che muore a metà di un lavoro attivo. Decidete contro quale orologio state combattendo prima di cercare un'impostazione.

Che cosa osserva davvero il timer

Su un Cisco ASA il parametro è vpn-idle-timeout, si imposta in una politica di gruppo o di utente e misura un periodo senza attività di comunicazione. L'unità è il minuto, il valore predefinito viene ereditato e il controllo viene eseguito sui contatori di traffico della sessione, non su ciò che il sistema operativo sa dei dispositivi di input. Il gateway non ha idea se ci sia una persona alla tastiera. Sa quando ha visto l'ultimo pacchetto da quel client.

Il secondo orologio è vpn-session-timeout, ed è assoluto. Parte quando la sessione viene stabilita e scade indipendentemente da quanto è occupato il tunnel. Una sessione che termina dopo esattamente un'ora di uso intenso è quel timer, non un timer di inattività, e nessuna quantità di digitazione la prolungherà.

Leggete entrambi i valori prima di cambiarne uno, perché falliscono in modi che dalla sedia dell'utente sembrano identici.

Tre orologi diversi che la gente chiama inattività

Tre politiche non correlate vengono descritte come il timer di inattività, e solo una riguarda il silenzio della rete.

La terza riga è quella che la gente vuole davvero quando dice che la VPN dovrebbe bloccarsi quando qualcuno si allontana. Un timer VPN non può misurare la presenza. Se il requisito è che un portatile incustodito perda l'accesso, questo appartiene alla politica di blocco schermo e del dispositivo, dove può essere imposto indipendentemente dal traffico di fondo.

Mescolare i tre produce richieste come disconnetti dopo trenta minuti senza digitare, che nessun gateway VPN può implementare onestamente.

Trovate la politica che possiede questa connessione

Identificate il client e il protocollo prima di cercare un'impostazione. Il profilo Cisco IPsec integrato di macOS, una connessione L2TP nativa e Cisco Secure Client non espongono gli stessi controlli, e uno screenshot di una casella disconnetti se inattivo in uno di essi non è prova per gli altri. I profili nativi espongono poco oltre al server, all'account e al segreto condiviso. Il timer vive sul gateway.

Sull'ASA leggete la politica effettiva dell'utente o del gruppo invece della politica predefinita per tutti:

show running-config group-policy NAME | include timeout
show vpn-sessiondb detail anyconnect filter name USER

L'output dei dettagli di sessione elenca i timeout di inattività e di sessione effettivamente applicati, con il tempo rimanente. Questa è la politica effettiva, eredità inclusa, cosa che un estratto di running-config non può dirvi. Confrontatela con il gruppo in cui credete che sia l'utente, perché una politica utente prevale sulla politica di gruppo.

Perché il vostro Mac sembra connesso dopo trenta minuti

Il traffico di fondo è la risposta abituale, e non è un difetto. Posta, sincronizzazione delle foto, un controllo degli aggiornamenti, un client di chat che tiene aperto un socket o una scheda del browser con un web socket producono ciascuno pacchetti che il gateway conta come attività. Il tunnel resta aperto perché viene davvero usato, solo non da voi. Guardate i contatori invece dello schermo se volete prove.

L'immagine speculare è la sessione che cade mentre digitate, e quello è un timeout di sessione o un cambio di politica dell'amministratore, non inattività.

C'è anche un effetto lato client che vale la pena conoscere. Alcuni client inviano i propri segnali di mantenimento o sonde di peer morto, e quei pacchetti azzerano il contatore di inattività del gateway. Ecco perché un mantenimento aggiunto per sconfiggere un timeout funziona, ed ecco perché è lo strumento sbagliato: cambia la prova che il timer vede senza cambiare il requisito di autorizzazione dietro la politica.

Cambiate il parametro giusto senza distruggerne lo scopo

Se l'obiettivo è terminare una classe di connessioni dopo un'inattività di rete approvata, chiedete esattamente questo nel linguaggio della politica, e tenete la durata massima della sessione come valore separato e deliberato. Poi provatelo secondo la procedura dell'amministratore, con il lavoro di fondo tenuto in conto.

Se l'obiettivo è fermare l'accesso quando una persona lascia la scrivania, la VPN è lo strato sbagliato per imporlo.

Non aggiungete mai un mantenimento che genera traffico solo per tenere viva una sessione oltre una politica scritta per terminarla. Questo trasforma un controllo in una formalità, e si scopre in un audit piuttosto che in un ticket. Cambiate la politica, o cambiate il requisito.