VPN-serverens oppetid: hvad det tal ikke fortæller dig

En offentlig nodeliste viser en server med en oppetid målt i uger, så du vælger den, og forbindelsen fejler i første forsøg. Det er ikke falsk reklame; det er det forkerte spørgsmål stillet til et tal, der måler noget andet. Oppetid angiver normalt, hvor længe en proces, container eller maskine har kørt siden seneste start, og det er en egenskab ved udgiverens infrastruktur, ikke ved din vej til den. At behandle det som pålidelighed er den samme kategorifejl som at behandle en bils kilometertæller som en vejrapport.

Hvad tallet måler

På en vært med en moderne service manager er tælleren forankret i en begivenhed, du faktisk kan læse: tidsstemplet, hvor enheden gik i aktiv tilstand, eller maskinens opstartstid. Alt andet er aritmetik på den forankring, og definitionen af forankringen varierer mellem udgivere. Én liste kan nulstilles ved en daemon-genstart, en anden ved en genstart, og en tredje ved en manuel nulstilling udført af en operatør, der ville have en ren graf.

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

De tre kommandoer besvarer tre forskellige spørgsmål, og en katalogliste, der viser ét tal, kan ikke fortælle dig, hvilket af dem den brugte. At sammenligne en rå tæller fra to lister er derfor slet ikke nogen sammenligning, før du ved, hvad hver af dem nulstilles på.

En proces kan køre, mens vejen er nede

Daemonen lytter. Certifikatet er gyldigt. Processen har været i live i treogtyve dage. Intet af det garanterer, at pakker fra dit netværk når den, fordi nåbarhed er en egenskab ved hele vejen: udbyderens uplink, peeringen mellem deres netværk og dit, trængslen på et delt transitlink og firewallen foran din egen forbindelse.

En server kan også være oppe og ubrugelig af en anden grund. En node, der har accepteret langt flere klienter, end dens båndbredde understøtter, vil vise en lang oppetid og en frygtelig oplevelse, fordi tælleren ikke måler kapacitet eller konkurrence. Det er den mest almindelige måde, en node med lang oppetid skuffer: intet er i stykker, alt er travlt.

Det omvendte tilfælde er også værd at huske. En node, der blev genstartet for en time siden, kan være helt sund nu, og sortering efter det største tal udelukker den stille. Oppetid er ikke en kvalitetsscore, og at behandle det som en sådan vælger efter alder i stedet for efter egnethed.

Friskhed: rapporten er ældre end dit forsøg

Offentlige kataloger er sider genereret ud fra periodiske kontroller, ikke live-telemetri. Den oppetid, du læser, blev beregnet ved den seneste opdatering, og den forbindelse, du forsøger, sker efter den. Imellem kan en udbyder miste et link, skifte et certifikat, flytte en adresse eller tage en node ud af drift, og siden vil fortsætte med at vise den seneste kendte gode tilstand indtil næste gennemløb.

Det hul virker også den anden vej. En node, der rapporteres som nede, kan være kommet sig minutter efter, rapporten blev genereret, så et øjeblikkeligt nyt forsøg mod en anden node er ikke altid det bedre valg.

Den praktiske regel er, at hvert rapporteret felt er en påstand om fortiden. Brug det til at bygge en kortliste, og verificér derefter med en måling, du selv foretager i det øjeblik, du har brug for det.

Hvad du i stedet bør teste

Beslut, hvad du har brug for fra noden, og test det. Har du brug for nåbarhed, fortæller et TCP-forbindelsesforsøg til lytteporten dig mere på et sekund end nogen tæller. Har du brug for en fungerende tunnel, forhandl en. Har du brug for brugbar gennemstrømning, overfør noget rigtigt og mål det, fordi forbindelsestid og gennemstrømning er forskellige egenskaber, og et hurtigt håndtryk siger intet om den anden.

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

Gentag testen i stedet for at stole på et enkelt forsøg. Pålidelighed er en fordeling over tid og forhold, og én vellykket forbindelse er en stikprøve på størrelse én. En håndfuld forsøg i de timer, hvor du faktisk bruger forbindelsen, vil slå enhver offentliggjort oppetid med bred margin.

At læse offentlige nodelister uden at blive vildledt

Oppetid bærer heller ingen information om de ting, folk normalt vil have fra en VPN: certifikatets gyldighed, hvem der driver udgangen, hvilken DNS-politik der gælder, og om operatøren gemmer forbindelsesposter. Det er separate påstande, der kræver separate beviser, og en lang tæller er ikke bevis for nogen af dem. En node kan være stabil i månedsvis og stadig være et dårligt valg for et privatlivskrav.

Hvor en liste virkelig hjælper, er ved at lave en kortliste. Sortér efter det, du ved, du har brug for, filtrér noder i regioner, der er irrelevante for opgaven, og test derefter de tre eller fire, der er tilbage. Gem fejlstadiet fra hvert forsøg i stedet for et enkelt ja eller nej, fordi „TLS-håndtrykket mislykkedes“ og „forbundet, men ingen gennemstrømning“ fører til helt forskellige konklusioner.

Rammen til måling af vejens ydeevne fremfører den samme pointe i en mere stringent form: definér metrikken, betingelserne og metoden, før du indsamler tal. Anvendt på en nodeliste betyder det, at oppetidsfeltet er kontekst. Den måling, du selv foretager, er beslutningen.