Uurlikse OpenVPN-onderbreking: heronderhandeling of 'n regte herverbinding?

Sestig minute, of dertig, of honderd en twintig: 'n onderbreking wat op 'n ronde interval val, is byna nooit die netwerk nie. OpenVPN vernuwe die sleutelmateriaal wat die datakanaal beskerm op 'n tydhouer, en 'n tydhouer korter as die een wat jy aangeneem het, lyk presies soos 'n skakel wat aanhoudend faal. Gebruikers rapporteer 'n gebreekte verbinding terwyl die log 'n suksesvolle sleutelruiling rapporteer. Die runbook hieronder skei daardie vernuwing van 'n werklike herbegin, lees die waarde wat werklik geld, en verander dit eers nadat die koste op tafel is.

Werk die stappe in volgorde, want die eerste een besluit of die res van die bladsy hoegenaamd op jou van toepassing is. Slaan vooruit en jy sal 'n aand spandeer om 'n tydhouer te stel vir 'n fout wat niks daarmee te doen het nie.

Onderskei 'n sagte herstel van 'n herbegin

Die logreel is die hele diagnose. 'n Heronderhandeling skryf 'n sagte herstel en dan 'n nuwe sleutelruiling binne dieselfde tonnel: die koppelvlak hou sy adres, roetes word nie weer bygevoeg nie, en gevestigde TCP-sessies oorleef gewoonlik met 'n pouse. 'n Werklike herbegin breek die sessie af, bou die koppelvlak weer op, gee dalk 'n ander kliëntadres uit, en maak elke langdurige verbinding dood. Albei gebeure is gewoon; net een van hulle verduidelik 'n onderbroke oproep.

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

Die weergawe-reël maak saak omdat logformulering tussen uitgawes verskuif, en 'n boodskap wat jy van 2.3 onthou, kan in 2.6 anders geformuleer wees. Lees jou eie log eerder as 'n forumuittreksel van iemand anders s'n. Haal die presiese reël aan wanneer jy om hulp vra, want 'n parafrase verloor die detail wat die gebeurtenis identifiseer. As die koppelvlakadres onveranderd is oor die gebeurtenis en die sesselys oorleef, kyk jy na 'n vernuwing en die oorblywende afdelings geld.

Lees die effektiewe tydhouer, nie jou lêer nie

reneg-sec is die aantal sekondes tussen heronderhandelinge van die datakanaal en die verstekwaarde is 3600. Elke portuur dra sy eie waarde, en die kleiner van die twee is wat die vernuwing werklik veroorsaak. Daardie enkele reël verduidelik die meeste van die verslae: 'n kliëntprofiel wat 'n groot getal stel, stel steeds uurliks terug terwyl die bediener die verstekwaarde hou.

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 die bediener se effektiewe konfigurasie, insluitend enigiets wat dit stoot, voordat jy 'n gevolgtrekking uit die kliëntlêer maak. Verhoog dan die breedsprakigheid en kyk een interval van begin tot einde: vlak 3 wys reeds die heronderhandelingsreëls, en die tydstempels sê of die gebeurtenis elke 3600 sekondes herhaal of eerder aktiwiteit volg.

Verander dit waar dit werklik gestoot word

Die rondgaande kuur is 'n enkele reël in die kliëntprofiel, en dit is omtrent die helfte van die tyd die verkeerde plek. Omdat die laer portuurwaarde wen, kan 'n kliënt wat die tydhouer op nul stel, steeds deur 'n bediener heronderhandel word wat nie verander het nie.

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

Waar profiele sentraal gegenereer word, wysig die sjabloon eerder as die ontplooide kopie, of die volgende voorsieningsloop sal die waarde herstel wat jy pas verwyder het. Verifieer deur twee intervalle te kyk, nie een nie: 'n enkele stil uur stem ooreen met 'n tydhouer wat op 7200 gestel is.

Besluit ook wat op 'n gemengde ontplooiing gebeur. Om die verandering eerste na kliënte uit te rol, laat 'n venster waarin die bediener steeds die vernuwing veroorsaak, wat onskadelik maar verwarrend is as jy die logs vir bevestiging dophou. Verander eerste die kant met die kleiner waarde, en die simptoom verdwyn op die punt wat jy verwag.

Wat jy prysgee deur heronderhandeling af te skakel

Gereelde heronderhandeling beperk hoe lank 'n enkele stel datakanaalsleutels verkeer beskerm. Om die tydhouer af te skakel, breek nie die tonnel nie, en op 'n tuisroeteerder of 'n klein kantoorpoort is die praktiese blootstelling beskeie. Dit is steeds 'n ruil, en die ruil is die moeite werd om te noem voordat jy dit maak. Wat verander, is hoe lank een sleutelstel 'n sessie beskerm, nie of die tonnel hoegenaamd werk nie.

Die redelike geval vir afskakeling is 'n herstel wat iets breek wat nie kan hervat nie: 'n oproep wat val, 'n afgeleë lessenaarsessie wat weer opgestel moet word, 'n rugsteun wat van die begin af herbegin. As die pouse onsigbaar vir gebruikers is, kos die verstekwaarde niks en behou jy die sleutelrotasie wat jy gekry het.

Verkies om die oorsaak reg te maak wanneer die patroon dit toelaat. 'n Vernuwing wat halfpad misluk terwyl die eerste handdruk geslaag het, wys na die pad eerder as die tydhouer: Soek na 'n pakkiegrootte-probleem in die groter beheerkanaalruiling, 'n stoopvolle vuurmuur wat die vloei laat val, of 'n voorstel wat net met die eerste poging slaag. Elkeen daarvan laat 'n spoor in dieselfde log wat jy pas gelees het. Om die tydhouer af te skakel, verberg daardie bewyse.

Wanneer die interval elders wys

Twee bure in die konfigurasie lewer soortgelyke simptome en verskillende regstellings. ping-restart herbegin die tonnel wanneer niks vir 'n bepaalde tydperk aankom nie, terwyl ping-exit die kliënt heeltemal afskakel. 'n Ledige onderbreking sonder enige heronderhandeling in die log hoort by hierdie dinge, of by 'n NAT-toestel wat die UDP-kaart op sy eie skedule laat verval het.

Verbruikersroeteerders, mobiele hotspotte en diensverskaffer-NAT laat almal ledige UDP-sessies verval sonder om iemand te sê. Daardie faling volg ledigheid eerder as die klok, en dit is die teken: 'n sessie wat ná tien stil minute val en 'n uur van bestendige verkeer oorleef, heronderhandel nie.

Skryf drie dinge neer voordat jy 'n vierde verander: die interval wat jy gemeet het, die effektiewe waarde wat jy gevind het, en die opdrag wat dit gewys het. As die interval beweeg wanneer die tydhouer beweeg, is die meganisme geïdentifiseer en die regstelling is 'n besluit oor die ruil hierbo. As dit nie beweeg nie, sit die instelling terug en hou aan kyk na keepalives, NAT-toestand en pakkieverlies.