Prečo opätovné pripojenie VPN znova žiada prihlasovacie údaje

Tunel, ktorý fungoval celé hodiny, si v okamihu prebudenia notebooku vyžiada heslo, a v konfigurácii sa nič nezmenilo. Zmenil sa stav prihlasovacích údajov, ktoré sa opätovné pripojenie pokúsilo znova použiť. Riadi to trojaký druh materiálu, a len jeden z nich prežije ľubovoľnú pauzu.

Prečítajte si, ktorý z nich klient žiadal, lebo všetky tri vypršia podľa iných hodín a zlyhávajú s inými správami.

Tri druhy opakovane použiteľného materiálu

Heslo v pamäti je tajomstvo, ktoré drží klient, a zostáva platné, kým ho účet nezmení. Token relácie vydáva server po úspešnom prihlásení, nesie vlastnú životnosť a možno ho kedykoľvek zrušiť. Tiket relácie TLS alebo bezpečnostná asociácia IKE je stav protokolu, lacný na obnovenie a úplne nezávislý od vášho hesla. Každý vydáva iný komponent a každý vyprší za vlastných podmienok.

Prvý prežije reštart, druhý zvyčajne prežije uspanie a tretí nemusí prežiť zmenu siete vôbec. Ich zámena vedie k nesprávnej oprave, napríklad k resetu hesla, ktoré nikdy nebolo odmietnuté.

Samotná výzva je diagnóza. Okno prehliadača alebo kód druhého faktora znamená, že server vyžadoval interaktívne overenie, kým tiché zlyhanie bez výzvy znamená, že klient nedošiel dosť ďaleko na to, aby bol opýtaný.

Obnova kľúčov nie je opätovné overenie

Obnova kľúčov nahrádza kľúče pri zachovaní overenej identity, preto sa na zdravom tuneli občas deje ticho. Opätovné overenie zopakuje samotnú kontrolu identity, a to je udalosť, ktorá vás potrebuje. IKEv2 obe výslovne oddeľuje a protistrana môže v nastavenom intervale vyžadovať úplné opätovné overenie bez ohľadu na to, koľko obnov kľúčov sa medzitým udialo. Obe udalosti vyzerajú zvonku rovnako, kým neprečítate, ktorú z nich pomenúva záznam.

OpenVPN sa správa rovnako vo svojej vlastnej terminológii: interval opätovného vyjednávania obnovuje dátový kanál a autentizačný token možno vrátiť klientovi, aby sa pri ďalšom pripojení vyhol plnému prihláseniu. Ten token má životnosť a server rozhoduje, či ho znova prijme.

Opätovné pripojenie po ôsmich hodinách teda môže zlyhať tam, kde opätovné pripojenie po ôsmich minútach uspelo, bez akejkoľvek zmeny konfigurácie na oboch stranách. To je celé vysvetlenie výzvy, ktorá sa objaví až po obede.

Keď klient nedokáže dokončiť novú výzvu

Zásada vyžadujúca krok v prehliadači zlyhá na klientovi, ktorý ho nemá ako zobraziť. Servery bez grafického rozhrania, spúšťacie skripty a staré profily postavené na overovaní iba heslom do toho narážajú, a zlyhanie sa často prejaví ako všeobecný časový limit, nie ako chyba overenia.

Prechody zariadení a siete môžu tiež spadať do okna vyhodnotenia zásady, takže prechod z Wi-Fi na hotspot sa zhoduje s kontrolou, ktorá by sa bola udiala tak či tak. Tá náhoda robí sieť vinnou, keď je príčinou časovač.

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

Prvý riadok zobrazuje udalosti opätovného vyjednávania a overovania vo vlastnom logu klienta, druhý zobrazuje bezpečnostné asociácie, ktoré protistrana strongSwan práve drží. Porovnajte časové značky s okamihom, keď sa výzva objavila; zhoda potvrdzuje časovač, nie sieť.

Čo hlásiť a čo nevypínať

Ak ručné prihlásenie uspeje a automatické opätovné použitie dôsledne zlyháva, povedzte to prevádzkovateľovi presne takto. Pomenuje to komponent: cestu opätovného použitia, nie údaje. Uveďte čas zlyhania, používaný účet a typ výzvy, ktorú ste videli.

Nevypínajte druhý faktor, nepreskakujte overenie certifikátu a nevkladajte prihlasovacie údaje do skriptu, aby bolo pripojenie tiché. Každé z toho odstraňuje kontrolu, ktorú má zásada vynucovať, a každé mení výzvu na prihlásenie na incident.

Požiadajte namiesto toho podporovaný postup: klienta, ktorý dokáže dokončiť výzvu, životnosť tokenu zodpovedajúcu pracovnému dňu, alebo schválený neinteraktívny profil pre stroj, ktorý sa nemôže opýtať. To sú všetko konfiguračné rozhodnutia, ktoré niekto môže schváliť, čo obchádzka nie je.