Oppetid for en VPN-server: hva tallet ikke forteller deg

En offentlig nodeliste viser en server med oppetid målt i uker, så du velger den, og tilkoblingen feiler på første forsøk. Det er ikke falsk reklame; det er det gale spørsmålet stilt til et tall som måler noe annet. Oppetid angir vanligvis hvor lenge en prosess, container eller maskin har kjørt siden siste start, og det er en egenskap ved utgiverens infrastruktur, ikke ved veien din dit. Å behandle det som pålitelighet er den samme kategorifeilen som å behandle en bils kilometerteller som en veirapport.

Hva tallet måler

På en vert med en moderne tjenestebehandler er telleren forankret i en hendelse du faktisk kan lese: tidsstempelet da enheten gikk inn i aktiv tilstand, eller maskinens oppstartstid. Alt annet er aritmetikk på den forankringen, og definisjonen av forankringen varierer mellom utgivere. Én liste kan nullstilles ved en daemon-omstart, en annen ved omstart av maskinen, og en tredje ved en manuell nullstilling utført av en operatør som ville ha en ren graf.

systemctl show -p ActiveEnterTimestamp --value openvpn-server@server
uptime -s
systemctl is-active openvpn-server@server

De tre kommandoene svarer på tre forskjellige spørsmål, og en katalogliste som viser ett tall kan ikke fortelle deg hvilket av dem den brukte. Å sammenligne en rå teller fra to lister er derfor ikke en sammenligning i det hele tatt før du vet hva hver av dem nullstilles på.

En prosess kan kjøre mens veien er nede

Daemonen lytter. Sertifikatet er gyldig. Prosessen har levd i tjuetre dager. Ingenting av dette garanterer at pakker fra nettverket ditt når den, fordi nåbarhet er en egenskap ved hele veien: leverandørens oppstrømsforbindelse, peeringen mellom deres nett og ditt, trengselen på en delt transittlinje og brannmuren foran din egen tilkobling.

En server kan også være oppe og ubrukelig av en annen grunn. En node som har tatt imot langt flere klienter enn båndbredden støtter, vil vise lang oppetid og en forferdelig opplevelse, fordi telleren ikke måler kapasitet eller konkurranse. Dette er den vanligste måten en node med høy oppetid skuffer: ingenting er i stykker, alt er opptatt.

Det motsatte tilfellet er også verdt å huske. En node som ble startet på nytt for en time siden, kan være helt frisk nå, og sortering etter det største tallet utelater den stille. Oppetid er ikke en kvalitetsscore, og å behandle det som en slik velger etter alder i stedet for etter egnethet.

Ferskhet: rapporten er eldre enn forsøket ditt

Offentlige kataloger er sider generert fra periodiske kontroller, ikke levende telemetri. Oppetiden du leser ble beregnet ved forrige oppdatering, og tilkoblingen du forsøker skjer etterpå. I mellomtiden kan en leverandør miste en linje, bytte et sertifikat, flytte en adresse eller ta en node ut av tjeneste, og siden vil fortsette å vise den sist kjente gode tilstanden til neste gjennomkjøring.

Det gapet virker også den andre veien. En node som rapporteres som nede, kan ha kommet seg minutter etter at rapporten ble laget, så et umiddelbart nytt forsøk mot en annen node er ikke alltid det bedre valget.

Den praktiske regelen er at hvert rapporterte felt er en påstand om fortiden. Bruk det til å bygge en kortliste, og verifiser deretter med en måling du gjør selv i det øyeblikket du bryr deg om.

Hva du bør teste i stedet

Bestem hva du trenger fra noden, og test det. Trenger du nåbarhet, forteller et TCP-tilkoblingsforsøk til lyttporten deg mer på ett sekund enn noen teller. Trenger du en fungerende tunnel, forhandle fram en. Trenger du brukbar gjennomstrømning, overfør noe ekte og mål det, fordi tilkoblingstid og gjennomstrømning er forskjellige egenskaper, og et raskt håndtrykk sier ingenting om den andre.

nc -vz -w 5 vpn.example.net 1194
curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' https://vpn.example.net/
mtr -rwc 20 vpn.example.net

Gjenta testen i stedet for å stole på ett forsøk. Pålitelighet er en fordeling over tid og forhold, og én vellykket tilkobling er et utvalg på størrelse én. En håndfull forsøk i timene du faktisk bruker tilkoblingen, vil slå enhver publisert oppetid med god margin.

Å lese offentlige nodelister uten å bli villedet

Oppetid bærer heller ingen informasjon om det folk vanligvis vil ha fra en VPN: sertifikatets gyldighet, hvem som driver utgangen, hvilken DNS-policy som gjelder, og om operatøren lagrer tilkoblingslogger. Dette er separate påstander som krever separate bevis, og en lang teller er ikke bevis for noen av dem. En node kan være stabil i månedsvis og likevel være et dårlig valg for et personvernkrav.

Der en liste virkelig hjelper, er ved å lage en kortliste. Sorter etter det du vet du trenger, filtrer ut noder i regioner som er irrelevante for oppgaven, og test deretter de tre eller fire som er igjen. Ta vare på feilsteget fra hvert forsøk i stedet for et enkelt ja eller nei, fordi «TLS-håndtrykket mislyktes» og «tilkoblet, men ingen gjennomstrømning» fører til helt forskjellige konklusjoner.

Rammeverket for måling av veilens ytelse gjør det samme poenget i en strengere form: definer metrikken, forholdene og metoden før du samler inn tall. Brukt på en nodeliste betyr det at oppetidsfeltet er kontekst. Målingen du gjør selv, er beslutningen.