Uptime van een VPN-server: wat dat getal je niet vertelt

Een openbare nodelijst toont een server met een uptime gemeten in weken, dus u kiest hem, en de verbinding mislukt bij de eerste poging. Dat is geen misleidende reclame; het is de verkeerde vraag aan een getal dat iets anders meet. Uptime geeft meestal aan hoe lang een proces, container of machine draait sinds de laatste start, en dat is een eigenschap van de infrastructuur van de uitgever, niet van uw pad ernaartoe. Het als betrouwbaarheid behandelen is dezelfde categoriefout als de kilometerteller van een auto als wegenrapport behandelen.

Wat het getal meet

Op een host met een moderne servicemanager is de teller verankerd aan een gebeurtenis die u echt kunt lezen: de tijdstempel waarop de unit de actieve toestand binnenging, of de opstarttijd van de machine. Al het andere is rekenwerk op dat anker, en de definitie van het anker verschilt per uitgever. De ene lijst kan resetten bij een daemon-herstart, een andere bij een herstart van de machine, en een derde bij een handmatige reset door een operator die een schone grafiek wilde.

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

Die drie commando’s beantwoorden drie verschillende vragen, en een directory die één getal toont kan u niet vertellen welke ervan is gebruikt. Een ruwe teller uit twee lijsten vergelijken is dus helemaal geen vergelijking tot u weet waarop elk ervan reset.

Een proces kan draaien terwijl het pad plat ligt

De daemon luistert. Het certificaat is geldig. Het proces leeft al drieëntwintig dagen. Niets daarvan garandeert dat pakketten uit uw netwerk hem bereiken, want bereikbaarheid is een eigenschap van het hele pad: de uplink van de provider, de peering tussen hun netwerk en het uwe, de congestie op een gedeelde transitlink en de firewall voor uw eigen verbinding.

Een server kan ook draaien en nutteloos zijn om een andere reden. Een node die veel meer clients heeft geaccepteerd dan zijn bandbreedte aankan, toont een lange uptime en een verschrikkelijke ervaring, omdat de teller geen capaciteit of concurrentie meet. Dit is de meest voorkomende manier waarop een node met een lange uptime teleurstelt: niets is kapot, alles is bezet.

Het omgekeerde geval is ook de moeite waard. Een node die een uur geleden opnieuw is gestart, kan nu volledig gezond zijn, en sorteren op het grootste getal sluit hem stilletjes uit. Uptime is geen kwaliteitsscore, en het als zodanig behandelen selecteert op leeftijd in plaats van op geschiktheid.

Actualiteit: het rapport is ouder dan uw poging

Openbare directory’s zijn pagina’s die uit periodieke controles worden gegenereerd, geen live telemetrie. De uptime die u leest, is bij de laatste verversing berekend, en de verbinding die u probeert, gebeurt daarna. Ondertussen kan een provider een link laten vallen, een certificaat wijzigen, een adres verplaatsen of een node uit dienst nemen, en de pagina blijft de laatst bekende goede toestand melden tot de volgende crawl.

Die kloof werkt ook de andere kant op. Een node die als down wordt gemeld, kan zich minuten na het genereren van het rapport hebben hersteld, dus een onmiddellijke nieuwe poging bij een andere node is niet altijd de betere keuze.

De praktische regel is dat elk gerapporteerd veld een bewering over het verleden is. Gebruik het om een shortlist te maken en verifieer daarna met een meting die u zelf doet op het moment dat u belangrijk vindt.

Wat u in plaats daarvan moet testen

Bepaal wat u van de node nodig hebt en test dat. Hebt u bereikbaarheid nodig, dan zegt een TCP-verbindingspoging naar de luisterpoort u in één seconde meer dan welke teller ook. Hebt u een werkende tunnel nodig, onderhandel er een. Hebt u bruikbare doorvoer nodig, draag dan iets echts over en meet het, want verbindingstijd en doorvoer zijn verschillende eigenschappen en een snelle handdruk zegt niets over de tweede.

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

Herhaal de test in plaats van op één poging te vertrouwen. Betrouwbaarheid is een verdeling over tijd en omstandigheden, en één geslaagde verbinding is een steekproef van grootte één. Een handvol pogingen in de uren dat u de verbinding echt gebruikt, verslaat elke gepubliceerde uptime met ruime marge.

Openbare nodelijsten lezen zonder misleid te worden

Uptime bevat ook geen informatie over de dingen die mensen gewoonlijk van een VPN willen: de geldigheid van het certificaat, wie de uitgang beheert, welk DNS-beleid geldt en of de operator verbindingsgegevens bewaart. Dat zijn afzonderlijke beweringen die afzonderlijk bewijs nodig hebben, en een lange teller is voor geen ervan bewijs. Een node kan maandenlang stabiel zijn en toch een slechte keuze voor een privacy-eis.

Waar een lijst echt helpt, is bij het maken van een shortlist. Sorteer op wat u weet dat u nodig hebt, filter nodes in regio’s die voor de taak irrelevant zijn eruit, en test dan de drie of vier die overblijven. Bewaar de faalfase van elke poging in plaats van een simpel ja of nee, want „de TLS-handdruk mislukte“ en „verbonden maar geen doorvoer“ leiden tot heel verschillende conclusies.

Het kader voor het meten van padprestaties maakt hetzelfde punt in een strengere vorm: definieer de metriek, de omstandigheden en de methode voordat u getallen verzamelt. Toegepast op een nodelijst betekent dat dat het uptime-veld context is. De meting die u zelf doet, is de beslissing.