OpenConnect vpnc-script: ce fișier rulează?

OpenConnect poate termina strângerea de mână a tunelului și totuși să vă lase fără rută către subrețeaua privată, pentru că clientul și ajutorul care modifică starea rețelei locale sunt două programe diferite. Autentificarea dovedește că poarta a acceptat sesiunea; nu dovedește nimic despre ce interfață, ce rute sau ce setări ale resolverului au fost instalate după aceea. Majoritatea rapoartelor confuze provin din înlocuirea ajutorului cu o copie dintr-un răspuns vechi, ceea ce schimbă comportamentul fiecărei conexiuni de pe mașină. Găsiți ajutorul pe care clientul în execuție îl apelează efectiv înainte de a modifica orice parte a acestuia.

Două programe, două responsabilități

Clientul deține transportul, autentificarea și dispozitivul tunelului. Un ajutor separat deține ceea ce se întâmplă în sistemul local odată ce tunelul există: adresarea pe interfață, rutele către subrețelele anunțate de poartă și configurația resolverului. documentația ajutorului OpenConnect descrie această separare și mediul pe care îl primește ajutorul. Distincția contează în timpul unei defecțiuni, pentru că o parolă respinsă și o rută lipsă nu sunt același incident chiar dacă desktopul afișează o singură casetă de dialog pentru amândouă.

Păstrarea acestei separări în minte explică și de ce o conexiune poate raporta succes în timp ce numele private încă nu se rezolvă. Tunelul este activ în ambele cazuri și doar etapa de integrare locală diferă.

Găsiți ajutorul folosit de clientul în execuție

Calea este stabilită la construirea pachetului și poate fi suprascrisă la fiecare apel, așa că fișierul pe care îl țineți minte dintr-o altă distribuție poate să nu aibă nimic de-a face cu această conexiune. Întrebați procesul în execuție, nu documentația care se întâmplă să fie deschisă.

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

Dacă linia procesului poartă un --script argument, acel fișier câștigă în fața valorii implicite compilate. Căi mai vechi precum /etc/vpnc/vpnc-script pot exista și totuși rămâne nefolosite, de aceea ștergerea sau editarea lor nu schimbă nimic într-o construcție recentă. Verificați și data modificării, pentru că un ajutor pe care nimeni nu l-a atins ani de zile este un semn puternic că valoarea implicită din pachet face treaba.

Integrarea cu NetworkManager este un al treilea proprietar, cu ajutor propriu și setări proprii de profil. Suprapunerea unui al doilea script de rute sau de resolver peste acea integrare dublează rutele și lasă un resolver pe care două programe susțin că îl administrează. Alegeți un singur proprietar pe conexiune și dezactivați-l pe celălalt înainte de testare.

Citiți prima operațiune eșuată, nu ultimul avertisment

Configurarea interfeței, instalarea rutelor, alegerea resolverului și curățarea stării vechi sunt pași separați, iar avertismentul tipărit ultimul este adesea o plângere despre curățare și nu defecțiunea care a rupt conexiunea. Citiți în sus până la prima operațiune concretă care a eșuat. O eroare a ajutorului care numește un fișier sau o adresă valorează mai mult decât zece linii de zgomot de demontare.

Comparați rezultatul local dorit cu cel observat: dispozitivul tunelului există, o rută către o adresă privată cunoscută trece prin el, iar resolverul răspunde pentru un nume privat. Un ajutor care reușește la primele două și eșuează la a treia indică politica resolverului și nu rutarea. Un ajutor care nu configurează deloc dispozitivul probabil nu a fost niciodată executat, iar aceasta este o chestiune de permisiuni, nu de rețea. Confirmați bitul executabil și contul de serviciu înainte de a rescrie orice logică.

Verificați conectarea, reconectarea și deconectarea

Configurarea este doar jumătate din contract, pentru că același ajutor trebuie să restaureze sau să elimine starea pe care o deține când tunelul se închide. Un ajutor care adaugă rute și nu le elimină niciodată lasă mașina cu o cale învechită care supraviețuiește sesiunii.

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

Rulați primele trei în timp ce sunteți conectat, deconectați-vă, apoi rulați-le din nou și confirmați că ruta și intrarea resolverului au dispărut. A patra linie arată dacă ajutorul a fost apelat măcar și ce cale executabilă a folosit serviciul. Păstrați acea pereche de ieșiri în tichet, pentru că tocmai comparația înainte și după face o eroare de curățare evidentă.

Țineți ajutorul împachetat și executabil pentru contul de serviciu, pentru că un script care rulează în shell-ul dumneavoastră poate fi totuși refuzat sub o politică de serviciu restricționată. Când personalizarea este cu adevărat necesară, documentați scopul și proprietarul și comparați-o cu versiunea împachetată la fiecare actualizare. Un fork neexplicat al unui ajutor este unul dintre puținele lucruri care pot face o conexiune funcțională să eșueze un an mai târziu.