Ein Inaktivitäts-Timer im VPN zählt Verkehr, nicht Tastatur
Der Inaktivitäts-Timeout des Gateways beobachtet die Pakete auf dem Tunnel, nicht Ihre Tastatur. Trennen Sie Inaktivitäts-, Sitzungs- und Bildschirmsperr-Timer, bevor Sie einen davon ändern.
Der Timer, der eine inaktive VPN-Sitzung trennt, zählt Pakete, nicht Tastenanschläge. Er beobachtet das Fehlen von Kommunikation auf dem Tunnel, deshalb wirkt ein Laptop mit Mail, einem Backup-Agenten oder einem Chat-Client im Hintergrund für ihn nie inaktiv. Diese eine Tatsache erklärt beide Richtungen der üblichen Beschwerde: eine Sitzung, die ein langes Mittagessen übersteht, und eine Sitzung, die mitten in aktiver Arbeit stirbt. Entscheiden Sie, gegen welche Uhr Sie kämpfen, bevor Sie nach einer Einstellung suchen.
Was der Timer tatsächlich beobachtet
Auf einer Cisco ASA ist der Parameter vpn-idle-timeout, er wird unter einer Gruppen- oder Benutzerrichtlinie gesetzt und misst einen Zeitraum ohne Kommunikationsaktivität. Die Einheit ist Minuten, der Standardwert wird geerbt, und die Prüfung läuft gegen die Verkehrszähler der Sitzung und nicht gegen das, was das Betriebssystem über Eingabegeräte weiß. Das Gateway hat keine Ahnung, ob ein Mensch an der Tastatur sitzt. Es weiß, wann es zuletzt ein Paket von diesem Client gesehen hat.
Die zweite Uhr ist vpn-session-timeout, und sie ist absolut. Sie beginnt beim Aufbau der Sitzung und läuft ab, unabhängig davon, wie ausgelastet der Tunnel ist. Eine Sitzung, die nach genau einer Stunde intensiver Nutzung endet, ist dieser Timer und kein Inaktivitätstimer, und keine Menge Tippens verlängert sie.
Lesen Sie beide Werte, bevor Sie einen davon ändern, denn sie versagen auf eine Weise, die vom Stuhl des Benutzers aus identisch aussieht.
Drei verschiedene Uhren, die Leute inaktiv nennen
Drei unabhängige Richtlinien werden als Inaktivitätstimer bezeichnet, und nur eine davon handelt von Netzstille.
| 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 |
Die dritte Zeile ist die, die Leute eigentlich wollen, wenn sie sagen, das VPN solle sperren, wenn jemand weggeht. Ein VPN-Timer kann Anwesenheit nicht messen. Wenn die Anforderung ist, dass ein unbeaufsichtigter Laptop den Zugang verliert, gehört das in die Richtlinie für Bildschirmsperre und Gerät, wo es unabhängig vom Hintergrundverkehr durchgesetzt werden kann.
Die drei zu vermischen erzeugt Anfragen wie nach dreißig Minuten ohne Tippen trennen, die kein VPN-Gateway ehrlich umsetzen kann.
Finden Sie die Richtlinie, der diese Verbindung gehört
Identifizieren Sie Client und Protokoll, bevor Sie nach einer Einstellung suchen. Das integrierte Cisco-IPsec-Profil von macOS, eine native L2TP-Verbindung und Cisco Secure Client bieten nicht dieselben Steuerelemente, und ein Screenshot eines Kontrollkästchens trennen-wenn-inaktiv in einem davon ist kein Beweis für die anderen. Die nativen Profile bieten wenig außer Server, Konto und gemeinsamem Geheimnis. Der Timer lebt auf dem Gateway.
Auf der ASA lesen Sie die effektive Richtlinie für den Benutzer oder die Gruppe statt der Standardrichtlinie für alle:
show running-config group-policy NAME | include timeout
show vpn-sessiondb detail anyconnect filter name USERDie Sitzungsdetails führen die tatsächlich angewandten Inaktivitäts- und Sitzungs-Timeouts mit der verbleibenden Zeit auf. Das ist die effektive Richtlinie einschließlich Vererbung, was ein Auszug aus der running-config Ihnen nicht sagen kann. Vergleichen Sie sie mit der Gruppe, in der der Benutzer Ihrer Meinung nach ist, denn eine Benutzerrichtlinie überschreibt die Gruppenrichtlinie.
Warum Ihr Mac nach dreißig Minuten verbunden aussieht
Hintergrundverkehr ist die übliche Antwort, und es ist kein Fehler. Mail, Fotosynchronisierung, eine Update-Prüfung, ein Chat-Client, der einen Socket offen hält, oder ein Browser-Tab mit einem Websocket erzeugen jeweils Pakete, die das Gateway als Aktivität zählt. Der Tunnel bleibt bestehen, weil er tatsächlich genutzt wird, nur nicht von Ihnen. Schauen Sie auf die Zähler statt auf den Bildschirm, wenn Sie Belege wollen.
Das Spiegelbild ist die Sitzung, die abbricht, während Sie tippen, und das ist ein Sitzungs-Timeout oder eine Richtlinienänderung des Administrators, nicht Untätigkeit.
Es gibt auch einen clientseitigen Effekt, den man kennen sollte. Manche Clients senden eigene Keepalives oder Dead-Peer-Sonden, und diese Pakete setzen den Inaktivitätszähler des Gateways zurück. Deshalb funktioniert ein Keepalive, das hinzugefügt wird, um ein Timeout zu besiegen, und deshalb ist es das falsche Werkzeug: es ändert den Beleg, den der Timer sieht, ohne die Autorisierungsanforderung hinter der Richtlinie zu ändern.
Ändern Sie den richtigen Parameter, ohne den Sinn zu zerstören
Wenn das Ziel ist, eine Klasse von Verbindungen nach genehmigter Netzuntätigkeit zu beenden, verlangen Sie genau das in der Sprache der Richtlinie, und halten Sie die maximale Sitzungsdauer als separaten und bewussten Wert. Testen Sie es dann nach dem Verfahren des Administrators mit berücksichtigter Hintergrundarbeit.
Wenn das Ziel ist, den Zugang zu stoppen, wenn eine Person den Schreibtisch verlässt, ist das VPN die falsche Ebene, um es durchzusetzen.
Fügen Sie niemals ein verkehrserzeugendes Keepalive hinzu, nur um eine Sitzung über eine Richtlinie hinaus am Leben zu halten, die geschrieben wurde, um sie zu beenden. Das macht eine Kontrolle zu einer Formalität, und es wird in einem Audit gefunden, nicht in einem Ticket. Ändern Sie die Richtlinie oder ändern Sie die Anforderung.