VPN-optyd: wat daardie syfer jou nie vertel nie

’n Openbare nodelys wys ’n bediener met ’n optyd van weke, so jy kies dit, en die verbinding faal met die eerste poging. Dit is nie vals advertensie nie; dit is die verkeerde vraag aan ’n syfer wat iets anders meet. Optyd wys gewoonlik hoe lank ’n proses, houer of masjien aan die gang is sedert dit laas begin het, en dit is ’n eienskap van die uitgewer se infrastruktuur eerder as van jou pad daarheen. Om dit as betroubaarheid te behandel, is dieselfde kategorie-fout as om ’n motor se kilometerstand as ’n padverslag te behandel.

Wat die syfer meet

Op ’n gasheer met ’n moderne diensbestuurder is die teller geanker aan ’n gebeurtenis wat jy werklik kan lees: die tydstempel toe die eenheid die aktiewe toestand betree het, of die opstarttyd van die masjien. Alles anders is rekenkunde op daardie anker, en die definisie van die anker verskil tussen uitgewers. Een lys kan terugstel op ’n daemon-herstart, ’n ander op ’n herlaai, en ’n derde op ’n handmatige terugstelling deur ’n operateur wat ’n skoon grafiek wou hê.

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

Daardie drie opdragte beantwoord drie verskillende vrae, en ’n gidslys wat een syfer wys, kan jou nie sê watter een daarvan dit gebruik het nie. Om ’n rou teller van twee lyste te vergelyk, is dus glad nie ’n vergelyking nie totdat jy weet waarop elkeen terugstel.

’n Proses kan aan die gang wees terwyl die pad af is

Die daemon luister. Die sertifikaat is geldig. Die proses leef al drie-en-twintig dae. Niks daarvan waarborg dat pakkette van jou netwerk dit bereik nie, want bereikbaarheid is ’n eienskap van die hele pad: die verskaffer se opstuurverbinding, die peering tussen hulle netwerk en joune, die oorlading op ’n gedeelde deurvoerverbinding, en die firewall voor jou eie verbinding.

’n Bediener kan ook aan die gang en nutteloos wees om ’n ander rede. ’n Node wat veel meer kliënte aanvaar het as wat sy bandwydte ondersteun, sal ’n lang optyd en ’n haglike ervaring wys, want die teller meet nie kapasiteit of mededinging nie. Dit is die mees algemene manier waarop ’n node met lang optyd teleurstel: niks is stukkend nie, alles is besig.

Die omgekeerde geval is ook die moeite werd om te onthou. ’n Node wat ’n uur gelede herbegin het, kan nou heeltemal gesond wees, en om volgens die grootste syfer te sorteer, sluit dit stilweg uit. Optyd is nie ’n kwaliteitstelling nie, en om dit as een te behandel, kies op ouderdom eerder as op geskiktheid.

Varsheid: die verslag is ouer as jou poging

Openbare gidse is bladsye wat uit periodieke kontroles gegenereer word, nie lewende telemetrie nie. Die optyd wat jy lees, is by die laaste verversing bereken, en die verbinding wat jy probeer, gebeur daarna. Intussen kan ’n verskaffer ’n skakel laat faal, ’n sertifikaat verander, ’n adres skuif of ’n node buite diens stel, en die bladsy sal aanhou om die laaste bekende goeie toestand te rapporteer tot die volgende kruip.

Daardie gaping loop ook die ander kant toe. ’n Node wat as af gerapporteer is, kon minute nadat die verslag gegenereer is herstel het, so ’n onmiddellike herpoging teen ’n ander node is nie altyd die beter keuse nie.

Die praktiese reël is dat elke gerapporteerde veld ’n bewering oor die verlede is. Gebruik dit om ’n kortlys te bou, en verifieer dan met ’n meting wat jy self op die oomblik wat vir jou saak maak, doen.

Wat om eerder te toets

Besluit wat jy van die node nodig het en toets dit. As jy bereikbaarheid nodig het, sê ’n TCP-verbindingspoging na die luisterpoort in een sekonde meer as enige teller. As jy ’n werkende tonnel nodig het, onderhandel een. As jy bruikbare deurvloei nodig het, dra iets werkliks oor en meet dit, want verbindingstyd en deurvloei is verskillende eienskappe en ’n vinnige handdruk sê niks oor die tweede nie.

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 die toets eerder as om ’n enkele poging te vertrou. Betroubaarheid is ’n verspreiding oor tyd en toestande, en een suksesvolle verbinding is ’n steekproef van grootte een. ’n Handvol pogings oor die ure waarin jy die verbinding werklik gebruik, sal enige gepubliseerde optyd met ’n wye marge oortref.

Om openbare nodelyste te lees sonder om mislei te word

Optyd dra ook geen inligting oor die dinge wat mense gewoonlik van ’n VPN wil hê nie: sertifikaatgeldigheid, wie die uitgang bedryf, watter DNS-beleid geld, en of die operateur verbindingsrekords hou. Dit is afsonderlike bewerings wat afsonderlike bewyse nodig het, en ’n lang teller is nie bewys vir enige van hulle nie. ’n Node kan maande lank stabiel wees en steeds ’n swak keuse vir ’n privaatheidvereiste wees.

Waar ’n lys wel help, is met die kortlys. Sorteer volgens wat jy weet jy nodig het, filtreer nodes in streke uit wat nie vir die taak relevant is nie, en toets dan die drie of vier wat oorbly. Hou die mislukkingsfase van elke poging eerder as ’n enkele ja-of-nee, want "TLS handshake failed" en "connected but no throughput" lei tot heeltemal verskillende gevolgtrekkings.

Die raamwerk vir die meting van padprestasie maak dieselfde punt in ’n meer streng vorm: definieer die maatstaf, die toestande en die metode voordat jy syfers versamel. Toegepas op ’n nodelys beteken dit die optydveld is konteks. Die meting wat jy self doen, is die besluit.