Tempo de espera TLS de sesenta segundos: que extremo se detivo realmente?
Emparede un intento do cliente cos eventos do propio servidor antes de tocar a configuración TLS. O silencio, o descarte temperán e un rexeitamento con nome requiren correccións distintas.
O cliente réndese aos sesenta segundos cunha mensaxe sobre a negociación de chaves, e o portátil non opina sobre por que. Esa frase describe a paciencia do cliente, non o comportamento do servidor. Tres situacións moi distintas prodúcena: o paquete nunca chegou ao servizo correcto, o servizo descartouno antes de rexistrar nada, ou o servizo rexeitouno e díxoo nun lugar que o cliente non pode ver. Correlacionar un só intento en ambos os extremos é o que as separa.
Dalle a un intento unha identidade que poidas buscar
Anota a hora de inicio coa súa zona horaria, o nome do perfil, o destino que o cliente resolveu realmente, o porto e se a conexión é UDP ou TCP. Se o perfil contén varias entradas remotas, indica cal escolleu ese intento, porque un novo intento pode pasarse á entrada seguinte sen cambiar o ficheiro que estás lendo.
Toma o extremo do rexistro activo, non da descarga que recordas. Un perfil que apunta a un enderezo privado é perfectamente válido e completamente inutilizable desde unha rede que non pode encamiñar cara a el, e ese caso vese idéntico a un servidor caído.
Despois pide ao operador a mesma ventá na instancia prevista. A desviación do reloxo é o bastante común como para que un desfase de poucos minutos faga que un evento coincidente pareza ausente, así que rexistra o desfase en lugar de concluír que non houbo ningún evento.
Catro observacións, catro pasos seguintes distintos
O que o servidor rexistra decide a rama. A ausencia de calquera intento apunta ao direccionamento, ao transporte ou ao camiño cara ao servizo. Os paquetes entrantes que desaparecen antes dun intercambio ordinario apuntan aos requisitos da canle de control do servizo real. Un rexeitamento con nome apunta ao obxecto que nomea. As respostas que saen do servidor pero nunca chegan ao cliente apuntan ao camiño de volta.
Un rexistro de aplicación baleiro é unha proba máis feble do que parece. O rexistro comeza nun punto determinado do intercambio, e os paquetes descartados antes dese punto non deixan rastro no ficheiro que estás lendo. Onde está autorizado, o operador pode usar observacións do servizo e da rede para ver se chegou algo.
Mantén os catro resultados separados nas túas notas. A tentación é fusionalos en «o servidor non responde», que é a frase que envía a xente a cambiar cifrados cando o problema real é unha regra de cortafogos. Unha nota que só rexistra a palabra tempo de espera tirou a distinción que acabas de pagar.
Corrixe a etapa que a proba nomea
Unha conexión TCP que se completa só demostra que algo aceptou un socket. Non demostra que o oínte sexa o servizo OpenVPN que configurou, e un servidor web no mesmo nome de host responde perfectamente a un navegador mentres é irrelevante para o túnel.
Se o servidor informa dunha lista de revocación caducada, iso é un feito moito máis específico que o tempo de espera final do cliente, e a corrección pertence á autoridade de certificación e non á rede. Se os dous extremos non coinciden sobre a protección da canle de control ou o material compartido, restablecer un contrasinal non cambia nada, porque o descarte ocorre antes de que se examine calquera credencial.
Cambia unha cousa que a proba realmente apoie, e despois repite o mesmo perfil contra o mesmo extremo. Conserva o primeiro evento novo se a conexión avanza máis, porque ese evento é a seguinte etapa da investigación, non un problema novo.
grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3
Que cambia realmente ampliar a ventá
Sesenta segundos é a ventá de aperta de mans do cliente, e a referencia comunitaria do cliente documenta a opción que a axusta. Aumentala fai que o cliente espere máis antes de renderse. Non fai aparecer un servizo ausente nin fai aceptable un paquete rexeitado.
Hai un uso lexítimo dunha ventá máis longa nunha ligazón lenta ou nun servidor moi cargado, e paga a pena probalo cando tes probas de que o intercambio avanza lentamente en lugar de non ocorrer. Probalo primeiro só atrasa o mesmo diagnóstico outro minuto e fai a liña temporal máis difícil de ler. Se a liña temporal mostra un intercambio que avanza e logo se detén, a ventá é un síntoma de carga e non de accesibilidade.