O VPN desconéctase constantemente? Segue esta orde

Anota o intervalo, o erro do cliente e o estado da rede antes de cambiar nada. O oco entre desconexións diche cal das catro capas comprobar.

Antes de reinstalar o cliente, anota tres cousas: canto tempo estivo levantado o túnel, que dixo o cliente cando caeu e se o equipo durmiu ou cambiou de rede mentres tanto. Esa nota é a única proba que terás despois, e reinstalar adoita borrala. Unha caída cun intervalo repetible é un temporizador ou unha caducidade de estado; unha caída nun momento aleatorio é un problema de ruta. A orde de abaixo evita que cambies tres cousas á vez e non aprendas nada.

Paso un: captura o intervalo e o texto do erro

Empeza polo rexistro do propio cliente e non polo panel do provedor. Nun cliente Linux, o rexistro do servizo máis o estado vivo do túnel cobren a maior parte:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Anota as marcas de tempo do último handshake correcto e o momento en que se detivo o tráfico, non só o momento en que a icona cambiou de cor. Un cliente GUI que di desconectado a posteriori pode estar informando dun estado que o núcleo acadou segundos antes.

Conserva a redacción do erro. Un tempo de espera esgotado, un rexeitamento de autenticación e un erro de adaptador ou controlador apuntan a tres capas distintas, e a maior parte do esforzo perdido neste problema vén de tratalos como un só. Copia a liña literalmente na túa nota.

Paso dous: cambia unha variable, non o perfil

Mantén o dispositivo e o perfil fixos e move a máquina a outra rede de acceso, como un punto de acceso do móbil. Esta é a proba máis barata que separa o cliente da ruta. Execútaa o tempo suficiente para cubrir o intervalo de fallo orixinal; dous minutos estables non demostran nada sobre unha caída que ocorre no minuto trinta.

Un portátil con porto Ethernet dache unha segunda comparación que saca o Wi-Fi da ecuación por completo. Se o túnel aguanta nas dúas alternativas, a rede de acceso orixinal merece a atención: itinerancia entre puntos de acceso, un router doméstico coa táboa de tradución caducada ou unha ligazón superior que reinicia fluxos longos.

Anota que variable cambiaches. Unha comparación só conta cando todo o demais permaneceu igual, e iso inclúe o extremo do servidor e a hora do día.

Paso tres: relaciona o intervalo cunha capa

A duración dunha boa sesión é o número único máis informativo que tes. Léoo contra esta lista antes de tocar temporizadores:

  • Caída tras suspender ou retomar: o estado do túnel sobreviviu á suspensión pero a interface non. Comproba o comportamento de reconexión ao retomar e se o servizo reinicia o túnel ou espera tráfico.
  • Caída só cando está inactivo: algo no medio fixo caducar o fluxo. É xusto o caso para o que existen os keepalive.
  • Caída a unha idade de sesión fixa: un evento de reautenticación ou de renovación de claves, non un fallo de ruta. Un rexeitamento explícito no rexistro exactamente nese intervalo é a pista.
  • Caída durante transferencias grandes ou páxinas grandes: sospeita do MTU e da fragmentación, non dun temporizador de inactividade.

Para o caso de inactividade, os axustes dependen do protocolo e os dous extremos importan. O keepalive 10 60 de OpenVPN no servidor envía un ping cada 10 segundos e reinicia a ligazón tras 60 segundos sen un; os clientes de WireGuard detrás de NAT usan PersistentKeepalive = 25 no bloque de par. OpenVPN tamén renegocia a canle de datos cun temporizador, reneg-sec, que por defecto son 3600 segundos na versión 2.x.

Non copies valores agresivos da guía doutro provedor. Un tempo de espera curto nunha ligazón móbil con perdas produce xusto as desconexións que debía evitar, e os valores enviados polo servidor anulan o que configures no perfil do cliente.

Paso catro: compara unha alternativa compatible

Se o operador publica tanto un perfil UDP como un TCP, executa o mesmo dispositivo e a mesma rede contra o outro. Usa o ficheiro correspondente real en lugar de editar o transporte nun perfil copiado. Un perfil TCP estable nunha ruta onde o UDP se reinicia acouta o problema a esa ruta; non demostra que o TCP sexa o mellor transporte en todas partes.

A mesma lóxica aplícase aos extremos. Proba outro servidor e mantén o resultado orixinal ao lado. Se só unha saída reinicia sesións, é unha proba sobre ese extremo, non un motivo para refacer cada adaptador do portátil.

Despois de calquera cambio, repite o desencadeante orixinal e confirma onde vai realmente o tráfico. Un acceso a internet recuperado non é o mesmo resultado que o tráfico dentro do túnel, e un cliente que caeu en silencio a unha ruta directa parece san desde o navegador.

Verifica a corrección e conserva a reversión

Unha corrección verifícase reproducindo o desencadeante orixinal, non cunha conexión correcta. Deixa o túnel inactivo máis alá do vello intervalo de fallo, suspende e retoma unha vez, e comproba despois a idade do handshake e o enderezo de saída:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Conserva o perfil anterior e os valores de temporizador anteriores ata que o novo comportamento sobreviva unha xornada laboral completa. Se as caídas volven, restaura a copia de seguridade e despois volve aplicar os cambios dun en un para que o segundo intento comece desde un estado coñecido.

Se o rexistro segue limpo e o túnel aínda cae cun intervalo repetible, a seguinte parada é o lado do servidor para esa sesión. Leva contigo o identificador de sesión do cliente e a hora exacta da caída, porque ese par é o que fai que un rexistro do servidor sexa buscable. As opcións de ligazón do protocolo están documentadas no manual de OpenVPN 2.6 cando necesitas o significado exacto dun valor.

Artigos relacionados