DNS-ul OpenVPN rămâne după SIGKILL: verificați mai întâi proprietarul

DNS-ul nu mai rezolvă după ce un client OpenVPN este omorât, iar primul instinct este să rescrii /etc/resolv.conf. Acea modificare poate rupe un resolver funcțional în timp ce adevărata stare învechită se află în altă parte. Întrebarea de lămurit mai întâi este cine deține setările DNS instalate de tunel și dacă ieșirea care a sărit curățarea a contat cu adevărat.

Trei condiții decid reparația: semnalul care a încheiat procesul, componenta resolverului care a primit setările și dacă legătura tunelului mai există. Răspundeți în această ordine și corectarea vine de obicei fără să atingeți un fișier global.

Decideți ce tip de ieșire a avut loc

În ediția Community a OpenVPN, atât SIGINT cât și SIGTERM sunt cereri de ieșire ordonată. SIGKILL nu poate fi prins: nu poate fi blocat sau tratat, așa că nicio rutină de oprire nu are șansa să ruleze. Un Ctrl+C obișnuit într-un terminal în prim-plan generează SIGINT, în timp ce un supraveghetor care renunță să aștepte escaladează de obicei la SIGKILL. Diferența contează pentru că doar al doilea caz garantează că cârligele au fost sărite.

Rularea în screen sau tmux nu schimbă semnalul pe care îl trimite Ctrl+C. Verificați ce a primit de fapt procesul, nu ce face de obicei terminalul.

Când un serviciu sau un manager de conexiuni rulează tunelul, opriți acea singură conexiune prin proprietarul ei în loc să omorâți pid-ul. Un manager poate ridica din nou procesul, lăsându-vă cu un tunel nou și o stare confuză a resolverului. Un proces independent are nevoie doar de o cerere obișnuită de terminare pentru ca curățarea să ruleze.

Decideți cine deține resolverul

systemd-resolved, un script în stil resolvconf și o simplă rescriere de fișier sunt trei proprietari diferiți. Primul ține setările pe legătură în memorie și le aruncă atunci când interfața dispare. Al doilea ține înregistrări care persistă până când ceva le elimină. Al treilea scrie un fișier și lasă restaurarea în seama celui care l-a scris.

Identificați proprietarul înainte de a alege o comandă de reparare. Același simptom are trei răspunsuri corecte diferite, în funcție de care este folosit.

Un VPN administrat de NetworkManager poate deține deja modificările resolverului. Adăugarea unui al doilea ajutor deasupra creează doi proprietari care concurează pentru aceeași legătură, iar starea învinsului reapare la următoarea reconectare. Dacă un manager este responsabil, corectați setarea în manager, nu într-un script.

Ce poate și ce nu poate face cârligul down

Scriptul down rulează o dată după ce dispozitivul TUN/TAP a fost închis. Adăugarea down-pre inversează această ordine și rulează scriptul cât timp dispozitivul încă există, ceea ce cer ajutoarele care au nevoie de legătura activă.

Niciuna dintre directive nu face un cârlig să ruleze după SIGKILL. Privilegiile nu sunt nici ele restaurate de down-pre: dacă daemonul coboară la un user sau group sau intră într-un chroot, cârligul rulează cu accesul pe care acesta i-l lasă. Un cârlig apelat poate totuși eșua în actualizarea resolverului. Referința OpenVPN acoperă semnalele și ciclul de viață al apelului invers.

Verificați eroarea cârligului însuși lângă starea de ieșire a procesului. O curățare lipsă și o curățare eșuată arată la fel în resolver și diferit în jurnale.

Verificați starea care rămâne de fapt

Pe un sistem care folosește systemd-resolved, resolvectl status arată ce legătură mai poartă serverele DNS ale VPN-ului sau domeniile de rutare. Acea legătură poate aparține unei conexiuni dispărute sau altui tunel încă activ.

O interfață care dispare își ia configurația pe legătură cu ea, așa că un cârlig sărit poate coexista cu DNS curat. Dacă legătura este încă înregistrată și este deținută exclusiv de conexiunea oprită, managerul proprietar ar trebui să o elimine. Dacă un script mai vechi a rescris un fișier global al resolverului, căutați în schimb pasul de restaurare documentat al acelui script.

Recuperați fără a fura altă legătură

Când setările pe legătură sunt responsabilitatea dumneavoastră, resolvectl revert preia numele legăturii și șterge configurația DNS de execuție pentru acea interfață. Este o acțiune de execuție, nu o editare de profil, așa că configurația persistentă a conexiunii rămâne neatinsă. Numiți legătura greșită și ștergeți DNS-ul unui tunel funcțional, de aceea numele vine din ieșirea stării.

Confirmați că /etc/resolv.conf este o legătură simbolică administrată înainte de a o edita, apoi opriți clientul normal încă o dată și priviți din nou DNS-ul. Dacă a doua oprire curăță, problema anterioară era ieșirea forțată, nu configurația.