Caiguda horària d'OpenVPN: renegociació o una reconnexió real?

Seixanta minuts, o trenta, o cent vint: una caiguda que cau en un interval rodó gairebé mai no és la xarxa. OpenVPN renova segons un temporitzador el material de claus que protegeix el canal de dades, i un temporitzador més curt que el que donàveu per fet sembla exactament un enllaç que falla una vegada i una altra. Els usuaris informen d’una connexió trencada mentre el registre informa d’un intercanvi de claus correcte. La guia següent separa aquesta renovació d’un reinici real, llegeix el valor que realment està en vigor i només el canvia després que el cost sigui damunt la taula.

Feu els passos en ordre, perquè el primer decideix si la resta de la pàgina us afecta gens. Si us avanceu, passareu una vetllada ajustant un temporitzador per una avaria que no hi té res a veure.

Distingiu un reinici suau d’un reinici

La línia del registre és tot el diagnòstic. Una renegociació escriu un reinici suau i després un intercanvi de claus nou dins del mateix túnel: la interfície conserva la seva adreça, les rutes no es tornen a afegir i les sessions TCP establertes solen sobreviure amb una pausa. Un reinici real trenca la sessió, reconstrueix la interfície, pot lliurar una adreça de client diferent i mata totes les connexions de llarga durada. Tots dos esdeveniments són ordinaris; només un explica una trucada tallada.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

La línia de versió importa perquè la redacció del registre canvia entre versions, i un missatge que recordeu del 2.3 pot estar redactat diferent al 2.6. Llegiu el vostre propi registre i no un extracte de fòrum d’algú altre. Citeu la línia exacta quan demaneu ajuda, perquè una paràfrasi perd el detall que identifica l’esdeveniment. Si l’adreça de la interfície no canvia durant l’esdeveniment i la llista de sessions sobreviu, esteu veient una renovació i les seccions restants s’apliquen.

Llegiu el temporitzador efectiu, no el vostre fitxer

reneg-sec és el nombre de segons entre renegociacions del canal de dades i el seu valor per defecte és 3600. Cada parell porta el seu valor, i el més petit dels dos és el que realment desencadena la renovació. Aquesta sola regla explica la majoria dels informes: un perfil de client que fixa un nombre gran encara es reinicia cada hora mentre el servidor manté el valor per defecte.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Llegiu també la configuració efectiva del servidor, incloent-hi tot el que empeny, abans de treure conclusions del fitxer del client. Després apugeu la verbositat i observeu un interval de principi a fi: el nivell 3 ja mostra les línies de renegociació, i les marques de temps us diuen si l’esdeveniment es repeteix cada 3600 segons o si segueix l’activitat.

Canvieu-ho on realment s’empeny

El remei que circula és una sola línia al perfil del client, i és el lloc equivocat aproximadament la meitat de les vegades. Com que guanya el valor més baix dels parells, un client que posa el temporitzador a zero encara pot ser renegociat per un servidor que no ha canviat.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Quan els perfils es generen centralment, editeu la plantilla i no la còpia desplegada, o la propera execució d’aprovisionament restaurarà el valor que acabeu d’eliminar. Verifiqueu-ho observant dos intervals, no un: una hora tranquil·la també encaixa amb un temporitzador fixat a 7200.

Decidiu també què passa en un desplegament mixt. Si esteneu el canvi primer als clients, queda una finestra en què el servidor encara desencadena la renovació; és inofensiu però confús si mireu els registres buscant confirmació. Canvieu primer el costat que té el valor més petit i el símptoma desapareix al punt que espereu.

Què cedeu en desactivar la renegociació

La renegociació regular limita quant de temps un sol conjunt de claus del canal de dades protegeix el trànsit. Desactivar el temporitzador no trenca el túnel, i en un router domèstic o una porta d’enllaç d’oficina petita l’exposició pràctica és modesta. És igualment un intercanvi, i val la pena enunciar-lo abans de fer-lo. El que canvia és quant de temps un conjunt de claus protegeix una sessió, no si el túnel funciona gens.

El cas raonable per desactivar-lo és un reinici que trenca una cosa que no es pot reprendre: una trucada que cau, una sessió d’escriptori remot que s’ha de tornar a establir, una còpia de seguretat que recomença des del principi. Si la pausa és invisible per als usuaris, mantenir el valor per defecte no costa res i conserva la rotació de claus que us han donat.

Preferiu arreglar la causa quan el patró ho permet. Una renovació que falla a mig camí mentre la primera encaixada de mans ha reeixit apunta al camí i no al temporitzador: busqueu un problema de mida de paquet en l’intercanvi més gran del canal de control, un tallafoc amb estat que descarta el flux o una proposta que només reeixix al primer intent. Cadascun d’aquests deixa una petjada en el mateix registre que acabeu de llegir. Desactivar el temporitzador amaga aquesta evidència.

Quan l’interval apunta a un altre lloc

Dos veïns de la configuració produeixen símptomes semblants i arreglos diferents. ping-restart reinicia el túnel quan no arriba res durant un període configurat, mentre que ping-exit abaixa el client del tot. Una caiguda inactiva sense cap renegociació enlloc del registre pertany a aquests o a un dispositiu NAT que ha fet caducar el mapatge UDP segons el seu propi calendari.

Els routers de consum, els punts d’accés mòbils i el NAT de nivell operador fan caducar les sessions UDP inactives sense dir-ho a ningú. Aquesta fallada segueix la inactivitat i no el rellotge, i aquesta és la pista: una sessió que cau després de deu minuts tranquils i sobreviu una hora de trànsit constant no està renegociant.

Anoteu tres coses abans de canviar-ne una quarta: l’interval que heu mesurat, el valor efectiu que heu trobat i l’ordre que l’ha mostrat. Si l’interval es mou quan es mou el temporitzador, el mecanisme queda identificat i l’arreglo és una decisió sobre l’intercanvi anterior. Si no es mou, torneu a posar el paràmetre i seguiu mirant keepalives, estat del NAT i pèrdua de paquets.