Šestdeset minut, ali trideset, ali sto dvajset: izpad, ki pade na okrogel interval, skoraj nikoli ni omrežje. OpenVPN po časovniku osvežuje ključni material, ki ščiti podatkovni kanal, in krajši časovnik od predvidenega je videti natanko kot povezava, ki nenehno odpoveduje. Uporabniki poročajo o pretrgani povezavi, medtem ko dnevnik poroča o uspešni izmenjavi ključev. Spodnji priročnik loči to osvežitev od resničnega ponovnega zagona, prebere vrednost, ki dejansko velja, in jo spremeni šele, ko je strošek na mizi.

Korake izvajajte po vrsti, ker prvi odloči, ali vas preostanek strani sploh zadeva. Če preskočite naprej, boste preživeli večer z nastavljanjem časovnika zaradi okvare, ki z njim nima nič skupnega.

Ločite mehko ponastavitev od ponovnega zagona

Vrstica v dnevniku je celotna diagnoza. Ponovno pogajanje zapiše mehko ponastavitev in nato novo izmenjavo ključev v istem tunelu: vmesnik ohrani naslov, poti se znova ne dodajo in vzpostavljene seje TCP običajno preživijo s premorom. Resnični ponovni zagon raztrga sejo, znova zgradi vmesnik, lahko dodeli drug naslov odjemalca in ubije vsako dolgotrajno povezavo. Oba dogodka sta običajna; le eden od njiju pojasni prekinjen klic.

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

Vrstica z različico je pomembna, ker se besedilo v dnevniku med izdajami spreminja, in sporočilo, ki se ga spomnite iz 2.3, je lahko v 2.6 drugače oblikovano. Berite svoj dnevnik, ne izvlečka s foruma nekoga drugega. Ko prosite za pomoč, citirajte točno vrstico, ker parafraza izgubi podrobnost, ki dogodek prepozna. Če se naslov vmesnika med dogodkom ne spremeni in seznam sej preživi, vidite osvežitev in preostali razdelki veljajo.

Berite veljavni časovnik, ne svoje datoteke

reneg-sec je število sekund med ponovnimi pogajanji podatkovnega kanala in njegova privzeta vrednost je 3600. Vsaka stran nosi svojo vrednost in prav manjša od obeh sproži osvežitev. To eno pravilo pojasni večino poročil: profil odjemalca, ki nastavi veliko število, se vseeno ponastavi vsako uro, dokler strežnik ohranja privzeto vrednost.

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

Preberite tudi veljavno konfiguracijo strežnika, vključno z vsem, kar potiska, preden sklepate iz odjemalčeve datoteke. Nato povečajte podrobnost in spremljajte en interval od začetka do konca: raven 3 že prikazuje vrstice ponovnega pogajanja, časovni žigi pa povedo, ali se dogodek ponavlja vsakih 3600 sekund ali sledi dejavnosti.

Spremenite ga tam, kjer se dejansko potiska

Zdravilo, ki kroži, je ena vrstica v profilu odjemalca in približno polovico časa je napačno mesto. Ker zmaga nižja vrednost strani, lahko odjemalca, ki časovnik nastavi na nič, še vedno znova pogaja strežnik, ki se ni spremenil.

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

Kjer se profili ustvarjajo centralno, uredite predlogo, ne nameščene kopije, sicer bo naslednji zagon oskrbovanja obnovil pravkar odstranjeno vrednost. Preverite z opazovanjem dveh intervalov, ne enega: ena tiha ura je skladna tudi s časovnikom, nastavljenim na 7200.

Odločite tudi, kaj se zgodi pri mešani uvedbi. Če spremembo najprej razširite na odjemalce, ostane okno, v katerem strežnik še sproža osvežitev; to je neškodljivo, a zmede, če zaradi potrditve spremljate dnevnike. Najprej spremenite stran z manjšo vrednostjo in simptom izgine na točki, ki jo pričakujete.

Čemu se odpoveste z izklopom ponovnega pogajanja

Redno ponovno pogajanje omejuje, kako dolgo en niz ključev podatkovnega kanala ščiti promet. Izklop časovnika ne pokvari tunela, na domačem usmerjevalniku ali prehodu male pisarne pa je praktična izpostavljenost skromna. Je še vedno menjava in menjavo velja imenovati, preden jo opravite. Spremeni se, kako dolgo en niz ključev ščiti sejo, ne pa, ali tunel sploh deluje.

Razumen primer za izklop je ponastavitev, ki pokvari nekaj, česar ni mogoče nadaljevati: klic, ki pade, seja oddaljenega namizja, ki jo je treba znova vzpostaviti, varnostna kopija, ki se začne znova. Če je premor za uporabnike neviden, ohranitev privzete vrednosti ne stane nič in vam ohrani rotacijo ključev.

Raje odpravite vzrok, ko vzorec to dopušča. Osvežitev, ki spodleti na pol poti, medtem ko je prvi rokovanje uspelo, kaže na pot, ne na časovnik: poiščite težavo z velikostjo paketa v večji izmenjavi krmilnega kanala, požarni zid s stanjem, ki spusti tok, ali predlog, ki uspe le v prvem poskusu. Vsak od njih pusti sled v istem dnevniku, ki ste ga pravkar prebrali. Izklop časovnika to dokazilo skrije.

Ko interval kaže drugam

Dva soseda v konfiguraciji dajeta podobne simptome in različne popravke. ping-restart znova zažene tunel, ko v nastavljenem obdobju nič ne prispe, medtem ko ping-exit odjemalca popolnoma spusti. Izpad v mirovanju brez kakršnega koli ponovnega pogajanja v dnevniku pripada tema ali napravi NAT, ki je pustila preslikavo UDP potekati po svojem urniku.

Potrošniški usmerjevalniki, mobilne dostopne točke in NAT na ravni operaterja pustijo nedejavne seje UDP potekati, ne da bi komu povedali. Ta okvara sledi nedejavnosti, ne uri, in to je znak: seja, ki pade po desetih tihih minutah in preživi uro enakomernega prometa, se ne pogaja znova.

Zapišite tri stvari, preden spremenite četrto: izmerjeni interval, najdeno veljavno vrednost in ukaz, ki jo je pokazal. Če se interval premakne, ko se premakne časovnik, je mehanizem prepoznan in popravek je odločitev o zgornji menjavi. Če se ne premakne, vrnite nastavitev in še naprej glejte keepalive, stanje NAT in izgubo paketov.

Sorodni članki