El temporitzador d'inactivitat de la VPN compta trànsit, no teclat
El temps d'espera d'inactivitat de la passarel·la mira els paquets del túnel, no el vostre teclat. Separeu els temporitzadors d'inactivitat, de sessió i de bloqueig de pantalla abans de canviar-ne cap.
El temporitzador que desconnecta una sessió VPN inactiva compta paquets, no pulsacions de teclat. Observa l'absència de comunicació al túnel, així que un portàtil amb correu, un agent de còpies de seguretat o un client de xat en segon pla mai no li sembla inactiu. Aquest sol fet explica les dues direccions de la queixa habitual: una sessió que sobreviu a un dinar llarg i una sessió que mor enmig de feina activa. Decidiu contra quin rellotge baralleu abans de buscar un paràmetre.
Què observa realment el temporitzador
En un Cisco ASA el paràmetre és vpn-idle-timeout, s'estableix en una política de grup o d'usuari i mesura un període sense activitat de comunicació. La unitat és minuts, el valor per defecte s'hereta i la comprovació es fa contra els comptadors de trànsit de la sessió, no contra el que el sistema operatiu sap dels dispositius d'entrada. La passarel·la no té ni idea si hi ha una persona al teclat. Sap quan va veure per última vegada un paquet d'aquell client.
El segon rellotge és vpn-session-timeout i és absolut. Comença quan s'estableix la sessió i caduca independentment de com d'ocupat estigui el túnel. Una sessió que acaba després d'exactament una hora d'ús intens és aquest temporitzador, no un temporitzador d'inactivitat, i cap quantitat d'escriptura l'allargarà.
Llegiu tots dos valors abans de canviar-ne qualsevol, perquè fallen de maneres que des de la cadira de l'usuari semblen idèntiques.
Tres rellotges diferents que la gent en diu inactivitat
Tres polítiques sense relació es descriuen com el temporitzador d'inactivitat, i només una tracta del silenci de la xarxa.
| Measure | What it observes | How it fails |
|---|---|---|
| Gateway idle timeout | No packets from the client on the tunnel | Drops after a quiet period, survives background traffic |
| Gateway session timeout | Elapsed time since the session was established | Drops at a fixed interval no matter how active the tunnel is |
| Screen lock and device policy | Human presence at the device | Session stays up while the laptop sits unattended and unlocked |
La tercera fila és la que la gent vol de debò quan diu que la VPN hauria de bloquejar-se quan algú s'allunya. Un temporitzador de VPN no pot mesurar la presència. Si el requisit és que un portàtil desatengut perdi l'accés, això pertany a la política de bloqueig de pantalla i de dispositiu, on es pot aplicar independentment del trànsit de fons.
Barrejar els tres produeix peticions com desconnecta després de trenta minuts sense escriure, que cap passarel·la VPN pot implementar honestament.
Trobeu la política que posseeix aquesta connexió
Identifiqueu el client i el protocol abans de buscar un paràmetre. El perfil Cisco IPsec integrat de macOS, una connexió L2TP nativa i Cisco Secure Client no exposen els mateixos controls, i una captura d'una casella de desconnecta si està inactiu en un d'ells no és evidència sobre els altres. Els perfils natius exposen poca cosa més enllà del servidor, el compte i el secret compartit. El temporitzador viu a la passarel·la.
A l'ASA, llegiu la política efectiva de l'usuari o del grup en lloc de la política per defecte de tothom:
show running-config group-policy NAME | include timeout
show vpn-sessiondb detail anyconnect filter name USERLa sortida de detall de la sessió llista els temps d'inactivitat i de sessió que s'han aplicat realment, amb el temps restant. Aquesta és la política efectiva, herència inclosa, cosa que un extracte de running-config no us pot dir. Compareu-la amb el grup on creieu que és l'usuari, perquè una política d'usuari substitueix la de grup.
Per què el vostre Mac sembla connectat al cap de trenta minuts
El trànsit de fons és la resposta habitual, i no és un error. El correu, la sincronització de fotos, una comprovació d'actualitzacions, un client de xat que manté un sòcol obert o una pestanya del navegador amb un web socket generen cadascun paquets que la passarel·la compta com a activitat. El túnel es manté perquè s'utilitza de veritat, només que no per vosaltres. Mireu els comptadors en lloc de la pantalla si voleu proves.
La imatge inversa és la sessió que cau mentre escriviu, que és un temps d'espera de sessió o un canvi de política de l'administrador, no inactivitat.
També hi ha un efecte del costat del client que val la pena conèixer. Alguns clients envien els seus propis senyals de manteniment o sondes de parell mort, i aquests paquets reinicien el comptador d'inactivitat de la passarel·la. Per això funciona un senyal de manteniment afegit per derrotar un temps d'espera, i per això és l'eina equivocada: canvia l'evidència que veu el temporitzador sense canviar el requisit d'autorització que hi ha darrere de la política.
Canvieu el paràmetre correcte sense trencar-ne el sentit
Si l'objectiu és acabar una classe de connexió després d'una inactivitat de xarxa aprovada, demaneu exactament això en el llenguatge de la política i manteniu la durada màxima de la sessió com un valor separat i deliberat. Després proveu-ho segons el procediment de l'administrador amb la feina de fons comptada.
Si l'objectiu és aturar l'accés quan una persona deixa l'escriptori, la VPN és la capa equivocada per aplicar-ho.
No afegiu mai un senyal de manteniment que generi trànsit només per mantenir una sessió més enllà d'una política escrita per acabar-la. Això converteix un control en una formalitat, i es descobreix en una auditoria, no en un tiquet. Canvieu la política, o canvieu el requisit.