Proč opětovné připojení VPN znovu žádá přihlašovací údaje

Tunel, který fungoval celé hodiny, si v okamžiku probuzení notebooku vyžádá heslo, a v konfiguraci se nic nezměnilo. Změnil se stav přihlašovacích údajů, které se opětovné připojení pokusilo znovu použít. To řídí tři druhy materiálu a jen jeden z nich přežije libovolnou pauzu.

Přečtěte si, který z nich klient požadoval, protože všechny tři vyprší podle jiných hodin a selhávají s jinými zprávami.

Tři druhy opakovaně použitelného materiálu

Uložené heslo je tajemství, které drží klient, a zůstává platné, dokud ho účet nezmění. Token relace vydává server po úspěšném přihlášení, nese vlastní životnost a lze ho kdykoli zneplatnit. Tiket relace TLS nebo IKE bezpečnostní asociace je stav protokolu, levný na obnovení a zcela nezávislý na vašem heslu. Každý vydává jiná komponenta a každý vyprší za vlastních podmínek.

První přežije restart, druhý obvykle přežije uspání a třetí nemusí přežít změnu sítě vůbec. Jejich záměna vede k nesprávné opravě, například k resetu hesla, které nikdy nebylo odmítnuto.

Samotná výzva je diagnóza. Okno prohlížeče nebo kód druhého faktoru znamená, že server vyžadoval interaktivní ověření, zatímco tiché selhání bez výzvy znamená, že klient nedošel dost daleko na to, aby byl dotázán.

Obnova klíčů není opětovné ověření

Obnova klíčů nahrazuje klíče při zachování ověřené identity, a proto se na zdravém tunelu občas děje tiše. Opětovné ověření zopakuje samotnou kontrolu identity, a to je událost, která vás potřebuje. IKEv2 obojí výslovně odděluje a protějšek může v nastaveném intervalu vyžadovat úplné opětovné ověření bez ohledu na to, kolik obnov klíčů mezitím proběhlo. Obě události vypadají zvenčí stejně, dokud nepřečtete, kterou z nich protokol označuje.

OpenVPN se chová stejně ve své vlastní terminologii: interval opětovného vyjednávání obnovuje datový kanál a autentizační token lze vrátit klientovi, aby se při dalším připojení vyhnul plnému přihlášení. Tento token má životnost a server rozhoduje, zda ho znovu přijme.

Opětovné připojení po osmi hodinách tedy může selhat tam, kde opětovné připojení po osmi minutách uspělo, bez jakékoli změny konfigurace na kterékoliv straně. To je celé vysvětlení výzvy, která se objeví jen po obědě.

Když klient nemůže dokončit novou výzvu

Zásada vyžadující krok v prohlížeči selže na klientovi, který ho nemá jak zobrazit. Servery bez grafického rozhraní, spouštěcí skripty a starší profily stavěné na ověřování jen heslem do toho narážejí, a selhání se často projeví jako obecný timeout, nikoli jako chyba ověření.

Přechody zařízení a sítě mohou také spadat do okna vyhodnocení zásady, takže přechod z Wi-Fi na hotspot se kryje s kontrolou, která by proběhla tak jako tak. Ta náhoda dělá síť vinou, když příčinou je časovač.

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

První řádek ukazuje události opětovného vyjednávání a ověřování ve vlastním logu klienta, druhý ukazuje bezpečnostní asociace, které protějšek strongSwan právě drží. Porovnejte časová razítka s okamžikem, kdy se výzva objevila; shoda potvrzuje časovač, nikoli síť.

Co hlásit a co nevypínat

Pokud ruční přihlášení uspěje a automatické opětovné použití soustavně selhává, řekněte to provozovateli přesně tak. Pojmenuje to komponentu: cestu opětovného použití, nikoli údaje. Uveďte čas selhání, používaný účet a typ výzvy, kterou jste viděli.

Nevypínejte druhý faktor, nepřeskakujte ověření certifikátu a nevkládejte přihlašovací údaje do skriptu, abyste připojení ztišili. Každé z toho odstraňuje kontrolu, kterou má zásada vynucovat, a každé mění výzvu k přihlášení v incident.

Požádejte místo toho podporovaný postup: klienta, který výzvu dokáže dokončit, životnost tokenu odpovídající pracovnímu dni, nebo schválený neinteraktivní profil pro stroj, který se nemůže dotázat. To jsou všechno konfigurační rozhodnutí, která někdo může schválit, což obejití není.