Ce supraviețuiesc de fapt persist-tun și persist-key în OpenVPN

Oprirea serviciului elimină interfața chiar și cu persist-tun setat. Aceasta este opțiunea care funcționează conform documentației, nu o defecțiune. Opțiunea descrie o singură cale de repornire într-un proces care rulează, iar systemctl stop nu este acea cale.

Citiți cele două nume împreună și designul devine clar. Unul păstrează un descriptor, celălalt păstrează material de cheie, și ambele există din cauza a ceea ce se întâmplă după renunțarea la privilegii.

Cele două resurse și repornirea căreia îi aparțin

OpenVPN semnalează propria repornire în două situații obișnuite. Un SIGUSR1 explicit face asta, iar un ping-restart declanșat de un partener mort face același lucru. Ambele lasă procesul viu și rulează din nou configurarea conexiunii, și acolo opțiunile își câștigă locul.

Doar rândul repornirii blânde este ceea ce schimbă aceste două opțiuni, iar munca pe care o sar este partea scumpă pe o legătură aglomerată. Redeschiderea unui dispozitiv dărâmă adresele și rutele atașate de el, iar reconstruirea lor poate scăpa pachete care erau în drum când a început repornirea. O oprire distruge aceleași obiecte fără nicio opțiune de a le păstra.

De ce există aceste opțiuni

Un server OpenVPN întărit pornește de obicei ca root, își deschide cheile și dispozitivul, apoi trece la un utilizator fără privilegii. După această trecere, unele operații pur și simplu dispar. Citirea unui fișier de cheie cu modul 0600, crearea unei interfețe de rețea sau schimbarea rutelor pot fi refuzate.

Fără opțiunile persist, un partener care tace suficient de mult pentru a declanșa ping-restart ar forța exact acele operații. Reconectarea ar eșua chiar dacă nimic din configurație nu s-ar fi schimbat. Procesul ar părea să moară fără motiv, iar jurnalul ar arăta o eroare de permisiuni în loc de o eroare de rețea.

Cu ele, repornirea blândă refolosește ceea ce faza privilegiată a obținut deja. Nu există magie și procesul nu supraviețuiește nimic. Obținerea resurselor este pur și simplu amânată.

Citiți prima eroare, nu pe ultima

Când o repornire eșuează, citiți prima eroare în locul ultimei. O cheie protejată, un fișier auth, un ioctl de interfață și un hook extern sunt patru resurse diferite. Păstrarea uneia nu spune nimic despre accesul la celelalte. Un hook care apelează un instrument de firewall are în continuare nevoie de privilegiile pe care le cere acel instrument.

Hook-urile au propriul comutator. Manualul OpenVPN asociază opțiunile persist cu up-restart, care decide dacă scripturile up și down rulează din nou după o repornire. O interfață rămasă sus nu vă spune așadar nimic despre faptul că integrarea resolverului a fost reîmprospătată.

# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'

# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0

Acea pereche de comenzi separă cele două moduri de eșec în câteva secunde. O interfață prezentă cu rute lipsă este o problemă de hook sau de rută. O interfață care a dispărut înseamnă că procesul s-a încheiat cu adevărat.

O interfață păstrată nu este un kill switch

Dacă cerința este ca traficul să nu părăsească niciodată tunelul, un dispozitiv păstrat nu oferă asta. Rutele pentru cealaltă familie de adrese, o a doua rută implicită și cazul în care procesul iese complet rămân toate în afara sferei opțiunii.

Tratați cele două cerințe separat. Păstrarea obiectului tunelului între reconectări este o comoditate pentru daemon. Blocarea ieșirii când tunelul este căzut este o politică de firewall cu propriile reguli și propriul test. Confundarea lor produce o configurație care pare defensivă și se comportă ca o reconectare cu efort maxim.

Numiți evenimentul înainte de a-l diagnostica. O repornire blândă, o încercare de conectare eșuată și o oprire a serviciului sunt trei evenimente cu trei comportamente, și doar primul este ceea ce descriu aceste opțiuni.