Cădere orară a OpenVPN: renegociere sau o reconectare reală?

Șaizeci de minute, sau treizeci, sau o sută douăzeci: o cădere care cade pe un interval rotund aproape niciodată nu este rețeaua. OpenVPN reînnoiește după un cronometru materialul de chei care protejează canalul de date, iar un cronometru mai scurt decât cel presupus arată exact ca o legătură care eșuează continuu. Utilizatorii raportează o conexiune ruptă în timp ce jurnalul raportează un schimb de chei reușit. Ghidul de mai jos separă acea reînnoire de o repornire reală, citește valoarea efectiv în vigoare și o schimbă abia după ce costul este pe masă.

Urmați pașii în ordine, pentru că primul decide dacă restul paginii vi se aplică deloc. Dacă săriți înainte, veți petrece o seară reglând un cronometru pentru o defecțiune care nu are nimic de-a face cu el.

Distingeți o resetare blândă de o repornire

Linia de jurnal este întregul diagnostic. O renegociere scrie o resetare blândă și apoi un schimb de chei nou în același tunel: interfața își păstrează adresa, rutele nu sunt adăugate din nou, iar sesiunile TCP stabilite supraviețuiesc de obicei cu o pauză. O repornire reală rupe sesiunea, reconstruiește interfața, poate atribui o altă adresă de client și ucide fiecare conexiune de lungă durată. Ambele evenimente sunt obișnuite; doar unul explică un apel întrerupt.

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

Linia de versiune contează pentru că formularea jurnalului se schimbă între versiuni, iar un mesaj pe care îl țineți minte din 2.3 poate fi formulat altfel în 2.6. Citiți propriul jurnal, nu un extras de forum al altcuiva. Citați linia exactă când cereți ajutor, pentru că o parafrază pierde detaliul care identifică evenimentul. Dacă adresa interfeței rămâne neschimbată pe durata evenimentului și lista de sesiuni supraviețuiește, vedeți o reînnoire, iar secțiunile rămase se aplică.

Citiți cronometrul efectiv, nu fișierul dumneavoastră

reneg-sec este numărul de secunde dintre renegocierile canalului de date, iar valoarea implicită este 3600. Fiecare parte poartă propria valoare, iar cea mai mică dintre cele două este cea care declanșează efectiv reînnoirea. Acea singură regulă explică majoritatea raportărilor: un profil de client care stabilește un număr mare este totuși resetat la fiecare oră cât timp serverul păstrează valoarea implicită.

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

Citiți și configurația efectivă a serverului, inclusiv tot ce împinge, înainte de a trage o concluzie din fișierul clientului. Apoi creșteți nivelul de detaliu și urmăriți un interval de la început la sfârșit: nivelul 3 arată deja liniile de renegociere, iar marcajele de timp spun dacă evenimentul se repetă la fiecare 3600 de secunde sau urmează activitatea.

Schimbați-o acolo unde este într-adevăr împinsă

Remediul care circulă este o singură linie în profilul clientului, și este locul greșit aproximativ jumătate din timp. Deoarece câștigă valoarea mai mică a părții, un client care pune cronometrul la zero poate fi totuși renegociat de un server care nu s-a schimbat.

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

Acolo unde profilurile sunt generate central, editați șablonul, nu copia implementată, altfel următoarea rulare de provizionare va restabili valoarea pe care tocmai ați eliminat-o. Verificați observând două intervale, nu unul: o oră liniștită este compatibilă și cu un cronometru setat la 7200.

Decideți și ce se întâmplă la o implementare mixtă. Dacă rulați schimbarea mai întâi la clienți, rămâne o fereastră în care serverul încă declanșează reînnoirea; este inofensiv, dar derutant dacă urmăriți jurnalele pentru confirmare. Schimbați mai întâi partea cu valoarea mai mică și simptomul dispare în punctul în care vă așteptați.

La ce renunțați dezactivând renegocierea

Renegocierea regulată limitează cât timp un singur set de chei ale canalului de date protejează traficul. Oprirea cronometrului nu rupe tunelul, iar pe un router de acasă sau pe o poartă de birou mic expunerea practică este modestă. Este totuși un schimb, iar schimbul merită enunțat înainte de a-l face. Ce se schimbă este cât timp un set de chei protejează o sesiune, nu dacă tunelul funcționează deloc.

Cazul rezonabil pentru dezactivare este o resetare care rupe ceva ce nu poate fi reluat: un apel care cade, o sesiune de desktop la distanță care trebuie restabilită, o copie de siguranță care reîncepe de la început. Dacă pauza este invizibilă pentru utilizatori, păstrarea valorii implicite nu costă nimic și vă păstrează rotația cheilor.

Preferați să remediați cauza când tiparul permite. O reînnoire care eșuează la jumătatea drumului în timp ce primul strângere de mână a reușit indică traseul, nu cronometrul: căutați o problemă de dimensiune a pachetului în schimbul mai mare al canalului de control, un firewall cu stare care aruncă fluxul sau o propunere care reușește doar la prima încercare. Fiecare dintre ele lasă o urmă în același jurnal pe care tocmai l-ați citit. Dezactivarea cronometrului ascunde acea dovadă.

Când intervalul indică altundeva

Doi vecini din configurație produc simptome similare și remedii diferite. ping-restart repornește tunelul când nimic nu sosește pentru o perioadă configurată, în timp ce ping-exit coboară complet clientul. O cădere în inactivitate fără nicio renegociere în jurnal aparține acestora sau unui dispozitiv NAT care a lăsat maparea UDP să expire după propriul program.

Routerele de consum, hotspoturile mobile și NAT-ul de nivel operator lasă toate sesiunile UDP inactive să expire fără să spună nimănui. Acea defecțiune urmează inactivitatea, nu ceasul, și acesta este indiciul: o sesiune care cade după zece minute liniștite și supraviețuiește o oră de trafic constant nu renegociază.

Notați trei lucruri înainte de a schimba un al patrulea: intervalul măsurat, valoarea efectivă găsită și comanda care a arătat-o. Dacă intervalul se mișcă atunci când se mișcă cronometrul, mecanismul este identificat, iar remediul este o decizie despre schimbul de mai sus. Dacă nu se mișcă, puneți setarea la loc și continuați să urmăriți keepalive, starea NAT și pierderea de pachete.