VPN-yhteyksien rajat: reaaliaikainen tila vai säilytetty historia
Kolmen yhteyden raja tarvitsee reaaliaikaisen paikkatilan, ei selaushistoriaa: mitä mekanismin on tallennettava, mitä se voi hylätä ja mihin tila menee seuraavaksi.
Kolme samanaikaista yhteyttä on hyväksymispäätös, ja sen vastaaminen edellyttää tietoa siitä, mitkä paikat ovat juuri nyt varattuina, ei siitä, mitä viime kuussa tapahtui. Palvelu voi hylätä neljännen istunnon pienen aktiivisten tietueiden taulun perusteella eikä koskaan rakenna aikajanaa. Se on väite mekanismista, ei operaattorista, ja erolla on merkitystä, kun luet tietosuojakäytäntöä. Alla oleva malli näyttää, mitä päätös tarvitsee ja mitä se voi hylätä.
Mekanismi: paikkataulu, ei loki
Yksinkertaisin toteutus liittää tilauksen enintään kolmeen aktiiviseen istuntotietueeseen. Jokainen hyväksytty istunto ottaa yhden paikan, ja paikka vapautetaan, kun palvelu päättää, että istunto on päättynyt. Tietue tarvitsee identiteetin, joka on riittävän yksilöllinen, jotta yhden yhteyden vapauttaminen ei vapauta toisen yhteyden paikkaa; siksi istuntotunniste on tärkeämpi kuin tilin nimi.
Varaus ja historia ovat eri tietorakenteita. Varaus vastaa kyllä tai ei -kysymykseen nykyhetkestä, ja se voidaan hylätä sinä hetkenä, kun istunto päättyy. Historia on vain lisättävä tapahtumavirta, ja se säilyy, koska joku päätti pitää sen. Palvelulla voi olla jompikumpi, molemmat tai ei kumpikaan.
Ero on ulkopuolelta näkymätön. Näkyvä yhteysraja sopii yhteen pikkuruisen muistissa olevan laskurin, jaetun tietokantataulun ja täydellisen tapahtuma-arkiston kanssa, jossa on kojelauta. Mikään rajassa ei kerro, mikä niistä on käynnissä.
| 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 |
Miksi reaaliaikainen malli tarvitsee silti koordinointia
Kadonnutta yhteyttä ei välttämättä tunnisteta heti päättyneeksi. Yhdyskäytävä odottaa aikakatkaisua, keepalive-virhettä tai kirjanpidon pysäytystä, ja kunnes jokin niistä saapuu, paikka pysyy varattuna. Käyttäjä, joka yhdistää uudelleen tänä aikana, näkee hylkäyksen, jolla ei ole mitään tekemistä neljännen laitteen kanssa.
Uudelleen käynnistetyn palvelimen on sovitettava tilansa, ja useiden samaa tiliä palvelevien yhdyskäytävien on tehtävä yhteinen päätös. Muuten tili voi ylittää kiintiönsä yhdistämällä eri sijainteihin. Jaettu tai palautettava tila ratkaisee sen, ja jaettu tila on suunnitteluvaatimus eikä todiste valvonnasta.
Mikään tästä koordinoinnista ei vaadi selaushistoriaa. Paketteja välittävä yhdyskäytävä ei tarvitse tietää, millä sivustoilla istunto vieraili, jotta se voi laskea istuntoja, ja näitä kahta tietovirtaa käsittelevät yleensä täysin eri komponentit.
Laskurin pitäminen muistissa ei tee liittyvistä tosiasioista anonyymejä. Palvelun käydessä tilaukseen liittyvä tietue paljastaa, että tilillä on aktiivisia yhteyksiä, ja sekä pääsy tuohon tilaan että sen elinikä ovat molemmat kysymisen arvoisia.
Mihin tila menee jälkeenpäin
Tietosuojakysymys ei ole se, voiko palvelin laskea. Kysy, mitä päättyneelle istunnolle tapahtuu: poistetaanko tietue vai tuleeko siitä tapahtuma seurantasarjaan? Kysy sitten, mitkä muut komponentit näkivät saman tapahtuman, sillä todennuslokit, kirjanpitotietueet ja varmuuskopiot voivat kukin pitää kopion, jonka valvontapolku hylkäsi.
RADIUS-kirjanpito on selkein esimerkki. Start- ja Stop-pari on olemassa laskutuksen ja istunnonhallinnan tukemiseksi, ja se luo yhteydestä tietueen riippumatta siitä, kysyykö sitä koskaan kukaan historiana. Palvelu, joka valvoo rajoja kirjanpidon kautta, säilyttää siis rakenteellisesti enemmän kuin paikkataulun.
Myös poistamisella on muoto. Reaaliaikataulusta poistettu tietue voi säilyä tuntia aiemmin otetussa varmuuskopiossa, ja tuon varmuuskopion säilytysaika on oma käytäntölausumansa. Vain ensisijaisen tallennuksen lukeminen antaa puutteellisen vastauksen.
Kysy kysymys kentittäin
RFC 6973:n tietojen minimoinnin ohjeistus sitoo kerätyt ja tallennetut tiedot siihen tarkoitukseen, jota ne palvelevat. Tähän sovellettuna hyödyllinen kysymys on, mitä kenttiä samanaikaisen hyväksynnän tehtävä todella tarvitsee ja mikä tarkoitus oikeuttaa kunkin säilyttämisen sen tehtävän päätyttyä.
Täsmällinen palvelukuvaus erottaa kiintiön valvontaan käytetyn reaaliaikaisen yhteystilan kaikista lopettamisen jälkeen säilytettävistä tietueista ja nimeää muut järjestelmät lupauksen piirissä. Lause, joka sanoo vain, että kolmea yhteyttä valvotaan, ei osoita, että arkisto on olemassa, eikä sitä, ettei sitä ole.
Kun elinkaari on epäselvä, kirjaa se vastaamattomana säilytyskysymyksenä eikä tuomiona. Rajan olemassaolo ei ole todiste piilotetusta historiasta, eikä uskottava selitys reaaliaikaisesta tilasta ole tarjoajan auditointi.