OpenVPN-fall hver time: reforhandling eller en ekte gjentilkobling?

Seksti minutter, eller tretti, eller hundre og tjue: et fall som lander på et rundt intervall er nesten aldri nettet. OpenVPN fornyer nøkkelmaterialet som beskytter datakanalen på en timer, og en timer som er kortere enn den du antok ser nøyaktig ut som en linje som stadig feiler. Brukere rapporterer en brutt tilkobling mens loggen rapporterer en vellykket nøkkelutveksling. Veiledningen nedenfor skiller den fornyelsen fra en ekte omstart, leser verdien som faktisk gjelder, og endrer den først etter at kostnaden er på bordet.

Gjør trinnene i rekkefølge, fordi det første avgjør om resten av siden gjelder for deg i det hele tatt. Hopp fremover, og du bruker en kveld på å justere en timer for en feil som ikke har noe med den å gjøre.

Skill en myk reset fra en omstart

Logglinjen er hele diagnosen. En reforhandling skriver en myk reset og deretter en ny nøkkelutveksling i samme tunnel: grensesnittet beholder adressen, ruter legges ikke til på nytt, og etablerte TCP-økter overlever vanligvis med en pause. En ekte omstart river økten, bygger grensesnittet på nytt, gir kanskje en annen klientadresse og dreper hver langvarig tilkobling. Begge hendelsene er vanlige; bare én av dem forklarer en falt samtale.

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

Versjonslinjen er viktig fordi loggformuleringen endrer seg mellom utgivelser, og en melding du husker fra 2.3 kan være formulert annerledes i 2.6. Les din egen logg i stedet for et forumutdrag fra noen andre. Siter den nøyaktige linjen når du ber om hjelp, fordi en parafrase mister detaljen som identifiserer hendelsen. Hvis grensesnittadressen er uendret gjennom hendelsen og øktlisten overlever, ser du en fornyelse, og de resterende avsnittene gjelder.

Les den effektive timeren, ikke filen din

reneg-sec er antallet sekunder mellom reforhandlinger av datakanalen, og standardverdien er 3600. Hver side bærer sin egen verdi, og den minste av de to er det som faktisk utløser fornyelsen. Den ene regelen forklarer de fleste rapportene: en klientprofil som setter et stort tall, tilbakestilles likevel 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/

Les også serverens effektive konfigurasjon, inkludert alt den skyver, før du trekker en konklusjon fra klientfilen. Deretter øker du detaljnivået og følger ett intervall fra start til slutt: nivå 3 viser allerede reforhandlingslinjene, og tidsstemplene forteller om hendelsen gjentas hvert 3600 sekund eller følger aktivitet i stedet.

Endre det der det faktisk skyves

Det sirkulerende middelet er én linje i klientprofilen, og det er feil sted omtrent halvparten av tiden. Fordi den laveste sideverdien vinner, kan en klient som setter timeren til null fortsatt bli reforhandlet av en server som ikke ble endret.

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

Der profiler genereres sentralt, rediger malen i stedet for den utrullede kopien, ellers vil neste klargjøringskjøring gjenopprette verdien du nettopp fjernet. Verifiser ved å se to intervaller, ikke ett: én stille time er forenlig med en timer som ble satt til 7200.

Bestem også hva som skjer ved en blandet utrulling. Ruller du endringen ut til klienter først, blir det et vindu der serveren fortsatt utløser fornyelsen; det er harmløst, men forvirrende hvis du følger med på loggene for bekreftelse. Endre den siden som har den minste verdien først, og symptomet forsvinner på det punktet du forventer.

Hva du gir opp ved å slå av reforhandling

Regelmessig reforhandling begrenser hvor lenge ett sett med datakanalnøkler beskytter trafikken. Å slå av timeren bryter ikke tunnelen, og på en hjemmeruter eller en liten kontorgateway er den praktiske eksponeringen beskjeden. Det er likevel en handel, og handelen er verdt å nevne før du gjør den. Det som endres, er hvor lenge ett nøkkelsett beskytter en økt, ikke om tunnelen fungerer i det hele tatt.

Det rimelige tilfellet for å slå det av er en reset som bryter noe som ikke kan gjenopptas: en samtale som faller, en fjernskrivebordsøkt som må gjenopprettes, en sikkerhetskopi som starter på nytt. Hvis pausen er usynlig for brukerne, koster det ingenting å beholde standarden, og den bevarer nøkkelrotasjonen du fikk.

Foretrekk å rette årsaken når mønsteret tillater det. En fornyelse som feiler halvveis mens den første håndtrykket lyktes, peker på veien og ikke på timeren: se etter et pakkestørrelsesproblem i den større kontrollkanalutvekslingen, en tilstandsbasert brannmur som slipper strømmen, eller et forslag som bare lykkes på første forsøk. Hver av dem etterlater et spor i den samme loggen du nettopp leste. Å slå av timeren skjuler det beviset.

Når intervallet peker et annet sted

To naboer i konfigurasjonen gir lignende symptomer og ulike rettelser. ping-restart starter tunnelen på nytt når ingenting kommer på en konfigurert periode, mens ping-exit tar klienten helt ned. Et fall i ledig tilstand uten noen reforhandling i loggen hører til disse, eller til en NAT-enhet som lot UDP-mappingen utløpe etter sin egen tidsplan.

Forbrukerrutere, mobile hotspots og carrier-grade NAT lar alle ledige UDP-økter utløpe uten å si det til noen. Den feilen følger ledighet og ikke klokken, og det er tegnet: en økt som faller etter ti stille minutter og overlever en time med jevn trafikk, reforhandler ikke.

Skriv ned tre ting før du endrer en fjerde: intervallet du målte, den effektive verdien du fant, og kommandoen som viste den. Hvis intervallet flytter seg når timeren flytter seg, er mekanismen identifisert, og rettelsen er en beslutning om handelen ovenfor. Hvis det ikke flytter seg, sett innstillingen tilbake og fortsett å se på keepalives, NAT-tilstand og pakketap.