Tunel koji je radio satima traži lozinku u trenutku kada se laptop probudi, a ništa u konfiguraciji nije promenjeno. Promenilo se stanje podataka za prijavu koje je ponovno povezivanje pokušalo ponovo da iskoristi. Time upravljaju tri vrste materijala, i samo jedna od njih preživljava proizvoljnu pauzu.

Pročitajte koju je klijent tražio, jer sve tri ističu po različitim satovima i odbijaju se različitim porukama.

Tri vrste materijala koji se može ponovo iskoristiti

Keširana lozinka je tajna koju drži klijent i važi dok je nalog ne promeni. Sesijski token izdaje server nakon uspešne prijave, nosi sopstveni rok i može se opozvati u svakom trenutku. TLS sesijska karta ili IKE bezbednosna asocijacija je protokolno stanje, jeftino za nastavak i potpuno nezavisno od vaše lozinke. Svaku izdaje druga komponenta i svaka ističe pod sopstvenim uslovima.

Prva preživljava restart, druga obično preživljava suspenziju, a treća možda uopšte ne preživi promenu mreže. Njihovo mešanje daje pogrešno rešenje, poput resetovanja lozinke koja nikada nije odbijena.

Sam upit je dijagnostika. Prozor pregledača ili kod drugog faktora znači da je server zahtevao interaktivnu autentifikaciju, dok tiha greška bez upita znači da klijent nikada nije stigao dovoljno daleko da bude pitan.

MaterialTypical lifetimeWhat invalidates it
Cached passwordUntil changedAccount or password policy change
Session tokenMinutes to hoursExpiry, revocation, reauthentication policy
Tunnel SA or TLS ticketConfigured rekey intervalRekey, network change, peer restart

Obnavljanje ključeva nije ponovna autentifikacija

Obnavljanje ključeva zamenjuje ključeve zadržavajući autentifikovani identitet, zato se na zdravom tunelu s vremena na vreme događa tiho. Ponovna autentifikacija ponavlja samu proveru identiteta i to je događaj kome ste potrebni. IKEv2 eksplicitno razdvaja to dvoje, a partner može zahtevati potpunu ponovnu autentifikaciju u zadatom intervalu bez obzira na to koliko je obnavljanja ključeva bilo između. Spolja su ta dva događaja identična dok ne pročitate koje od njih dnevnik imenuje.

OpenVPN se ponaša isto u svom rečniku: interval ponovnog pregovaranja osvežava podatkovni kanal, a autentifikacijski token može se vratiti klijentu kako bi se izbegla potpuna prijava pri sledećoj vezi. Taj token ima rok i server odlučuje hoće li ga ponovo prihvatiti.

Tako ponovno povezivanje nakon osam sati može pasti tamo gde je ponovno povezivanje nakon osam minuta uspelo, bez ikakve promene konfiguracije ni na jednoj strani. To je celo objašnjenje za upit koji se pojavljuje samo posle ručka.

Kada klijent ne može da dovrši novi izazov

Politika koja zahteva korak u pregledaču pašće na klijentu koji nema kako to da prikaže. Serveri bez interfejsa, skripte za pokretanje i stari profili građeni za autentifikaciju samo lozinkom svi udaraju u taj zid, a greška se često pojavljuje kao opšte isticanje vremena, a ne kao greška autentifikacije.

Prelazi uređaja i mreže takođe mogu pasti unutar prozora za procenu politike, pa se prelazak sa Wi-Fi na pristupnu tačku poklapa sa proverom koja bi se ionako dogodila. Ta slučajnost čini mrežu krivom kada je uzrok tajmer.

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

Prvi red prikazuje događaje ponovnog pregovaranja i autentifikacije u klijentovom sopstvenom dnevniku, a drugi prikazuje bezbednosne asocijacije koje strongSwan partner trenutno drži. Uporedite vremenske oznake sa trenutkom pojave upita; poklapanje potvrđuje tajmer, a ne mrežu.

Šta prijaviti i šta ne isključivati

Ako ručna prijava uspeva, a automatska ponovna upotreba dosledno pada, recite to tačno operateru. To imenuje komponentu: put ponovne upotrebe, ne podatke za prijavu. Uključite vreme kvara, korišteni nalog i vrstu upita koju ste videli.

Ne isključujte drugi faktor, ne preskačite proveru sertifikata i ne lepite podatke za prijavu u skriptu da bi povezivanje bilo tiho. Svako od toga uklanja proveru koju politika postoji da sprovede, i svako pretvara upit za prijavu u incident.

Zatražite umesto toga podržani tok: klijenta koji može da dovrši izazov, rok tokena koji odgovara radnom danu ili odobreni neinteraktivni profil za mašinu koja ne može da pita. Sve su to konfiguracione odluke koje neko može da odobri, što zaobilazno rešenje nije.

Povezani članci