openconnect omorât: rutele și DNS-ul încă indică tunelul

Tunelul este oprit, dar mașina se comportă în continuare ca și cum ar fi pornit: o interogare atârnă până expiră, iar o rută indică o interfață care nu mai există. Aceasta este semnătura unui proces openconnect care a murit fără să-și ruleze asistentul de deconectare. Starea de rețea pe care a creat-o este încă instalată, și nimic altceva din sistem nu știe cum să o elimine.

Parcurgeți mașina în ordinea în care a fost creată starea: proces, legătură, rută, resolver. Fiecare pas vă spune dacă clientul chiar a plecat sau doar s-a detașat de terminal, iar această distincție decide dacă mai reparați ceva.

Începeți cu procesul, nu cu configurația

Deschideți un terminal și întrebați ce mai rulează înainte de a atinge o rută. pgrep -a openconnect listează fiecare instanță cu argumentele ei, ceea ce arată fișierul pid și scriptul care i-a fost dat. Un proces la care nu vă așteptați explică tunelul fantomă mai repede decât orice jurnal.

Dacă nu rulează nimic, priviți legătura. ip link show tun0 vă spune dacă interfața a supraviețuit, și ip route show dev tun0 listează rutele încă legate de ea. Apoi verificați resolverul cu resolvectl status. Notați toate cele trei ieșiri înainte de a le modifica, deoarece acea înregistrare este modul în care distingeți mai târziu o intrare învechită de una nouă.

O interfață care dispare își ia de obicei rutele cu ea. Rutele care supraviețuiesc legăturii înseamnă de obicei că procesul este încă viu sau că un al doilea client deține dispozitivul.

Scriptul auxiliar este cel care anulează modificările

openconnect nu elimină singur interfața, rutele sau intrările din resolver. Apelează un asistent extern, /etc/vpnc/vpnc-script într-un build upstream și /usr/share/vpnc-scripts/vpnc-script în pachetele Debian și Ubuntu, ales cu -s. Același script care ridică tunelul este cel care îl demontează.

Dacă procesul iese fără să apeleze acel asistent, starea rămâne. manualul OpenConnect spune explicit că rutarea și serviciul de nume nu vor funcționa corect fără script, și descrie asistentul ca fiind componenta care demontează starea interfeței la ieșire. De aceea contează calea atunci când porniți clientul cu -s.

Ce semnal ajunge pe acea cale s-a schimbat între versiuni. Manualul pentru 7.06 tratează SIGTERM ca o ieșire imediată care sare peste script. Build-urile actuale documentează INT și TERM ca o oprire curată, în care sesiunea este delogată și asistentul rulează. Citiți secțiunea SIGNALS a binarului pe care îl aveți de fapt, în loc să presupuneți oricare dintre cele două comportamente.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

Trimiteți semnalul pe care îl documentează build-ul dumneavoastră

Odată ce știți semnalul, opriți procesul după pid, nu după model.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

Apoi repetați cele trei verificări din prima secțiune în loc să vă bazați pe starea de ieșire. ip link show tun0 ar trebui să eșueze, ip route show dev tun0 nu ar trebui să afișeze nimic, și resolvectl status nu ar mai trebui să listeze legătura VPN.

SIGHUP nu este un buton de oprire: deconectează, rulează scriptul și lasă sesiunea reluabilă cu --cookie. SIGUSR2 forțează o reconectare imediată. SIGKILL sare complet peste curățare, și exact aceasta este starea despre care este acest articol.

Reparați resolverul fără a înlocui resolv.conf

Pe majoritatea sistemelor Ubuntu /etc/resolv.conf este o legătură simbolică către systemd-resolved, nu un fișier pe care ar trebui să îl editați. Înlocuirea ei strică rezolvarea numelor pentru fiecare rețea, nu doar pentru VPN. În schimb, eliminați înregistrarea tunelului:

resolvectl revert tun0
resolvectl query example.com

Dacă sistemul folosește resolvconf în loc de systemd-resolved, înregistrarea pe interfață persistă până când i se spune să dea drumul legăturii, și resolvconf -d tun0 este acțiunea echivalentă. Verificați ce resolver este folosit înainte de a alege comanda.

O interogare încă îndreptată către un server din spatele legăturii moarte atârnă până expiră, iar acea întârziere arată ca un server DNS stricat, nu ca o rută rămasă.

Faceți următoarea deconectare plictisitoare

Păstrați aceeași cale a fișierului pid la pornire și la oprire, transmițând --pid-file de fiecare dată, sau rulați openconnect sub o unitate al cărei KillSignal corespunde semnalului pe care îl documentează versiunea dvs. Testarea mai întâi în prim-plan vă arată mesajele de oprire pe care le afișează asistentul.

Conectați-vă, deconectați-vă și rulați cele trei verificări o dată. O ieșire curată nu lasă nicio legătură VPN, nicio rută VPN și nicio intrare de resolver VPN. Dacă una dintre cele trei supraviețuiește, acum știți care componentă nu a curățat. Următoarea investigație începe atunci de la acel răspuns, nu de la o interogare atârnată.