Upptid för en VPN-server: vad siffran inte berättar
Räknaren mäter tid sedan något startade, inte nåbarhet från ditt nätverk. Kontrollera definitionen och rapporttiden och testa sedan det du behöver.
En offentlig nodlista visar en server med upptid mätt i veckor, så du väljer den, och anslutningen misslyckas vid första försöket. Det är inte falsk reklam; det är fel fråga ställd till en siffra som mäter något annat. Upptid anger vanligtvis hur länge en process, container eller maskin har kört sedan senaste starten, och det är en egenskap hos utgivarens infrastruktur, inte hos din väg dit. Att behandla det som tillförlitlighet är samma kategorifel som att behandla en bils vägmätare som en vägrapport.
Vad siffran mäter
På en värd med en modern tjänstehanterare är räknaren förankrad i en händelse du faktiskt kan läsa: tidsstämpeln då enheten gick in i aktivt tillstånd, eller maskinens starttid. Allt annat är aritmetik på den förankringen, och definitionen av förankringen varierar mellan utgivare. En lista kan nollställas vid en daemon-omstart, en annan vid omstart av maskinen, och en tredje vid en manuell nollställning som gjordes 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 kommandona svarar på tre olika frågor, och en kataloglista som visar ett enda tal kan inte berätta vilket av dem den använde. Att jämföra en rå räknare från två listor är därför inte en jämförelse alls förrän du vet vad var och en nollställs på.
En process kan köra medan vägen är nere
Daemonen lyssnar. Certifikatet är giltigt. Processen har levt i tjugotre dagar. Inget av detta garanterar att paket från ditt nätverk når den, eftersom nåbarhet är en egenskap hos hela vägen: leverantörens uppströmslänk, peeringen mellan deras nät och ditt, trängseln på en delad transitlänk och brandväggen framför din egen anslutning.
En server kan också vara uppe och oanvändbar av en annan anledning. En nod som har tagit emot långt fler klienter än dess bandbredd klarar visar en lång upptid och en fruktansvärd upplevelse, eftersom räknaren inte mäter kapacitet eller konkurrens. Det är det vanligaste sättet en nod med hög upptid gör besvikna: inget är trasigt, allt är upptaget.
Det omvända fallet är också värt att komma ihåg. En nod som startades om för en timme sedan kan vara helt frisk nu, och sortering efter det största talet utesluter den tyst. Upptid är inte en kvalitetspoäng, och att behandla det som en sådan väljer efter ålder i stället för efter lämplighet.
Färskhet: rapporten är äldre än ditt försök
Offentliga kataloger är sidor som genereras från periodiska kontroller, inte levande telemetri. Upptiden du läser beräknades vid den senaste uppdateringen, och anslutningen du försöker göra sker efteråt. Under tiden kan en leverantör tappa en länk, byta ett certifikat, flytta en adress eller ta en nod ur drift, och sidan fortsätter att visa det senast kända goda tillståndet till nästa genomsökning.
Det gapet verkar också åt andra hållet. En nod som rapporteras som nere kan ha återhämtat sig minuter efter att rapporten skapades, så ett omedelbart nytt försök mot en annan nod är inte alltid det bättre valet.
Den praktiska regeln är att varje rapporterat fält är ett påstående om det förflutna. Använd det för att bygga en kortlista och verifiera sedan med en mätning du gör själv i det ögonblick som är viktigt för dig.
Vad du bör testa i stället
Bestäm vad du behöver från noden och testa det. Behöver du nåbarhet säger ett TCP-anslutningsförsök till lyssningsporten dig mer på en sekund än någon räknare. Behöver du en fungerande tunnel, förhandla fram en. Behöver du användbar genomströmning, överför något verkligt och mät det, eftersom anslutningstid och genomströmning är olika egenskaper och ett snabbt handslag inte säger något om den andra.
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
Upprepa testet i stället för att lita på ett enda försök. Tillförlitlighet är en fördelning över tid och förhållanden, och en lyckad anslutning är ett urval av storlek ett. En handfull försök under de timmar då du faktiskt använder anslutningen slår varje publicerad upptid med bred marginal.
Att läsa offentliga nodlistor utan att bli vilseledd
Upptid bär inte heller någon information om det folk vanligtvis vill ha från en VPN: certifikatets giltighet, vem som driver utgången, vilken DNS-policy som gäller och om operatören sparar anslutningsloggar. Det är separata påståenden som kräver separata bevis, och en lång räknare är inte bevis för något av dem. En nod kan vara stabil i månader och ändå vara ett dåligt val för ett integritetskrav.
Där en lista verkligen hjälper är vid att göra en kortlista. Sortera efter det du vet att du behöver, filtrera bort noder i regioner som är irrelevanta för uppgiften och testa sedan de tre eller fyra som återstår. Spara felsteget från varje försök i stället för ett enkelt ja eller nej, eftersom ”TLS-handslaget misslyckades” och ”ansluten men ingen genomströmning” leder till helt olika slutsatser.
Ramen för mätning av vägens prestanda gör samma poäng i en strängare form: definiera mätvärdet, förhållandena och metoden innan du samlar in siffror. Tillämpat på en nodlista betyder det att upptidsfältet är kontext. Mätningen du gör själv är beslutet.