Mikä lasketaan onnistuneeksi VPN-kirjautumiseksi raportissa?
Todennus, alustettu tunneli ja toimiva pyyntö ovat kolme eri lopputulosta. Nimeä se, jota raporttisi mittaa, ennen kuin lasket mitään.
Kolme raporttia samasta VPN:stä voivat olla eri mieltä ilman, että yksikään niistä on väärässä, koska jokainen ymmärtää onnistuneen kirjautumisen eri tavalla. Yksi laskee yhteydet, jotka pääsivät palvelimelle, toinen laskee identiteetit, jotka todennusvaihe hyväksyi, ja kolmas laskee istunnot, jotka saivat alustuksen valmiiksi. Yhden valitseminen ennen tietojen keräämistä on ero mittarin ja väitteen välillä.
Hyödyllinen kysymys ei ole, mikä määritelmä on yleisesti oikein, vaan mihin tulokseen lukija aikoo reagoida.
Kolme eri tapahtumaa kantaa samaa nimeä
Palvelin hyväksyy kuljetusyhteyden heti, kun kättely on valmis, ja se tapahtuu ennen kuin yhtään tunnistetietoa esitetään. Tämä tapahtuma kertoo, että portti on tavoitettavissa ja verkkopolku toimii, eikä se kerro mitään siitä, kuka yhdisti. Todennus on myöhempi vaihe, joka voi epäonnistua, ja se voi myös onnistua identiteetille, jolle ei koskaan sallita pääsyä verkkoon.
Alustus tulee todennuksen jälkeen, ja alustuksen valmiiksi saanut tunneli voi seisoa toimettomana loppupäivän. Sovelluksen pyyntö on ainoa tapahtuma, joka osoittaa käyttäjän päässeen johonkin haluamaansa. Nämä vaiheet ovat sisäkkäisiä, joten laajimman laskenta ylittää aina kapeimman laskennan. Mikään tapahtumaketjussa ei todista käyttäjän olleen tuottelias, vain sen, että jokainen portti avautui vuorollaan.
Tuotedokumentaatio nimeää tilat yleensä selvästi. OpenVPN:n hallintaliittymän muistiinpanot erottavat TCP-yhteyden, todennustuloksen ja valmiin alustuksen, mikä on täsmälleen se ero, jonka raportti tarvitsee. Tilaksi merkitty connected ei todista, että tiedostojako tai tietokantatoiminto onnistui myöhemmin.
Laske istunnot, identiteetit tai pyynnöt
Päätä yksikkö ennen kuin päätät luvun. Istuntojen laskenta vastaa siihen, kuinka monta kertaa palvelua käytettiin, identiteettien laskenta siihen, kuinka monta eri tiliä ilmestyi, ja pyyntöjen laskenta siihen, kuinka paljon työtä tehtiin. Toimittajat laskevat nämä myös eri tavoin, eikä käyttäjissä mitattua oikeutta voi verrata istunnoissa mitattuun kuvaajaan. Väärän valitseminen on syy siihen, miksi kapasiteettisuunnitelma mitoitetaan väärälle määrälle.
Uudelleenyhdistämiset ovat paikka, jossa istuntolaskennat hiljaa paisuvat. Asiakasohjelma, joka katkeaa muutaman minuutin välein ja yhdistää uudelleen, tuottaa yhdelle henkilölle kymmeniä istuntotietueita, joten raportti, joka laskee istunnot henkilöinä, yliarvioi käytön juuri niissä olosuhteissa, joissa luotettavuus on huonoin. Kirjoita sääntö muistiin: uusi istunto uudelleenyhdistämisen jälkeen lasketaan erikseen, tai se jatkaa edellistä määritellyn ikkunan sisällä.
Osoitteet ovat heikoin käytettävissä oleva identiteetti. Tunneliosoite voidaan antaa toiselle käyttäjälle minuutteja myöhemmin, ja kaksi käyttäjää voi jakaa yhden osoitteen käännöksen kautta. Liitä tilin tunniste todennustapahtumasta sen sijaan, että päättelet henkilön lokin osoitteesta.
Testaa määritelmää yhdellä todellisella päivällä
Ota yhden päivän lokit ja laske sama liikenne kolmella tavalla. Jos kolme lukua ovat lähellä toisiaan, määritelmällä ei ehkä ole suurta merkitystä tarkoituksellesi; jos ne eroavat suurella kertoimella, raportin on sanottava, mitä se käyttää.
journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Initialization Sequence Completed"
journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Peer Connection Initiated"
awk '/VERIFY OK/ {print $NF}' /var/log/openvpn-server.log | sort -u | wc -l
Aja sama poiminta päivänä, jolla on tunnettu katkos, ja vertaa muotoa kokonaissumman sijaan. Päivänä, jolloin ylälinkki värisi, yhteyksien tapahtumissa pitäisi näkyä piikki ja eri tileissä maltillinen kasvu, ja jos ei näy, laskuri mittaa todennäköisesti jotain muuta kuin raportti väittää.
Säilytä kysely itse tuloksen vieressä. Kuka tahansa voi toistaa dokumentoidun suodattimen, eikä luku ilman suodatintaan ole auditoitavissa.
Kerro, mitä tapahtuma todistaa
Epäonnistunut yritys ansaitsee oman luokkansa sen sijaan, että se taitetaan kummallekaan puolelle. Epäonnistumisiin kuuluvat väärin kirjoitetut salasanat, vanhentuneen profiilin asiakasohjelmat ja tahallinen luotaus, ja kaikilla kolmella on erilainen vastaus. Epäonnistuminen ei ole todiste onnistuneesta tunkeutumisesta eikä myöskään todiste vaarattomuudesta.
Kirjoita johtopäätös sillä vahvuudella, jota tapahtuma tukee: tämä tili todennettiin tähän palveluun tässä ikkunassa, tästä lähteestä, ja istunto pääsi alustukseen. Kaikki siitä, mitä käyttäjä teki sen jälkeen, vaatii merkinnän sovelluksen puolella eikä lisää tunnelitietoja.
Kun raportti menee jollekulle, joka tekee lisensointia, kapasiteettia tai turvallisuutta koskevan päätöksen, laita määritelmä ensimmäiselle riville eikä alaviitteeseen. Määritelmä on löydös, ja luku on mielekäs vain sen sisällä.