OpenVPN-fall kvar time: reforhandling eller ei ekte attilkopling?

Seksti minutt, eller tretti, eller hundre og tjue: eit fall som landar på eit rundt intervall er nesten aldri nettet. OpenVPN fornyar nøkkelmaterialet som vernar datakanalen på ein timer, og ein timer som er kortare enn den du antok ser nøyaktig ut som ei linje som stadig feilar. Brukarar rapporterer ei broten tilkopling medan loggen rapporterer ein vellukka nøkkelutveksling. Rettleiinga nedanfor skil den fornyinga frå ein ekte omstart, les verdien som faktisk gjeld, og endrar han først etter at kostnaden er på bordet.

Gjer trinna i rekkjefølgje, fordi det første avgjer om resten av sida gjeld for deg i det heile. Hoppar du framover, brukar du ein kveld på å justere ein timer for ein feil som ikkje har noko med han å gjere.

Skil ein mjuk reset frå ein omstart

Logglina er heile diagnosen. Ei reforhandling skriv ein mjuk reset og deretter ein ny nøkkelutveksling i same tunnelen: grensesnittet held på adressa si, ruter blir ikkje lagde til på nytt, og etablerte TCP-økter overlever vanlegvis med ei pause. Ein ekte omstart riv økta, byggjer grensesnittet på nytt, gir kanskje ei anna klientadresse og drep kvar langvarig tilkopling. Begge hendingane er vanlege; berre éin av dei forklarar ein fallen samtale.

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

Versjonslina er viktig fordi loggformuleringa endrar seg mellom utgjevingar, og ei melding du hugsar frå 2.3 kan vere formulert annleis i 2.6. Les din eigen logg i staden for eit forumutdrag frå nokon andre. Siter den nøyaktige lina når du ber om hjelp, fordi ein parafrase mistar detaljen som identifiserer hendinga. Viss grensesnittadressa er uendra gjennom hendinga og øktlista overlever, ser du ei fornying, og dei resterande avsnitta gjeld.

Les den effektive timeren, ikkje fila di

reneg-sec er talet på sekund mellom reforhandlingar av datakanalen, og standardverdien er 3600. Kvar side ber sin eigen verdi, og den minste av dei to er det som faktisk utløyser fornyinga. Den eine regelen forklarar dei fleste rapportane: ein klientprofil som set eit stort tal, blir likevel nullstilt kvar time medan serveren held på standarden.

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

Les også den effektive konfigurasjonen til serveren, inkludert alt han skyv, før du dreg ein konklusjon frå klientfila. Aukar du så detaljnivået og følgjer eitt intervall frå start til slutt: nivå 3 viser allereie reforhandlingslinjene, og tidsstempla fortel om hendinga blir gjenteken kvart 3600 sekund eller følgjer aktivitet i staden.

Endre det der det faktisk blir skyvd

Det rundgangne middelet er éi line i klientprofilen, og det er feil stad om lag halvparten av tida. Fordi den lågaste sideverdien vinn, kan ein klient som set timeren til null framleis bli reforhandla av ein server som ikkje vart endra.

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

Der profilar blir genererte sentralt, rediger malen i staden for den utrulla kopien, elles vil neste klargjeringskøyring gjenopprette verdien du nettopp fjerna. Stadfest ved å sjå to intervall, ikkje eitt: ein roleg time er også i samsvar med ein timer sett til 7200.

Avgjer også kva som skjer ved ein blanda utrulling. Rullar du endringa ut til klientar først, blir det eit vindauge der serveren framleis utløyser fornyinga; det er harmslaust, men forvirrande viss du følgjer med på loggane for stadfesting. Endre den sida som har den minste verdien først, og symptomet forsvinn på det punktet du ventar.

Kva du gir opp ved å slå av reforhandling

Regelmessig reforhandling avgrensar kor lenge eitt sett med datakanalnøklar vernar trafikken. Å slå av timeren bryt ikkje tunnelen, og på ein heimeruter eller ein liten kontorgateway er den praktiske eksponeringa rimeleg. Det er likevel ein handel, og handelen er verdt å nemne før du gjer han. Det som endrar seg, er kor lenge eitt nøkkelsett vernar ei økt, ikkje om tunnelen fungerer i det heile.

Det rimelege tilfellet for å slå det av er ein reset som bryt noko som ikkje kan takast opp att: ein samtale som fell, ei fjernskrivebordsøkt som må gjenopprettast, ein tryggleikskopi som startar på nytt. Viss pausa er usynleg for brukarane, kostar det ingenting å behalde standarden, og han bevarar nøkkelrotasjonen du fekk.

Føretrekk å rette årsaka når mønsteret tillèt det. Ei fornying som feilar halvvegs medan den første handtrykkinga lukkast, peikar på vegen og ikkje på timeren: sjå etter eit pakkestorleiksproblem i den større kontrollkanalutvekslinga, ein tilstandsbasert brannmur som slepp straumen, eller eit framlegg som berre lukkast på første forsøk. Kvar av dei etterlèt eit spor i den same loggen du nettopp las. Å slå av timeren gøymer det beviset.

Når intervallet peikar ein annan stad

To naboar i konfigurasjonen gir liknande symptom og ulike rettingar. ping-restart startar tunnelen på nytt når ingenting kjem på ein konfigurert periode, medan ping-exit tek klienten heilt ned. Eit fall i ledig tilstand utan noka reforhandling i loggen høyrer til desse, eller til eit NAT-apparat som lét UDP-mappinga gå ut etter sin eigen timeplan.

Forbrukarrutarar, mobile hotspot og carrier-grade NAT lèt alle ledige UDP-økter gå ut utan å seie det til nokon. Den feilen følgjer ledigheit og ikkje klokka, og det er teiknet: ei økt som fell etter ti stille minutt og overlever ein time med jamn trafikk, reforhandlar ikkje.

Skriv ned tre ting før du endrar ein fjerde: intervallet du målte, den effektive verdien du fann, og kommandoen som viste han. Viss intervallet flyttar seg når timeren flyttar seg, er mekanismen identifisert, og rettinga er ei avgjerd om handelen ovanfor. Viss det ikkje flyttar seg, set innstillinga tilbake og hald fram med å sjå på keepalives, NAT-tilstand og pakketap.