Temps d'espera TLS de seixanta segons: quin extrem es va aturar realment?

El client es rendeix al cap de seixanta segons amb un missatge sobre la negociació de claus, i l'ordinador portàtil no opina sobre per què. Aquesta frase descriu la paciència del client, no el comportament del servidor. Tres situacions ben diferents la produeixen: el paquet no va arribar mai al servei correcte, el servei el va descartar abans de registrar res, o el servei el va rebutjar i ho va dir en un lloc que el client no pot veure. Correlacionar un sol intent en tots dos extrems és el que les separa.

Dóna a un intent una identitat que puguis cercar

Anota l'hora d'inici amb la seva zona horària, el nom del perfil, la destinació que el client va resoldre realment, el port i si la connexió és UDP o TCP. Si el perfil conté diverses entrades remotes, indica quina va triar aquell intent, perquè un reintent pot haver passat a l'entrada següent sense canviar el fitxer que llegeixes.

Pren el punt final del registre actiu, no de la descàrrega que recordes. Un perfil que apunta a una adreça privada és perfectament vàlid i completament inutilitzable des d'una xarxa que no hi pot encaminar, i aquest cas sembla idèntic a un servidor caigut.

Després demana a l'operador la mateixa finestra a la instància prevista. La desviació de rellotge és prou comuna que un decalatge de pocs minuts pot fer que un esdeveniment coincident sembli absent, així que registra el decalatge en lloc de concloure que no hi va haver cap esdeveniment.

Quatre observacions, quatre passos següents diferents

El que el servidor registra decideix la branca. L'absència de qualsevol intent apunta a l'adreçament, el transport o el camí cap al servei. Els paquets entrants que desapareixen abans d'un intercanvi ordinari apunten als requisits del canal de control del servei real. Un rebuig amb nom apunta a l'objecte que anomena. Les respostes que surten del servidor però no arriben mai al client apunten al camí de tornada.

Un registre d'aplicació buit és una evidència més feble del que sembla. El registre comença en un punt determinat de l'intercanvi, i els paquets descartats abans d'aquest punt no deixen cap rastre en el fitxer que llegeixes. On està autoritzat, l'operador pot fer servir observacions del servei i de la xarxa per veure si hi va arribar res.

Mantén els quatre resultats separats a les notes. La temptació és fusionar-los en «el servidor no respon», que és la frase que envia la gent a canviar xifrats quan el problema real és una regla de tallafoc. Una nota que només registra la paraula temps d'espera ha llançat la distinció que acabes de pagar.

Corregeix l'etapa que l'evidència assenyala

Una connexió TCP que es completa només demostra que alguna cosa va acceptar un sòcol. No demostra que l'oient sigui el servei OpenVPN que has configurat, i un servidor web al mateix nom d'amfitrió respon perfectament a un navegador mentre és irrellevant per al túnel.

Si el servidor informa d'una llista de revocació caducada, això és un fet molt més específic que el temps d'espera final del client, i la correcció pertoca a l'autoritat de certificació i no a la xarxa. Si els dos extrems no coincideixen sobre la protecció del canal de control o el material compartit, restablir una contrasenya no canvia res, perquè el descart passa abans que s'examini cap credencial.

Canvia una cosa que l'evidència realment avali, i després repeteix el mateix perfil contra el mateix punt final. Conserva el primer esdeveniment nou si la connexió arriba més enllà, perquè aquest esdeveniment és la fase següent de la investigació, no un problema nou.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

Què canvia realment ampliar la finestra

Seixanta segons és la finestra d'apretada de mans del client, i la referència comunitària del client documenta l'opció que l'ajusta. Augmentar-la fa que el client esperi més abans de rendir-se. No fa aparèixer un servei absent ni fa acceptable un paquet rebutjat.

Hi ha un ús legítim d'una finestra més llarga en un enllaç lent o un servidor molt carregat, i val la pena provar-ho quan tens proves que l'intercanvi avança lentament i no que no passa. Provar-ho primer només endarrereix el mateix diagnòstic un minut més i fa la línia temporal més difícil de llegir. Si la línia temporal mostra un intercanvi que avança i després s'atura, la finestra és un símptoma de càrrega, no d'abastabilitat.