Ein inaktiv VPN-timar tel trafikk, ikkje tastaturaktivitet
Ein *gateway-tidsavbrudd overvakar pakkar på tunnelen, ikkje tastaturet ditt. Separat tidtakarar for tomgang, økter og *skjermlås før du endrar nokre av dei.
Tidtakaren som koplar frå ei inaktiv VPN-økt, tel pakkar, ikkje tastetrykk. Den observerer fråværet av kommunikasjon på tunnelen, så ei berbar datamaskin med e-post, ein backup-agent eller ein chat-klient i bakgrunnen ser aldri uverksam ut for han. Det eine faktum forklarer begge retningar av den vanlege klaga: ei økt som overlever ein lang lunsj, og ei økt som døyr midt i aktivt arbeid. Bestem deg for kva klokke du kjempar før du leitar etter ei innstilling.
Kva tidtakaren faktisk observerer
På ein Cisco ASA er knotten *vpn-idle-timeout, sett under ein gruppepolicy eller ein brukarpolicy, og den måler ein periode utan kommunikasjonsaktivitet. Eininga er minutt, standarden er arva, og sjekken køyrer mot trafikkteljarar på økta i staden for mot alt operativsystemet veit om inndataeiningar. *Gatewayen aner ikkje om eit menneske er ved tastaturet. Den veit når han sist såg ein pakke frå den klienten.
Den andre klokka er *vpn-session-timeout, og den er absolutt. Den startar når økta er etablert og går ut uavhengig av kor oppteke tunnelen er. Ei økt som blir avslutta etter nøyaktig éin time med mykje bruk er den *timeren, ikkje ein inaktiv timar, og inga mengd skriving vil forlengja henne.
Les begge verdiane før du endrar heller, fordi dei feilar på måtar som ser identiske ut frå stolen til brukaren.
Tre ulike klokker folk kallar inaktive
Tre ikkje-relaterte retningslinjer blir beskrivne som inaktiv tidtakar, og berre éin av dei handlar om stille i nettverket.
| 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 |
Den tredje rada er den folk faktisk vil ha når dei seier at *VPN-en skal låsast når nokon går bort. Ein VPN-timar kan ikkje måla nærvær. Viss kravet er at ei ubetent berbar datamaskin mistar tilgang, høyrer det heime i *skjermlås og einingspolicy, der det kan handhevast uavhengig av bakgrunnstrafikk.
Blanding av dei tre produserer førespurnader som fråkopling etter tretti minutt utan å skriva, som ingen *VPN-gateway kan implementera ærleg.
Finn policyen som eig dette sambandet
Identifiser klienten og protokollen før du ser etter ei innstilling. Den innebygde *macOS Cisco Ipsec-profilen, ei innebygd L2TP-tilkopling og Cisco *Secure *Client viser ikkje dei same kontrollane, og eit skjermbilete av ein *frakobling-hvis-idle-avmerkingsboks i ein av dei er ikkje bevis for dei andre. Dei opphavlege profilane avslører lite utover serveren, kontoen og den delte løyndommen. Tidtakaren bur på *gatewayen.
På ASA, les den effektive policyen for brukaren eller gruppa i staden for standardpolicyen for alle:
show running-config group-policy NAME | include timeout
show vpn-sessiondb detail anyconnect filter name USERSesjonsdetaljutgangen viser inaktive og økttidsavbrot som faktisk vart brukt, med gjenverande tid. Det er den effektive policyen, inkludert arv, som eit løpande konfigurasjonsutdrag ikkje kan fortelja deg. Samanlikn det med gruppa du trur brukaren er i, fordi ein brukarpolicy overstyrer gruppepolicyen.
Kvifor *Mac-en din ser tilkopla ut etter tretti minutt
Bakgrunnstrafikk er det vanlege svaret, og det er ikkje ein feil. E-post, biletsynkronisering, ein oppdateringssjekk, ein chat-klient som held ein *socket open, eller ei nettlesarfane med ein *websocket produserer kvar pakkar *gatewayen tel som aktivitet. Tunnelen held fram med å vere oppe fordi den verkeleg blir brukt, berre ikkje av deg. Sjå teljarane i staden for skjermen om du vil ha bevis.
Spegelbiletet er økta som fell medan du skriv, som er eit tidsavbrot for økta eller ein administrators policyendring, ikkje lediggang.
Det er også ein klientsideeffekt verd å vita. Nokre klientar sender sine eigne *keepalives eller *dead-peer-sonder, og desse pakkane tilbakestiller *gatewayens inaktive tel. Det er derfor ein *keepalive lagt til for å overvinna ein timeout fungerer, og kvifor det er feil verktøy: det endrar bevisa tidtakaren ser utan å endra autorisasjonskravet bak policyen.
Byt høgre knottar utan å bryta poenget med den
Viss målet er å avslutta ein tilkoplingsklasse etter godkjend nettverksinaktivitet, be om akkurat det på policyspråket, og behald maksimal øktvarigheit som ein separat og medviten verdi. Test den deretter under prosedyren til administratoren med bakgrunnsarbeid rekneskapsført.
Viss målet er å stoppa tilgangen når ein person forlèt skrivebordet, er VPN feil lag for å handheva det.
Aldri legg til ein trafikkgenererande *keepalive berre for å halda ei økt i live forbi ein policy skriven for å avslutta han. Det konverterer ein kontroll til ein formalitet, og den blir funnen i ein revisjon i staden for i ein billett. Endre policyen, eller endre kravet.