Tempo de espera da conexión VPN: DNS, transporte, negociación ou inicio de sesión

“A conexión esgotou o tempo” é o erro menos específico que pode imprimir un cliente VPN. Significa que unha operación perdeu o seu prazo, e cada etapa, desde a resolución de nomes ata a resposta de inicio de sesión, ten un prazo. Os clientes que só amosan a mensaxe final fan que as etapas parezan idénticas, así que a xente sobe o tempo de espera, cambia o porto e reinstala o perfil, nesa orde, sen aprender nada. Comparar as etapas é máis rápido: cada unha falla nun lugar distinto, e cada fallo deixa un tipo distinto de evidencia.

Catro etapas, catro fallos distintos

A secuencia é fixa aínda que o cliente a oculte: o nome debe resolverse, debe establecerse un transporte cara ao enderezo resultante, o protocolo debe negociar os seus parámetros e chaves, e a conta debe autenticarse. A guía de solución de problemas de conectividade de OpenVPN segue a mesma orde para o seu propio cliente, e os demais séguena de preto. Un tempo esgotado na segunda etapa e outro na cuarta non teñen nada en común agás a palabra da pantalla.

Lea o rexistro buscando a última liña que indica progreso, non a última liña antes do erro. A maioría dos clientes imprime algo como un enderezo resolvido, un socket establecido, un handshake iniciado ou unha solicitude de autenticación, e a etapa que segue esa liña é a que se esgotou.

A resolución de nomes falla antes de calquera contacto

Se o punto final nunca se resolve, o cliente non ten a que conectarse e non se fixo ningún traballo de transporte. Ese fallo adoita ser instantáneo en lugar dun tempo de espera completo, que é a forma máis barata de distinguilo do resto. Probe o nome co resolutor do sistema e cun segundo resolutor, e compare as dúas respostas antes de concluír que o servidor está caído.

Un enderezo antigo copiado dunha publicación de foro é unha causa común dun tempo esgotado que parece un problema do servidor, porque agora o enderezo pertence a outra cousa ou a nada. Use o perfil actual do operador en lugar de substituír un enderezo que antes funcionaba. Unha resposta de ping ausente non é proba en ningún sentido: moitos puntos finais descartan ICMP mentres serven perfectamente ben.

A configuración do transporte espera un paquete que non chegará

Cando o DNS está ben e o cliente aínda consome todo o tempo de espera, a capa de transporte é o sospeitoso. En TCP pode probar o porto directamente; Test-NetConnection en Windows ou nc -vz en Linux dille se algo acepta a conexión, e iso é máis útil ca un ping. En UDP non pode probar do mesmo xeito, porque non hai ningún handshake que completar nesa capa, e esta asimetría provoca moitas conclusións equivocadas.

O que demostra unha proba TCP é limitado: un servizo que acepta o porto 443 non é necesariamente o oínte VPN, e un punto final só UDP non ten ningún porto TCP para aceptar nada. Reescribir un perfil de UDP a TCP non crea un oínte no outro lado; só cambia o que espera o seu cliente. Se a rede filtra o protocolo, o cambio produce un tempo esgotado distinto na mesma etapa.

Os portais cativos merecen a súa propia comprobación nesta etapa. Ata que o portal autorice o dispositivo, o tráfico saínte vai ao portal e o intento de túnel simplemente queda colgado. Complete primeiro o portal nun navegador, volva intentalo despois, e non cambie o perfil mentres o portal siga pendente.

Negociación e inicio de sesión significan que o servidor respondeu

Unha vez que o túnel chega ao servidor, o cliente inicia un handshake e o erro cambia de carácter. Un atasco aquí ten que ver coa compatibilidade, non coa accesibilidade: versións de protocolo desaxustadas, un cifrado ou unha configuración de canle de datos que o outro lado non aceptará, ou un perfil que espera unha función que o servidor non ofrece. OpenVPN moveu os seus valores predeterminados de negociación entre versións maiores coa suficiente frecuencia como para que un perfil escrito para unha xeración poida chegar ao servidor e aínda así non levantarse.

A autenticación é a última etapa e a máis fácil de ler mal. Un rexeitamento explícito é unha resposta, o que significa que a ruta funciona e o problema é a identidade, o certificado ou o estado da conta. Un fluxo de inicio de sesión único baseado en navegador é un terceiro caso: o cliente espera unha acción que vostede non realizou, ou un navegador que non pode lanzar, e non chegará nada ata que complete ese paso.

Compare a evidencia antes de cambiar o reintento

Manteña o dispositivo e o perfil fixos e cambie unha cousa á vez, empezando pola rede. Se o mesmo perfil conecta cun punto de acceso do teléfono e se esgota no Wi-Fi do hotel, a variable é a ruta, non o servidor. Se falla en todas partes, a variable é o perfil ou o punto final. Se falla só a unha hora do día, capture a marca de tempo e compárea con eventos do lado do servidor antes de supor nada sobre a carga.

Para un servizo que vostede administra, a comparación decisiva é se o intento chega sequera. Unha conexión que chega ao oínte e logo se atasca pertence á etapa de negociación; unha que nunca aparece na vista do oínte é un problema de transporte ou de resolución, e ningún axuste de reintentos o moverá. Os rexistros do servidor tamén separan un inicio de sesión rexeitado dunha caída silenciosa, que é a diferenza entre unha corrección de identidade e unha de cortafuegos.

Anote a versión do cliente, o nome do perfil, a hora do intento coa súa zona horaria e o primeiro erro útil en lugar da última liña de desconexión. Elimine as chaves e o material con credenciais antes de compartir o extracto. Despois faga unha corrección significativa e reintente, porque un prazo máis longo só axuda á operación lenta documentada e non fai nada por un enderezo equivocado ou un porto bloqueado.