Zašto ponovno povezivanje VPN-a ponovno traži akreditive
Sačuvana lozinka i token koji se može više puta koristiti istječu po različitim rasporedima. Pročitajte koji je materijal ponovno povezivanje tražilo prije nego što bilo šta promijenite na klijentu.
Tunel koji je radio satima traži lozinku u trenutku kada se laptop probudi, a ništa u konfiguraciji nije promijenjeno. Promijenilo se stanje akreditiva koje je ponovno povezivanje pokušalo ponovno upotrijebiti. Time upravljaju tri vrste materijala, i samo jedna od njih preživljava proizvoljnu pauzu.
Pročitajte koju je klijent tražio, jer sve tri istječu po različitim satovima i odbijaju se različitim porukama.
Tri vrste materijala koji se može ponovno upotrijebiti
Keširana lozinka je tajna koju drži klijent i vrijedi dok je račun ne promijeni. Sesijski token izdaje server nakon uspješne prijave, nosi vlastiti rok i može se opozvati u svakom trenutku. TLS sesijska karta ili IKE sigurnosna asocijacija je protokolno stanje, jeftino za nastavljanje i potpuno neovisno od vaše lozinke. Svaku izdaje druga komponenta i svaka istječe po vlastitim uvjetima.
Prva preživljava restart, druga obično preživljava suspenziju, a treća možda uopće ne preživi promjenu mreže. Njihovo miješanje daje pogrešno rješenje, poput resetiranja lozinke koja nikada nije odbijena.
Sam upit je dijagnostika. Prozor preglednika ili kod drugog faktora znači da je server zahtijevao interaktivnu autentifikaciju, dok tiha greška bez upita znači da klijent nikada nije stigao dovoljno daleko da bude pitan.
| Material | Typical lifetime | What invalidates it |
|---|---|---|
| Cached password | Until changed | Account or password policy change |
| Session token | Minutes to hours | Expiry, revocation, reauthentication policy |
| Tunnel SA or TLS ticket | Configured rekey interval | Rekey, network change, peer restart |
Obnavljanje ključeva nije ponovna autentifikacija
Obnavljanje ključeva zamjenjuje ključeve zadržavajući autentificirani identitet, zato se na zdravom tunelu s vremena na vrijeme događa tiho. Ponovna autentifikacija ponavlja samu provjeru identiteta i to je događaj koji vas treba. IKEv2 eksplicitno razdvaja to dvoje, a partner može zahtijevati potpunu ponovnu autentifikaciju u zadanom intervalu bez obzira na to koliko je obnavljanja ključeva bilo između. Izvana su ta dva događaja identična dok ne pročitate koje od njih dnevnik imenuje.
OpenVPN se ponaša isto u vlastitom rječniku: interval ponovnog pregovaranja osvježava podatkovni kanal, a autentifikacijski token može se vratiti klijentu kako bi se izbjegla potpuna prijava pri sljedećoj vezi. Taj token ima rok i server odlučuje hoće li ga ponovno prihvatiti.
Tako ponovno povezivanje nakon osam sati može pasti tamo gdje je ponovno povezivanje nakon osam minuta uspjelo, bez ikakve promjene konfiguracije ni na jednoj strani. To je cijelo objašnjenje za upit koji se pojavljuje samo poslije ručka.
Kada klijent ne može dovršiti novi izazov
Politika koja zahtijeva korak u pregledniku pasti će na klijentu koji ga nema kako prikazati. Serveri bez sučelja, skripte za pokretanje i stari profili građeni za autentifikaciju samo lozinkom svi udaraju u taj zid, a greška se često pojavljuje kao generičko istekanje vremena, a ne kao pogreška autentifikacije.
Prijelazi uređaja i mreže također mogu pasti unutar prozora evaluacije politike, pa se prelazak s Wi-Fi na pristupnu točku poklapa s provjerom koja bi se ionako dogodila. Ta slučajnost čini mrežu krivom kada je uzrok mjerač vremena.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
Prvi redak prikazuje događaje ponovnog pregovaranja i autentifikacije u klijentovu vlastitom dnevniku, a drugi prikazuje sigurnosne asocijacije koje strongSwan partner trenutačno drži. Usporedite vremenske oznake s trenutkom pojave upita; podudaranje potvrđuje mjerač vremena, a ne mrežu.
Šta prijaviti i šta ne isključivati
Ako ručna prijava uspijeva, a automatska ponovna upotreba dosljedno pada, recite to točno operateru. To imenuje komponentu: put ponovne upotrebe, ne akreditive. Uključite vrijeme kvara, korišteni račun i vrstu upita koju ste vidjeli.
Ne isključujte drugi faktor, ne preskačite provjeru certifikata i ne lijepljite akreditive u skriptu da povezivanje bude tiho. Svako od toga uklanja provjeru koju politika postoji da provede, i svako pretvara upit za prijavu u incident.
Zatražite umjesto toga podržani tok: klijenta koji može dovršiti izazov, rok tokena koji odgovara radnom danu ili odobreni neinteraktivni profil za stroj koji ne može pitati. Sve su to konfiguracijske odluke koje netko može odobriti, što zaobilazno rješenje nije.