OpenVPN později ukončí relaci OTP: co potřebuje opětovné ověření

Ze strany klienta to vypadá jako náhodné odpojení hodinu po začátku fungující relace. Ikona v oznamovací oblasti zmizí, tunel se znovu sestaví a protokol ukazuje selhání ověření, nikoli chybu sítě. Ve skutečnosti relace znovu vyjednala a druhé navázání spojení potřebovalo přihlašovací údaje, jejichž platnou kopii klient už neměl. Jednorázový kód, který fungoval při přihlášení, nemůže fungovat znovu, takže obnova klíče selže přesně tak, jak byla navržena.

Oprava spočívá v rozhodnutí, co má druhé navázání spojení předložit, ne v delším časovači opakování.

Sledujte výměnu z pohledu klienta

Při přihlášení klient odešle uživatelské jméno, heslo a kód z tokenu a server kombinaci přijme. Relace pak běží, dokud nezabere spouštěč opětovného vyjednání, který zahájí nové navázání TLS uvnitř existujícího tunelu. To navázání znovu žádá ověření. Pokud cesta ověření na serveru očekává heslo plus aktuální jednorázový kód, klient nemá nový kód, který by nabídl, pokud uživatel není přítomen, aby jej zadal.

Většina klientů neotevře výzvu uprostřed relace, takže navázání vyprší a tunel spadne. Uživatel vidí opětovné připojení, ne výzvu k ověření, a proto první hlášení obvykle viní síť.

auth-gen-token mění, kdo odpovídá na druhou otázku

auth-gen-token je volba, která umožňuje serveru vydat token po úspěšném přihlášení, a pozdější opětovná vyjednání předkládají tento token místo opakování hesla a kódu. Příručka dokumentuje jeho životnost a chování při obnově a s tokenem se musí zacházet jako s přihlašovacím údajem s vlastní expirací. Ve výchozí cestě server ověřuje token sám, místo aby znovu volal externí ověřovač hesel.

S externí integrací ověřování se toto rozdělení mění. Plugin musí rozumět stavu tokenu a uplatňovat vlastní kontroly, protože server už není jedinou součástí, která rozhoduje, zda relace pokračuje. Zacházet s tokenem jako s dalším číselným jednorázovým kódem není implementací této funkce.

Rozhodněte, co se stane se stavem účtu

Token, který přežije přístup k účtu, je díra v politice. Rozhodněte, jak se deaktivovaný účet, odebrané členství ve skupině nebo odvolané zařízení prosadí, dokud je token ještě platný. Krátké životnosti tokenů zmenšují okno; výslovná cesta odvolání jej činí záměrným. Napište odpověď, než volbu zapnete, protože výchozí cesta se při každém opětovném vyjednání neobrací na externí ověřovač.

Při nasazení s více servery musí být tajemství pro podepisování tokenů sdílené, jinak může být klient poslán na uzel, který jeho token nedokáže ověřit.

Testujte expiraci a opětovné připojení, ne jen přihlášení

Snižte interval opětovného vyjednání v testovacím profilu, aby druhé navázání proběhlo, když se díváte, a pak sledujte oba protokoly. Potvrďte, že token se vydává při přihlášení, předkládá při obnově klíče a obnovuje nebo znovu vydává podle nastavené životnosti. Poté vynuťte expiraci tokenu a úplné opětovné připojení, protože klient, který se čistě připojí, může na cestě obnovy klíče stále selhat.

Odebrání účtu testujte nakonec. Ten případ vám řekne, zda se politika, kterou jste napsali, prosazuje, nebo je jen zdokumentovaná.

Neopravujte to vypnutím obnovy

Nastavení intervalu opětovného vyjednání na nulu na obou stranách odstraní symptom i rotaci klíčů. Tím se problém opakovaného použití přihlašovacích údajů skryje za změnu politiky, kterou nikdo nezkontroloval. Ponechte obnovu a vyberte mezi tokenem vydaným serverem a novou interaktivní výzvou podle toho, zda je uživatel přítomen.

Delší časovač opakování neudělá spotřebovaný kód znovu platným. Jen oddálí odpojení a ztíží čtení protokolu.