El VPN es desconnecta constantment? Segueix aquest ordre

Abans de reinstal·lar el client, anota tres coses: quant de temps va estar aixecat el túnel, què va dir el client quan es va tallar i si l’equip va dormir o va canviar de xarxa mentrestant. Aquesta nota és l’única prova que tindràs després, i reinstal·lar normalment l’esborra. Una caiguda amb un interval repetible és un temporitzador o una caducitat d’estat; una caiguda en un moment aleatori és un problema de camí. L’ordre de sota evita que canviïs tres coses alhora i no aprenguis res.

Pas u: captura l’interval i el text de l’error

Comença pel registre del propi client i no pel tauler del proveïdor. En un client Linux, el registre del servei més l’estat viu del túnel cobreixen la major part:

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 les marques de temps de l’últim handshake correcte i el moment en què el trànsit es va aturar, no només el moment en què la icona va canviar de color. Un client GUI que diu desconnectat després dels fets pot estar informant d’un estat que el nucli va assolir segons abans.

Conserva la redacció de l’error. Un temps d’espera esgotat, un rebuig d’autenticació i un error d’adaptador o controlador apunten a tres capes diferents, i la major part de l’esforç perdut en aquest problema ve de tractar-los com una sola. Copia la línia literalment a la teva nota.

Pas dos: canvia una variable, no el perfil

Mantén l’equip i el perfil fixos i mou la màquina a una altra xarxa d’accés, com ara un punt d’accés del mòbil. Aquesta és la prova més barata que separa el client del camí. Executa-la prou estona per cobrir l’interval de fallada original; dos minuts estables no demostren res sobre una caiguda que passa al minut trenta.

Un portàtil amb port Ethernet et dóna una segona comparació que treu el Wi-Fi de l’equació del tot. Si el túnel aguanta en les dues alternatives, la xarxa d’accés original mereix l’atenció: itinerància entre punts d’accés, un encaminador domèstic amb la taula de traducció caducada o un enllaç superior que reinicia fluxos llargs.

Anota quina variable has canviat. Una comparació només compta quan tota la resta s’ha mantingut igual, i això inclou el punt final del servidor i l’hora del dia.

Pas tres: relaciona l’interval amb una capa

La durada d’una bona sessió és el nombre únic més informatiu que tens. Llegeix-lo contra aquesta llista abans de tocar temporitzadors:

• Caiguda després de suspendre o reprendre: l’estat del túnel va sobreviure a la suspensió però la interfície no. Comprova el comportament de reconnexió en reprendre i si el servei reinicia el túnel o espera trànsit.
• Caiguda només quan està inactiu: alguna cosa al mig ha fet caducar el flux. És just el cas per al qual existeixen els keepalive.
• Caiguda a una edat de sessió fixa: un esdeveniment de reautenticació o de renovació de claus, no una fallada de camí. Un rebuig explícit al registre exactament en aquest interval és la pista.
• Caiguda durant transferències grans o pàgines grans: sospita de l’MTU i la fragmentació, no d’un temporitzador d’inactivitat.

Per al cas d’inactivitat, els paràmetres depenen del protocol i els dos extrems importen. El keepalive 10 60 d’OpenVPN al servidor envia un ping cada 10 segons i reinicia l’enllaç després de 60 segons sense cap; els clients de WireGuard darrere de NAT fan servir PersistentKeepalive = 25 al bloc de parell. OpenVPN també renegocia el canal de dades amb un temporitzador, reneg-sec, que per defecte és de 3600 segons a la versió 2.x.

No copiïs valors agressius de la guia d’un altre proveïdor. Un temps d’espera curt en un enllaç mòbil amb pèrdues produeix justament les desconnexions que havia de prevenir, i els valors enviats pel servidor substitueixen el que configures al perfil del client.

Pas quatre: compara una alternativa compatible

Si l’operador publica tant un perfil UDP com un de TCP, executa el mateix equip i la mateixa xarxa contra l’altre. Fes servir el fitxer corresponent real en lloc d’editar el transport en un perfil copiat. Un perfil TCP estable en un camí on l’UDP es reinicia estreny el problema a aquest camí; no demostra que el TCP sigui el millor transport a tot arreu.

La mateixa lògica s’aplica als punts finals. Prova un altre servidor i mantén el resultat original al costat. Si només una sortida reinicia sessions, és una prova sobre aquell punt final, no un motiu per refer cada adaptador del portàtil.

Després de qualsevol canvi, repeteix el disparador original i confirma on va realment el trànsit. Un accés a internet recuperat no és el mateix resultat que el trànsit dins del túnel, i un client que ha caigut en silenci a una ruta directa sembla sa des del navegador.

Verifica la solució i conserva la reversió

Una solució es verifica reproduint el disparador original, no amb una connexió correcta. Deixa el túnel inactiu més enllà del vell interval de fallada, suspèn i reprèn un cop, i comprova després l’edat del handshake i l’adreça de sortida:

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

Conserva el perfil anterior i els valors de temporitzador anteriors fins que el nou comportament sobrevisqui un dia de feina sencer. Si les caigudes tornen, restaura la còpia de seguretat i després torna a aplicar els canvis d’un en un perquè el segon intent comenci des d’un estat conegut.

Si el registre es manté net i el túnel encara cau amb un interval repetible, la següent parada és el costat del servidor per a aquesta sessió. Porta l’identificador de sessió del client i l’hora exacta de la caiguda, perquè aquesta parella és el que fa cercable un registre de servidor. Les opcions d’enllaç del protocol estan documentades al manual d’OpenVPN 2.6 quan necessites el significat exacte d’un valor.