Kāpēc VPN atkārtota savienojuma laikā atkal prasa akreditācijas datus
Saglabātā parole un atkārtoti lietojamais marķieris beidzas pēc dažādiem grafikiem. Pirms kaut ko mainīt klientā, izlasiet, kādu materiālu pieprasīja atkārtotais savienojums.
Tunelis, kas strādāja stundām ilgi, pieprasa paroli tajā mirklī, kad klēpjdators pamostas, un konfigurācijā nekas nav mainījies. Mainījies ir tās akreditācijas datu kopas stāvoklis, kuru atkārtotais savienojums mēģināja izmantot atkārtoti. To nosaka trīs materiāla veidi, un tikai viens no tiem pārdzīvo patvaļīgu pārtraukumu.
Izlasiet, kuru klients pieprasīja, jo visi trīs beidzas pēc dažādiem pulksteņiem un neizdodas ar dažādiem ziņojumiem.
Trīs atkārtoti lietojama materiāla veidi
Kešatmiņā saglabātā parole ir noslēpums, ko tur klients, un tā paliek derīga, līdz konts to nomaina. Sesijas marķieri izsniedz serveris pēc veiksmīgas pieteikšanās, tam ir savs darbības laiks, un to jebkurā brīdī var atsaukt. TLS sesijas biļete vai IKE drošības asociācija ir protokola stāvoklis, lēti atsākt un pilnīgi neatkarīgs no jūsu paroles. Katru izsniedz cita komponente, un katra beidzas ar saviem noteikumiem.
Pirmais pārdzīvo pārstartēšanu, otrais parasti pārdzīvo miegu, bet trešais var nepārdzīvot tīkla maiņu vispār. Tos sajaucot, tiek iegūts nepareizs risinājums, piemēram, atiestatīta parole, kas nekad netika noraidīta.
Pats uzvedne ir diagnostika. Pārlūka logs vai otrā faktora kods nozīmē, ka serveris pieprasīja interaktīvu autentifikāciju, savukārt klusa neizdošanās bez uzvednes nozīmē, ka klients nekad netika tik tālu, lai tam jautātu.
| 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 |
Atslēgu atjaunošana nav atkārtota autentifikācija
Atslēgu atjaunošana aizstāj atslēgas, saglabājot autentificēto identitāti, tāpēc veselā tunelī tā laiku pa laikam notiek klusi. Atkārtota autentifikācija atkārto pašu identitātes pārbaudi, un tas ir notikums, kam vajadzīgs jūsu atbalsts. IKEv2 skaidri nošķir abus, un partneris var pieprasīt pilnīgu atkārtotu autentifikāciju noteiktā intervālā neatkarīgi no tā, cik atslēgu atjaunošanu starplaikā notika. No ārpuses abi notikumi izskatās vienādi, līdz izlasāt, kuru nosauc žurnāls.
OpenVPN rīkojas tāpat savā vārdnīcā: atkārtotas pārrunas intervāls atsvaidzina datu kanālu, un autentifikācijas marķieri var atgriezt klientam, lai nākamajā savienojumā izvairītos no pilnīgas pieteikšanās. Šim marķierim ir darbības laiks, un serveris izlemj, vai to pieņemt vēlreiz.
Tāpēc atkārtots savienojums pēc astoņām stundām var neizdoties tur, kur atkārtots savienojums pēc astoņām minūtēm izdevās, bez jebkādām konfigurācijas izmaiņām abās pusēs. Tas ir viss izskaidrojums uzvednei, kas parādās tikai pēc pusdienām.
Kad klients nevar pabeigt jauno izaicinājumu
Politika, kas pieprasa pārlūka soli, neizdosies klientā, kuram nav iespējas to parādīt. Serveri bez saskarnes, starta skripti un vecie profili, kas veidoti tikai paroles autentifikācijai, visi atduras pret šo sienu, un neizdošanās bieži parādās kā vispārējs taimauts, nevis autentifikācijas kļūda.
Ierīces un tīkla pārejas var arī iekrist politikas novērtējuma logā, tāpēc pāreja no Wi-Fi uz piekļuves punktu sakrīt ar pārbaudi, kas notiktu jebkurā gadījumā. Šī sakritība liek tīklam izskatīties vainīgam, ja cēlonis ir taimeris.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
Pirmā rinda rāda atkārtotas pārrunas un autentifikācijas notikumus paša klienta žurnālā, bet otrā rāda drošības asociācijas, kas strongSwan partnerim pašlaik ir. Salīdziniet laika zīmes ar brīdi, kad parādījās uzvedne; sakritība apstiprina taimeri, nevis tīklu.
Ko ziņot un ko neizslēgt
Ja manuāla pieteikšanās izdodas, bet automātiska atkārtota izmantošana konsekventi neizdodas, sakiet operatoram tieši to. Tas nosauc komponenti: atkārtotas izmantošanas ceļu, nevis akreditācijas datus. Iekļaujiet neizdošanās laiku, izmantoto kontu un redzētās uzvednes veidu.
Neizslēdziet otro faktoru, neizlaidiet sertifikāta validāciju un neielīmējiet akreditācijas datus skriptā, lai savienojums būtu kluss. Katrs no tiem noņem pārbaudi, kurai politika pastāv, un katrs pārvērš pieteikšanās uzvedni incidentā.
Tā vietā pieprasiet atbalstīto plūsmu: klientu, kas spēj pabeigt izaicinājumu, marķiera darbības laiku, kas atbilst darba dienai, vai apstiprinātu neinteraktīvu profilu mašīnai, kas nevar pajautāt. Tie visi ir konfigurācijas lēmumi, ko kāds var apstiprināt, bet apiet to nevar.