Odpojení VPN může nastat z důvodů, které z pohledu klienta vypadají stejně a uvnitř nemají nic společného: relace tunelu skončila, spustil se časovač nečinnosti nebo zastaraly přihlašovací údaje, které klient znovu používal. Každý má jiného vlastníka a jinou opravu. Právě sled chyb v okamžiku odpojení je odlišuje, a obvykle jde o jeden řádek.

Proti jednomu tunelu běží troje hodiny a jen jedny z nich jsou tunel.

Troje různé hodiny na jednom tunelu

Hodiny relace patří bráně: maximální doba připojení, časový limit nečinnosti, nebo obojí, a tunel ukončí, jakmile je dosaženo kterékoli z nich. Hodiny tokenu patří ověřovacímu systému a rozhodují, jak dlouho lze přihlašovací údaj znovu předložit bez člověka. Hodiny cesty patří jakémukoli NAT nebo firewallu mezi klientem a bránou a nechávají vypršet mapování pro toky, které považují za dokončené. Všechny tři způsobí odpojení a žádné z nich neprodukuje stejný řádek v logu.

Jen první je pojem VPN. Zbývající dvoje pochází z oblasti identity a sítí a běžně se s ním zaměňují.

Jak se token skutečně znovu používá

Servery OpenVPN mohou po prvním přihlášení vydat ověřovací token, takže renegociace řídicího kanálu znovu nežádá uživatele o přihlašovací údaje. Klient tento token dál předkládá a server rozhoduje, jak dlouho zůstane přijatelný. Když je životnost tokenu kratší než interval renegociace, příští renegociace selže a klient nahlásí chybu ověření místo časového limitu. Proto stejný profil funguje hodinu a pak selže v pevném bodě.

Interval renegociace je samostatné nastavení. Jeho změna posouvá, kdy se token předkládá, ne jak dlouho žije.

Jak každé vypršení vypadá z pohledu klienta

Časový limit relace obvykle přichází jako čisté odpojení s důvodem na straně serveru, často po předvídatelné době a bez ověřovací chyby. Časový limit nečinnosti vypadá jako ticho: tunel přestane přenášet provoz a pak to keepalive vzdá. Vypršení tokenu přijde jako AUTH_FAILED uprostřed relace, která ještě před sekundou fungovala.

Přečtěte řádek a pak se podívejte na hodiny. Doba, která odpovídá nastavené hodnotě, není náhoda.

Proč uložené heslo nepomůže

Uložené heslo v mezipaměti odpovídá na výzvu k zadání hesla. Neprodlužuje životnost tokenu a neuspokojí výzvu druhého faktoru ani kontrolu stavu zařízení. Zvyšování frekvence opakování, zkracování časových limitů připojení nebo opětovný import profilu nic nemění na tom, jak dlouho bude systém identity přihlašovací údaj přijímat.

Trvalé opravy jsou správná životnost na správném objektu, nebo klientský tok, který dokáže požadovanou výzvu dokončit bez člověka.

Co zdokumentovat a otestovat

Zapište všechny tři hodnoty: limity relace a nečinnosti brány, životnost tokenu a nejkratší relevantní časový limit mapování na cestě. Pak každé vypršení cíleně otestujte zkrácením jedné hodnoty, sledováním, co klient hlásí, a obnovením hodnoty. Potvrďte, co musí uživatel na každé hranici udělat, protože vyžadovat plné přihlášení každou hodinu je politické rozhodnutí, které měl někdo udělat záměrně.

Odpojení, které přijde úplně bez ověřovací události, patří cestě nebo časovači nečinnosti, což je jiné vyšetřování s jinými důkazy.

Související články