De ce clientul OpenVPN rămâne oprit după un singur timeout

Luni dimineață: tunelul care a urcat vinerea a dispărut, interfața este încă listată, iar în jurnal nu scrie nicăieri că cineva a observat. Gazda este online, panoul este verde, și tot ce a trimis peste weekend a ieșit prin interfața fizică. Aici lipsesc două decizii independente: una despre dacă procesul clientului supraviețuiește unei defecțiuni trecătoare și una despre dacă ceva deasupra lui repornește procesul după ce acesta iese. Repararea doar a uneia lasă cealaltă lacună deschisă.

Începeți de la ce a făcut de fapt unitatea, nu de la ce susține monitorizarea. systemctl status openvpn-client@office și journalctl -u openvpn-client@office -n 50 arată motivul ieșirii și ultima linie pe care clientul a scris-o înainte de a pleca.

Procesul a ieșit înainte ca cineva să observe

Un client care dispare fără eroare a ieșit de obicei intenționat. Profilul decide acest comportament, nu managerul de servicii: ping-exit încheie procesul imediat ce cealaltă parte nu mai răspunde, în timp ce ping-restart păstrează procesul și se reconectează în interiorul lui. Limitele de sesiune și temporizatoarele de inactivitate produc de afară aceeași imagine: fără tunel și fără alarmă.

Cele două directive ping nu pot apărea împreună într-un singur profil, așa că alegeți una și notați alegerea. Uitați-vă și la server, pentru că propriul său ping-exit închide o sesiune indiferent de ce a cerut clientul, iar doar jurnalul serverului notează cine a luat acea decizie.

Alegerea între ping-exit și ping-restart

Alegeți ping-restart pentru un laptop sau un sit îndepărtat care trebuie să se vindece singur, și păstrați ping-exit pentru cazurile în care un tunel mort trebuie să oprească procesul pentru ca altceva să poată acționa asupra lui. Numerele contează mai puțin decât relația: ping 10 cu ping-restart 60 înseamnă zece secunde de liniște înainte de o sondă și șaizeci înainte de repornire, ceea ce este agresiv pe un link mobil cu pierderi și rezonabil pe unul cu cablu. Scrieți motivul lângă linie, altfel următorul cititor va presupune că valorile implicite au fost intenționate.

Apoi confirmați că procesul este într-adevăr cel care a ieșit. O unitate care raportează activitate în timp ce tunelul este mort este o altă defecțiune, tratată mai jos.

Supraveghere care repornește cu adevărat unitatea

Pe o gazdă systemd, cea mai mică schimbare durabilă este un singur fișier drop-in: Restart=on-failure și RestartSec=10 în /etc/systemd/system/[email protected]/restart.conf. Un drop-in este citit doar când systemd își reîncarcă propriile definiții, așa că rulați systemctl daemon-reload după aceea. Verificați cu systemctl show -p Restart -p ExecMainStatus openvpn-client@office în loc să presupuneți că valoarea a ajuns. Instanța din numele fișierului trebuie să fie profilul pe care unitatea îl încarcă de fapt, așa că un fișier scris pentru office nu face nimic pentru openvpn-client@home.

on-failure ignoră un caz: o ieșire curată cu status zero. Unele căi de demontare se termină așa, așa că citiți statusul înregistrat în loc să aveți încredere în formularea unei pagini de manual. Dacă clientul dumneavoastră renunță cu un zero, aveți nevoie de Restart=always, iar prețul este că un profil cu adevărat stricat revine iar și iar până când limita de rată de pornire se activează și jurnalul se umple.

Restart=always se activează și după o oprire deliberată. Folosiți systemctl stop pentru mentenanță și mascați unitatea dacă trebuie să rămână oprită în timp ce lucrați.

Prindeți scurgerea cât timp tunelul este oprit

Supravegherea readuce tunelul; nu împiedică traficul să iasă cât timp tunelul lipsește. persist-tun păstrează dispozitivul și rutele sale între reconectări, ceea ce este convenabil și deschide o fereastră. Dispozitivul supraviețuiește, rutele încă indică spre el, iar pachetele se scurg afară neprotejate și nereportate. Este o alegere de politică, nu o valoare implicită neutră.

Când o gazdă nu are voie să emită deloc pachete neprotejate, doar firewall-ul poate garanta asta. O regulă de ieșire care permite interfața tunelului și adresa serverului VPN și aruncă tot restul rămâne valabilă după moartea clientului, iar nimic din configurația clientului însuși nu poate filtra traficul pe care clientul nu îl transportă.

Testați oprirea deliberată a clientului. Rulați systemctl stop openvpn-client@office, apoi curl -m 5 https://example.com, care ar trebui să eșueze în loc să reușească prin linkul fizic. Un succes înseamnă că regula firewall-ului lipsește sau este prea permisivă.

Reconectați, confirmați că tunelul transportă din nou trafic și abia apoi adăugați verificarea la monitorizare. Sondarea ip addr din cron pentru un dispozitiv tun este supravegherea care eșuează cel mai des, pentru că cu persist-tun dispozitivul supraviețuiește sesiunii, iar sonda raportează sănătate în timp ce nu se transportă nimic.