Prima sesiune câștigă: limitarea autentificărilor OpenVPN înainte de evacuare
Respingerea unei autentificări ulterioare nu este același lucru cu înlocuirea celei vechi. Decizia trebuie luată înainte de evacuarea cu același nume, iar verificarea slotului trebuie să fie atomică.
O politică ce permite o sesiune per cont pare rezolvată până când sosește a doua autentificare. Sunt posibile două rezultate: noul venit înlocuiește sesiunea aflată în desfășurare, sau sesiunea aflată în desfășurare păstrează slotul, iar noul venit este respins. Doar al doilea este o politică în care prima sesiune câștigă. Opțiunea de client la care apelează majoritatea activează concurența și, prin urmare, nu produce acest rezultat.
Două contracte se ascund în spatele unei singure setări
Cu concurența dezactivată, o a doua conexiune care prezintă același nume de certificat poate înlătura sesiunea deja activă. Activarea concurenței permite mai multe sesiuni simultan, ceea ce este opusul unei limite. Niciuna dintre stări nu este o politică de respingere, așa că decizia trebuie luată în altă parte.
Scrieți contractul înainte de a implementa orice: cine este respins, ce dovadă identifică sesiunea activă și ce se întâmplă când o sesiune moare fără o deconectare curată. O politică pe care nimeni nu a formulat-o astfel nu poate fi testată mai târziu.
Evacuarea are loc înaintea cârligului de conectare
În calea de cod a serverului 2.6, pregătirea timpurie a unui client nou elimină instanțele existente cu același nume atunci când concurența este dezactivată. Acea eliminare are loc înainte de rularea lanțului de gestionare a conectării. Un script care observă duplicatul și returnează eroare respinge astfel noul venit după ce sesiunea activă a fost deja eliminată - exact rezultatul pe care politica trebuia să îl prevină. Ordinea apelurilor inverse din implementarea upstream este singurul răspuns de încredere pentru build-ul dumneavoastră.
| Stage | Who can still refuse | Effect on the incumbent |
|---|---|---|
| Certificate check | Server trust configuration | None |
| Authentication decision | The authentication controller | None, because establishment has not run |
| Connect handler | A profile script | Already evicted in the same-name case |
| Post-establishment | Status tooling, monitoring | Both sessions already exist or one is gone |
Interogarea fișierului de stare nu este nici ea o poartă. Două încercări care sosesc simultan pot vedea amândouă un slot gol înainte ca vreuna să îl confirme, și amândouă continuă.
Mutați decizia în autentificare
Interfața de administrare poate prelua decizia de autentificare după verificarea certificatului. În această configurație controlerul nu este un monitor: primește fiecare instanță de client care se conectează și răspunde dacă acea instanță poate continua. Deoarece răspunsul sosește înainte de stabilire, o respingere lasă sesiunea activă neatinsă. Același canal raportează deconectările, și astfel controlerul află că un slot a fost eliberat în mod legitim.
Fiecare instanță nouă trebuie să treacă de această poartă, inclusiv reconectările și orice cale care se reautentifică fără solicitare. O poartă la care unele instanțe nu ajung niciodată nu protejează nimic, iar omisiunea rămâne invizibilă până când cineva încearcă ocolirea.
Tokenurile pot trece pe lângă poartă
După ce un token este emis, serverul îl poate valida intern și poate sări peste autentificarea externă pentru acea conexiune. Apelul de administrare nu are loc niciodată, așa că o verificare a slotului implementată doar acolo nu vede niciodată noua instanță. Acest comportament este o comoditate pentru utilizatori și o gaură într-o politică de concurență. Faceți ca conexiunile autentificate cu token să treacă printr-o verificare autoritativă echivalentă sau dezactivați calea tokenului atunci când politica cere o decizie pentru fiecare conexiune.
Nu compensați acceptând fiecare token fără condiții. Un token expirat sau invalid trebuie totuși să eșueze, și trebuie să eșueze prin același punct de decizie ca tot restul.
Legați rezervarea de o instanță, nu de o adresă
O adresă este o identitate slabă: o reconectare de pe același laptop poate veni de la o altă adresă, iar o acreditare copiată poate veni de la aceeași. Legați rezervarea de instanța de client pe care o atribuie serverul, astfel încât o reautentificare a instanței deja admise să fie recunoscută ca proprietar. Un identificator nou de instanță trebuie să obțină propriul slot prin decizia primul câștigă, chiar și atunci când prezintă același token.
Eliberați doar rezervarea care aparține încercării eșuate. Un eveniment de deconectare întârziat dintr-o încercare mai veche nu trebuie să șteargă slotul unui proprietar mai nou, de aceea eliberarea numește instanța, nu contul. După repornirea controlerului, reconciliați sesiunile active înainte de a admite pe cineva și aplicați aceeași regulă pe fiecare gateway care deservește contul.
Decideți separat cum este recuperat un slot cu adevărat învechit. Administratorul are nevoie de o modalitate documentată de a-l curăța, iar acea cale nu ar trebui să fie accesibilă unui utilizator care doar face clic pe reconectare.
Testați perechile care contează: două autentificări aproape simultane, o reconectare după o închidere curată, o reautentificare a sesiunii active, un nou venit respins și o repornire a controlerului. În fiecare caz sesiunea activă trebuie să rămână utilizabilă, iar noul venit trebuie respins fără daune colaterale pentru alte conturi.