Limite de conexiuni VPN: stare în timp real sau istoric păstrat
O limită de trei conexiuni are nevoie de starea în timp real a sloturilor, nu de un istoric de navigare: ce trebuie să stocheze mecanismul, ce poate arunca și unde ajunge această stare mai departe.
Trei conexiuni simultane sunt o decizie de admitere, iar pentru a răspunde la ea este nevoie să știm ce sloturi sunt ocupate chiar acum, nu ce s-a întâmplat luna trecută. Un serviciu poate refuza o a patra sesiune pe baza unui tabel mic de înregistrări active și nu construiește niciodată o cronologie. Aceasta este o afirmație despre mecanism, nu despre operator, iar diferența contează când citești o politică de confidențialitate. Modelul de mai jos arată de ce are nevoie decizia și ce poate arunca.
Mecanismul: un tabel de sloturi, nu un jurnal
Cea mai simplă implementare asociază un abonament cu până la trei înregistrări active de sesiune. Fiecare sesiune admisă ocupă un slot, iar slotul este eliberat când serviciul decide că acea sesiune s-a încheiat. Înregistrarea are nevoie de o identitate suficient de specifică încât eliberarea unei conexiuni să nu elibereze slotul altei conexiuni; de aceea identificatorul sesiunii contează mai mult decât numele contului.
Ocuparea și istoricul sunt structuri de date diferite. Ocuparea răspunde la o întrebare da sau nu despre prezent și poate fi aruncată în momentul în care sesiunea se încheie. Un istoric este un flux de evenimente doar cu adăugare, și supraviețuiește pentru că cineva a ales să îl păstreze. Un serviciu poate avea unul, ambele sau niciunul.
Distincția este invizibilă din exterior. O limită de conexiuni vizibilă este compatibilă cu un contor minuscul în memorie, cu un tabel de bază de date partajat și cu o arhivă completă de evenimente cu panou de control. Nimic din limită nu îți spune care dintre ele rulează.
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
De ce modelul în timp real are totuși nevoie de coordonare
O conexiune pierdută poate să nu fie recunoscută imediat ca încheiată. Gateway-ul așteaptă un timeout, o defecțiune keepalive sau o oprire de contabilizare, iar până când sosește unul dintre ele slotul rămâne ocupat. Un utilizator care se reconectează în acel interval vede un refuz care nu are nimic de-a face cu un al patrulea dispozitiv.
Un server repornit trebuie să își reconcilieze starea, iar mai multe gateway-uri care deservesc același cont au nevoie de o decizie comună. Altfel un cont poate depăși cota conectându-se la locații diferite. Starea partajată sau recuperabilă rezolvă asta, iar starea partajată este o cerință de proiectare, nu o dovadă de supraveghere.
Nimic din acea coordonare nu necesită istorice de navigare. Un gateway care redirecționează pachete nu trebuie să știe ce site-uri a vizitat o sesiune pentru a număra sesiuni, iar cele două fluxuri de date sunt de obicei gestionate de componente complet diferite.
Păstrarea unui contor în memorie nu face nici faptele asociate anonime. Cât timp serviciul rulează, o înregistrare legată de abonament dezvăluie că un cont are conexiuni active, iar atât accesul la acea stare, cât și durata ei de viață merită întrebate.
Unde ajunge această stare mai departe
Întrebarea de confidențialitate nu este dacă serverul poate număra. Întreabă ce se întâmplă cu o sesiune încheiată: înregistrarea este eliminată sau devine un eveniment într-o serie de monitorizare? Apoi întreabă ce alte componente au văzut același eveniment, deoarece jurnalele de autentificare, înregistrările contabile și copiile de siguranță pot păstra fiecare o copie pe care calea de aplicare a aruncat-o.
Contabilizarea RADIUS este exemplul cel mai clar. O pereche Start și Stop există pentru a sprijini facturarea și controlul sesiunilor, și creează o înregistrare a conexiunii indiferent dacă cineva o interoghează vreodată ca istoric. Un serviciu care aplică limite prin contabilizare păstrează așadar prin construcție mai mult decât un tabel de sloturi.
Ștergerea are și ea o formă. O înregistrare eliminată din tabelul în timp real poate persista într-o copie de siguranță făcută cu o oră înainte, iar perioada de păstrare a acelei copii este o declarație de politică proprie. Citind doar depozitul primar obții un răspuns incomplet.
Pune întrebarea în termeni de câmpuri
Ghidul de minimizare a datelor din RFC 6973 leagă datele colectate și stocate de scopul servit. Aplicat aici, întrebarea utilă este ce câmpuri are nevoie de fapt sarcina de admitere simultană și ce scop justifică păstrarea fiecăruia după ce acea sarcină se încheie.
O declarație de serviciu precisă separă starea conexiunii în timp real folosită pentru aplicarea cotei de orice înregistrare păstrată după încetare și numește celelalte sisteme din sfera promisiunii. O propoziție care spune doar că sunt aplicate trei conexiuni nu stabilește nici că există o arhivă, nici că nu există.
Când ciclul de viață nu este clar, notează-l ca întrebare de păstrare fără răspuns, nu ca verdict. Prezența unei limite nu este dovadă a unui istoric ascuns, iar o explicație plauzibilă a stării în timp real nu este un audit al furnizorului.