Temps de funcionament d’un servidor VPN: què no us diu aquesta xifra
El comptador mesura el temps des que alguna cosa va arrencar, no l’abastabilitat des de la vostra xarxa. Reviseu la definició i l’hora de l’informe, i després proveu el que necessiteu.
Una llista pública de nodes mostra un servidor amb un temps de funcionament mesurat en setmanes, el trieu, i la connexió falla al primer intent. No és publicitat enganyosa; és la pregunta equivocada feta a una xifra que mesura una altra cosa. El temps de funcionament normalment indica quant de temps fa que un procés, un contenidor o una màquina funciona des de l’últim arrencament, i això és una propietat de la infraestructura del publicador, no del vostre camí cap a ell. Tractar-lo com a fiabilitat és el mateix error de categoria que tractar l’odòmetre d’un cotxe com un informe de la carretera.
Què mesura la xifra
En un amfitrió amb un gestor de serveis modern, el comptador està ancorat a un esdeveniment que realment podeu llegir: la marca de temps en què la unitat va entrar a l’estat actiu, o l’hora d’arrencada de la màquina. Tota la resta és aritmètica sobre aquesta àncora, i la definició de l’àncora varia entre publicadors. Una llista pot reiniciar-se en reiniciar el dimoni, una altra en reiniciar la màquina, i una tercera en un reinici manual fet per un operador que volia un gràfic net.
systemctl show -p ActiveEnterTimestamp --value openvpn-server@server
uptime -s
systemctl is-active openvpn-server@server
Aquestes tres ordres responen a tres preguntes diferents, i un directori que mostra una sola xifra no us pot dir quina de les tres ha utilitzat. Per tant, comparar un comptador cru de dues llistes no és cap comparació fins que no sapigueu a què es reinicia cadascun.
Un procés pot estar en marxa mentre el camí està caigut
El dimoni escolta. El certificat és vàlid. El procés fa vint-i-tres dies que és viu. Res d’això no garanteix que els paquets de la vostra xarxa hi arribin, perquè l’abastabilitat és una propietat de tot el camí: l’enllaç ascendent del proveïdor, el peering entre la seva xarxa i la vostra, la congestió en un enllaç de trànsit compartit i el tallafoc davant de la vostra pròpia connexió.
Un servidor també pot estar en marxa i ser inútil per un altre motiu. Un node que ha acceptat molts més clients del que la seva amplada de banda admet mostrarà un temps de funcionament llarg i una experiència horrible, perquè el comptador no mesura capacitat ni contenció. Aquesta és la manera més habitual com un node amb molt de temps de funcionament decep: no hi ha res trencat, tot està ocupat.
També val la pena recordar el cas invers. Un node que es va reiniciar fa una hora pot estar perfectament sa ara, i ordenar pel nombre més gran l’exclou silenciosament. El temps de funcionament no és una puntuació de qualitat, i tractar-lo com a tal selecciona per edat en lloc de per idoneïtat.
Frescor: l’informe és més antic que el vostre intent
Els directoris públics són pàgines generades a partir de comprovacions periòdiques, no telemetria en directe. El temps de funcionament que llegiu es va calcular a l’última actualització, i la connexió que intenteu passa després. Entremig, un proveïdor pot fer caure un enllaç, canviar un certificat, moure una adreça o treure un node de servei, i la pàgina continuarà mostrant l’últim estat bo conegut fins al següent rastreig.
Aquest buit també funciona en l’altre sentit. Un node informat com a caigut pot haver-se recuperat minuts després de generar-se l’informe, així que reintentar immediatament contra un altre node no sempre és la millor opció.
La regla pràctica és que cada camp informat és una afirmació sobre el passat. Feu-lo servir per construir una llista curta i després verifiqueu amb un mesurament que feu vosaltres mateixos en el moment que us importa.
Què cal provar en lloc d’això
Decidiu què necessiteu del node i proveu-ho. Si necessiteu abastabilitat, un intent de connexió TCP al port d’escolta us diu en un segon més que qualsevol comptador. Si necessiteu un túnel que funcioni, negocieu-ne un. Si necessiteu un cabal utilitzable, transferiu alguna cosa real i mesureu-la, perquè el temps de connexió i el cabal són propietats diferents i una negociació ràpida no diu res sobre la segona.
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
Repetiu la prova en lloc de confiar en un sol intent. La fiabilitat és una distribució al llarg del temps i de les condicions, i una connexió reeixida és una mostra de mida u. Un grapat d’intents durant les hores en què realment utilitzeu la connexió superarà qualsevol temps de funcionament publicat amb un marge ampli.
Llegir llistes públiques de nodes sense ser enganyat
El temps de funcionament tampoc no aporta cap informació sobre les coses que la gent sol voler d’una VPN: la validesa del certificat, qui opera la sortida, quina política de DNS s’aplica i si l’operador guarda registres de connexió. Són afirmacions separades que necessiten proves separades, i un comptador llarg no és prova de cap d’elles. Un node pot ser estable durant mesos i seguir sent una mala elecció per a un requisit de privadesa.
On una llista sí que ajuda és a fer la llista curta. Ordeneu per allò que sabeu que necessiteu, filtreu els nodes de regions irrellevants per a la tasca i proveu els tres o quatre que queden. Guardeu l’etapa de fallada de cada intent en lloc d’un simple sí o no, perquè «la negociació TLS ha fallat» i «connectat però sense cabal» porten a conclusions completament diferents.
El marc per mesurar el rendiment del camí planteja el mateix punt en una forma més rigorosa: definiu la mètrica, les condicions i el mètode abans de recollir xifres. Aplicat a una llista de nodes, això significa que el camp del temps de funcionament és context. El mesurament que feu vosaltres és la decisió.