Elk uur een OpenVPN-onderbreking: heronderhandeling of een echte herverbinding?

Zestig minuten, of dertig, of honderdtwintig: een onderbreking die op een rond interval valt, is bijna nooit het netwerk. OpenVPN vernieuwt volgens een timer het sleutelmateriaal dat het datakanaal beschermt, en een timer die korter is dan u aannam, ziet er precies uit als een verbinding die steeds uitvalt. Gebruikers melden een verbroken verbinding terwijl het log een geslaagde sleuteluitwisseling meldt. De handleiding hieronder scheidt die vernieuwing van een echte herstart, leest de waarde die werkelijk van kracht is en wijzigt die pas nadat de kosten op tafel liggen.

Voer de stappen in volgorde uit, want de eerste bepaalt of de rest van de pagina überhaupt op u van toepassing is. Slaat u vooruit, dan brengt u een avond door met het afstellen van een timer voor een storing die er niets mee te maken heeft.

Onderscheid een zachte reset van een herstart

De logregel is de hele diagnose. Een heronderhandeling schrijft een zachte reset en daarna een nieuwe sleuteluitwisseling binnen dezelfde tunnel: de interface behoudt zijn adres, routes worden niet opnieuw toegevoegd, en bestaande TCP-sessies overleven meestal met een pauze. Een echte herstart rukt de sessie uiteen, bouwt de interface opnieuw op, geeft mogelijk een ander clientadres uit en doodt elke langdurige verbinding. Beide gebeurtenissen zijn gewoon; slechts één ervan verklaart een weggevallen gesprek.

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

De versieregel is belangrijk omdat de logformulering tussen releases verschuift, en een bericht dat u uit 2.3 kent, kan in 2.6 anders geformuleerd zijn. Lees uw eigen log in plaats van een forumextract van iemand anders. Citeer de exacte regel wanneer u om hulp vraagt, want een parafrase verliest het detail dat de gebeurtenis identificeert. Als het interfaceadres tijdens de gebeurtenis ongewijzigd blijft en de sessielijst overleeft, ziet u een vernieuwing en gelden de overige secties.

Lees de effectieve timer, niet uw bestand

reneg-sec is het aantal seconden tussen heronderhandelingen van het datakanaal en de standaardwaarde is 3600. Elke kant draagt zijn eigen waarde, en de kleinste van de twee is wat de vernieuwing werkelijk veroorzaakt. Die ene regel verklaart de meeste meldingen: een clientprofiel dat een groot getal instelt, wordt nog steeds elk uur gereset terwijl de server de standaard aanhoudt.

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

Lees ook de effectieve configuratie van de server, inclusief alles wat die pusht, voordat u uit het clientbestand een conclusie trekt. Verhoog dan de uitgebreidheid en volg één interval van begin tot eind: niveau 3 toont de heronderhandelingsregels al, en de tijdstempels zeggen of de gebeurtenis elke 3600 seconden terugkeert of juist activiteit volgt.

Wijzig het waar het werkelijk wordt gepusht

Het rondgaande middel is één regel in het clientprofiel, en het is ongeveer de helft van de tijd de verkeerde plek. Omdat de lagere waarde van de kant wint, kan een client die de timer op nul zet, nog steeds opnieuw worden onderhandeld door een server die niet is gewijzigd.

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

Waar profielen centraal worden gegenereerd, bewerk dan de sjabloon en niet de uitgerolde kopie, anders herstelt de volgende provisioning-run de waarde die u net hebt verwijderd. Controleer door twee intervallen te bekijken, niet één: één rustig uur past ook bij een timer die op 7200 is gezet.

Bepaal ook wat er bij een gemengde uitrol gebeurt. Als u de wijziging eerst naar clients uitrolt, blijft er een venster waarin de server de vernieuwing nog veroorzaakt; dat is onschadelijk maar verwarrend als u de logs op bevestiging volgt. Wijzig eerst de kant met de kleinere waarde en het symptoom verdwijnt op het punt dat u verwacht.

Wat u opgeeft door heronderhandeling uit te schakelen

Regelmatige heronderhandeling beperkt hoe lang één set datakanaalsleutels het verkeer beschermt. De timer uitschakelen breekt de tunnel niet, en op een thuisrouter of een kleine kantoorpoort is de praktische blootstelling bescheiden. Het blijft een ruil, en de ruil is het waard om te benoemen voordat u hem doet. Wat verandert, is hoe lang één sleutelset een sessie beschermt, niet of de tunnel überhaupt werkt.

Het redelijke geval om het uit te schakelen is een reset die iets breekt dat niet kan worden hervat: een gesprek dat wegvalt, een sessie op afstand die opnieuw moet worden opgezet, een back-up die opnieuw begint. Als de pauze onzichtbaar is voor gebruikers, kost de standaard niets en behoudt u de sleutelrotatie die u kreeg.

Geef er de voorkeur aan de oorzaak te verhelpen wanneer het patroon dat toelaat. Een vernieuwing die halverwege faalt terwijl de eerste handdruk slaagde, wijst op het pad en niet op de timer: zoek een pakketgrootteprobleem in de grotere uitwisseling van het controlekanaal, een stateful firewall die de stroom laat vallen, of een voorstel dat alleen bij de eerste poging slaagt. Elk daarvan laat een spoor achter in hetzelfde log dat u net hebt gelezen. De timer uitschakelen verbergt dat bewijs.

Wanneer het interval ergens anders op wijst

Twee buren in de configuratie produceren vergelijkbare symptomen en verschillende oplossingen. ping-restart herstart de tunnel wanneer er gedurende een ingestelde periode niets aankomt, terwijl ping-exit de client volledig neerhaalt. Een onderbreking bij inactiviteit zonder enige heronderhandeling in het log hoort bij deze, of bij een NAT-apparaat dat de UDP-mapping volgens zijn eigen schema liet verlopen.

Consumentenrouters, mobiele hotspots en carrier-grade NAT laten allemaal inactieve UDP-sessies verlopen zonder het iemand te vertellen. Die fout volgt inactiviteit en niet de klok, en dat is het teken: een sessie die na tien stille minuten wegvalt en een uur gelijkmatig verkeer overleeft, onderhandelt niet opnieuw.

Schrijf drie dingen op voordat u een vierde wijzigt: het interval dat u mat, de effectieve waarde die u vond en de opdracht die het toonde. Als het interval beweegt wanneer de timer beweegt, is het mechanisme geïdentificeerd en is de oplossing een beslissing over de ruil hierboven. Beweegt het niet, zet de instelling dan terug en blijf kijken naar keepalives, NAT-status en pakketverlies.