OpenVPN-drop hver time: renegociering eller en rigtig genopkobling?

Tres minutter, eller tredive, eller hundrede og tyve: et drop, der lander på et rundt interval, er næsten aldrig netværket. OpenVPN fornyer det nøglemateriale, der beskytter datakanalen, på en timer, og en timer, der er kortere end den, du antog, ser præcis ud som et link, der hele tiden fejler. Brugere rapporterer en brudt forbindelse, mens loggen rapporterer en vellykket nøgleudveksling. Vejledningen nedenfor adskiller den fornyelse fra en egentlig genstart, læser den værdi, der faktisk gælder, og ændrer den først, efter at prisen er på bordet.

Udfør trinnene i rækkefølge, fordi det første afgør, om resten af siden overhovedet gælder for dig. Spring frem, og du vil bruge en aften på at tune en timer for en fejl, der ikke har noget med den at gøre.

Skeln et blødt reset fra en genstart

Loglinjen er hele diagnosen. En renegociering skriver et blødt reset og derefter en ny nøgleudveksling inde i den samme tunnel: grænsefladen beholder sin adresse, ruter tilføjes ikke igen, og etablerede TCP-sessioner overlever normalt med en pause. En rigtig genstart river sessionen ned, genopbygger grænsefladen, udleverer måske en anden klientadresse og dræber enhver langvarig forbindelse. Begge hændelser er almindelige; kun én af dem forklarer et afbrudt opkald.

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

Versionslinjen er vigtig, fordi logformuleringen flytter sig mellem udgivelser, og en besked, du husker fra 2.3, kan være formuleret anderledes i 2.6. Læs din egen log i stedet for et forumuddrag fra en anden. Citér den præcise linje, når du beder om hjælp, fordi en parafrase mister den detalje, der identificerer hændelsen. Hvis grænsefladens adresse er uændret gennem hændelsen, og sessionslisten overlever, ser du en fornyelse, og de resterende afsnit gælder.

Læs den effektive timer, ikke din fil

reneg-sec er antallet af sekunder mellem renegocieringer af datakanalen, og standardværdien er 3600. Hver peer bærer sin egen værdi, og den mindste af de to er det, der faktisk udløser fornyelsen. Den ene regel forklarer de fleste rapporter: en klientprofil, der sætter et stort tal, nulstilles stadig hver time, mens serveren beholder 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/

Læs også serverens effektive konfiguration, inklusive alt hvad den skubber, før du drager en konklusion ud fra klientfilen. Hæv derefter detaljeringsgraden og følg et interval fra start til slut: niveau 3 viser allerede renegocieringslinjerne, og tidsstemplerne fortæller, om hændelsen gentages hvert 3600 sekund, eller følger aktivitet i stedet.

Ændr det, hvor det faktisk skubbes

Det cirkulerende middel er én linje i klientprofilen, og det er det forkerte sted cirka halvdelen af tiden. Fordi den lavere peerværdi vinder, kan en klient, der sætter timeren til nul, stadig renegocieres af en server, der ikke blev ændret.

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

Hvor profiler genereres centralt, rediger skabelonen i stedet for den udrullede kopi, ellers vil den næste provisioning-kørsel gendanne den værdi, du netop fjernede. Verificér ved at se to intervaller, ikke ét: en enkelt stille time er forenelig med en timer, der blev sat til 7200.

Beslut også, hvad der sker ved en blandet udrulning. Ruller du ændringen ud til klienter først, efterlades et vindue, hvor serveren stadig udløser fornyelsen, hvilket er harmløst men forvirrende, hvis du holder øje med loggene for bekræftelse. Ændr den side, der har den mindste værdi, først, og symptomet forsvinder på det punkt, du forventer.

Hvad du giver afkald på ved at slå renegociering fra

Regelmæssig renegociering begrænser, hvor længe et enkelt sæt datakanalnøgler beskytter trafik. At slå timeren fra ødelægger ikke tunnelen, og på en hjemmerouter eller en lille kontorgateway er den praktiske eksponering beskeden. Det er stadig en handel, og handlen er værd at nævne, før du gør den. Det, der ændres, er, hvor længe et nøglesæt beskytter en session, ikke om tunnelen virker overhovedet.

Det rimelige tilfælde for at slå det fra er et reset, der ødelægger noget, som ikke kan genoptages: et opkald, der falder, en fjernskrivebordssession, der skal genoprettes, en backup, der starter forfra. Hvis pausen er usynlig for brugerne, koster standarden intet og bevarer den nøglerotation, du fik.

Foretræk at rette årsagen, når mønsteret tillader det. En fornyelse, der fejler halvvejs, mens det første håndtryk lykkedes, peger på vejen snarere end timeren: se efter et pakkestørrelsesproblem i den større kontrolkanaludveksling, en stateful firewall, der dropper flowet, eller et forslag, der kun lykkes i første forsøg. Hver af disse efterlader et spor i den samme log, du netop læste. At slå timeren fra skjuler det bevis.

Når intervallet peger et andet sted hen

To naboer i konfigurationen giver lignende symptomer og forskellige rettelser. ping-restart genstarter tunnelen, når der ikke ankommer noget i en konfigureret periode, mens ping-exit tager klienten helt ned. Et ledigt drop uden nogen renegociering i loggen hører til disse eller til en NAT-enhed, der lod UDP-mappingen udløbe efter sin egen tidsplan.

Forbrugerroutere, mobile hotspots og carrier-grade NAT lader alle ledige UDP-sessioner udløbe uden at fortælle nogen det. Den fejl følger lediggang snarere end uret, og det er tegnet: en session, der dropper efter ti stille minutter og overlever en time med jævn trafik, renegocierer ikke.

Skriv tre ting ned, før du ændrer en fjerde: det interval, du målte, den effektive værdi, du fandt, og den kommando, der viste den. Hvis intervallet flytter sig, når timeren flytter sig, er mekanismen identificeret, og rettelsen er en beslutning om handlen ovenfor. Hvis det ikke flytter sig, sæt indstillingen tilbage og bliv ved med at kigge på keepalives, NAT-tilstand og pakketab.