VPN-konexioen mugak: zuzeneko egoera edo gordetako historia
Hiru konexioen muga batek zuzeneko lekuen egoera behar du, ez nabigazio-historia: zer gorde behar duen mekanismoak, zer bota dezakeen eta nora doan gero egoera hori.
Hiru konexio aldi berean onarpen-erabakia dira, eta erantzuteko orain zein leku dauden okupatuta jakin behar da, joan den hilabetean zer gertatu zen jakin beharrean. Zerbitzu batek laugarren saio bat uka dezake erregistro aktiboen taula txiki bat erabiliz, eta inoiz ez du denbora-lerro bat eraikitzen. Hori mekanismoari buruzko adierazpena da, ez operadoreari buruzkoa, eta aldea garrantzitsua da pribatutasun-politika bat irakurtzean. Ondorengo ereduak erakusten du zer behar duen erabakiak eta zer bota dezakeen.
Mekanismoa: leku-taula bat, ez erregistro bat
Inplementaziorik sinpleenak harpidetza bat lotzen du hiru saio-erregistro aktibo arte. Onartutako saio bakoitzak leku bat hartzen du, eta lekua askatzen da zerbitzuak saioa amaitu dela erabakitzen duenean. Erregistroak nahikoa zehatza den identitatea behar du, konexio bat askatzeak beste konexio baten lekua aska ez dezan; horregatik saio-identifikatzaileak kontuaren izenak baino garrantzi handiagoa du.
Okupazioa eta historia datu-egitura desberdinak dira. Okupazioak orainaldiko bai edo ez galdera bati erantzuten dio, eta saioa amaitzen den unean bertan bota daiteke. Historia gertaeren fluxu gehigarri hutsa da, eta bizirik irauten du norbaitek gordetzea aukeratu duelako. Zerbitzu batek bat, biak edo bat ere ez izan ditzake.
Aldea ikusezina da kanpotik. Ikusgai dagoen konexio-muga bat bateragarria da memorian dagoen kontagailu txiki batekin, partekatutako datu-baseko taula batekin eta panel bat duen gertaera-artxibo oso batekin. Mugaren inguruan ezerk ez dizu esaten zein ari den martxan.
| 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 |
Zergatik behar duen zuzeneko ereduak koordinazioa oraindik
Galdutako konexio bat agian ez da berehala amaitutzat aitortzen. Ateak denbora-muga baten, keepalive hutsegite baten edo kontabilitate-geldialdi baten zain egoten da, eta horietako bat iritsi arte lekua okupatuta jarraitzen du. Tarte horretan berriz konektatzen den erabiltzaileak laugarren gailu batekin zerikusirik ez duen ukazioa ikusten du.
Berrabiarazitako zerbitzari batek bere egoera adiskidetu behar du, eta kontu bera zerbitzatzen duten atari batzuek erabaki komuna behar dute. Bestela kontu batek bere kuota gaindi dezake hainbat kokalekutara konektatuz. Egoera partekatuak edo berreskura daitekeenak hori konpontzen du, eta egoera partekatua diseinu-betekizuna da, ez zaintzaren froga.
Koordinazio horrek ez du nabigazio-historyrik behar. Paketeak birbidaltzen dituen atari batek ez du jakin behar saio batek zein webgune bisitatu zituen saioak zenbatzeko, eta bi datu-fluxu horiek erabat desberdinak diren osagaiek kudeatzen dituzte normalean.
Kontagailu bat memorian edukitzeak ez ditu lotutako gertaerak anonimo bihurtzen. Zerbitzua martxan dagoen bitartean, harpidetzari lotutako erregistro batek erakusten du kontu batek konexio aktiboak dituela, eta bai egoera horretarako sarbidea bai haren iraupena galdetzekoak dira.
Nora doan gero egoera
Pribatutasun-galdera ez da zerbitzariak zenbatu dezakeen. Galdetu zer gertatzen zaion amaitutako saio bati: erregistroa kentzen da, edo monitorizazio-serie bateko gertaera bihurtzen da? Gero galdetu beste zein osagaik ikusi zuten gertaera bera, autentifikazio-erregistroek, kontabilitate-erregistroek eta segurtasun-kopia bakoitzak gorde baitezakete betearazpen-bideak baztertutako kopia bat.
RADIUS kontabilitatea da adibiderik argiena. Start eta Stop bikote bat dago fakturazioa eta saioen kontrola babesteko, eta konexioaren erregistroa sortzen du, inork inoiz historikotzat kontsultatzen duen ala ez. Kontabilitatearen bidez mugak betearazten dituen zerbitzu batek, beraz, leku-taula bat baino gehiago gordetzen du eraikuntzaz.
Ezabatzeak ere forma du. Zuzeneko taulatik kendutako erregistro bat ordu bat lehenago egindako segurtasun-kopia batean iraun dezake, eta kopia horren atxikipen-epea bere politikaren adierazpena da. Biltegiratze nagusia soilik irakurtzeak erantzun osatugabea ematen du.
Egin galdera eremuen arabera
RFC 6973ren datu-minimizazio gidaritzak biltzen eta gordetzen diren datuak zerbitzatzen den helburuari lotzen dizkio. Hemen aplikatuta, galdera erabilgarria da zein eremu behar dituen benetan onarpen konkurrentearen zereginak, eta zein helburuk justifikatzen duen bakoitza gordetzea zeregin hori amaitutakoan.
Zerbitzu-adierazpen zehatz batek kuota betearazteko erabiltzen den zuzeneko konexio-egoera bereizten du amaitu ondoren atxikitako edozein erregistrotatik, eta promesaren esparruan dauden beste sistemak izendatzen ditu. Hiru konexio betearazten direla soilik dioen esaldi batek ez du ezartzen artxibo bat badenik ezta bat ere ez dagoenik.
Bizi-zikloa argia ez denean, erantzun gabeko atxikipen-galdera gisa erregistratu, ez epai gisa. Muga bat egotea ez da historia ezkutu baten froga, eta zuzeneko egoeraren azalpen sinesgarria ez da hornitzailearen auditoria.