OpenVPN 3 Linux: citește o eroare D-Bus înainte de a reveni

Defecțiunile din OpenVPN 3 Linux sosesc ca o eroare de metodă D-Bus cu un nume necunoscut atașat, iar tentația este să retrogradezi un pachet și să speri. Clientul nu este un singur program: o interfață din linia de comandă vorbește pe magistrală cu servicii care dețin profilurile, sesiunile, motorul VPN și modificările de rețea privilegiate. Să decizi care dintre acele cinci deține apelul care eșuează este cea mai mare parte a diagnosticului și costă o comandă în locul unei reveniri. Ce urmează este acea decizie, în ordinea în care defecțiunile apar de obicei.

Cinci proprietari în spatele unei comenzi

Cinci procese contează, și fiecare are propriul nume pe magistrală: interfața care îți acceptă comanda, managerul de configurație care stochează profilurile și politica lor de acces, managerul de sesiuni care deține durata de viață a sesiunilor, backendul care rulează conexiunea prin OpenVPN 3 Core Engine și serviciul de configurare a rețelei care instalează interfața, rutele și setările DNS. O eroare care numește un obiect de configurație nu este așadar o eroare a backendului, iar un backend care nu pornește nu este o eroare de autentificare. Încadrarea mesajului într-unul dintre acele rânduri trebuie să se întâmple înainte de a schimba ceva, pentru că fiecare pas ulterior depinde de rândul care este adevărat. Să ghicești rândul este felul în care o corecție scurtă devine o după-amiază de lucru cu pachete.

Întreabă magistrala de sistem ce servicii sunt prezente înainte de a întreba orice altceva, apoi confirmă că piesele instalate sunt de acord asupra unei versiuni. OpenVPN 3 Linux înregistrează acele servicii ca unități de sistem, deci magistrala de interogat este cea de sistem, interogarea versiunii are nevoie de autoritate administrativă, iar o listare făcută cu --user citește sesiunea ta de autentificare, unde unitățile nu apar niciodată. Serviciile se activează la cerere și unele se închid când sunt inactive, deci un serviciu care lipsește înainte de prima ta cerere pur și simplu nu a fost încă întrebat nimic. Cele trei comenzi de mai jos răspund despre prezență, versiune și starea unităților fără a deschide o sesiune VPN.

sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'

Ce dovedește de fapt fiecare listă

Vederile proprii ale clientului sunt cea mai ieftină dovadă disponibilă, și fiecare dintre ele dovedește mai puțin decât pare. Un profil din lista de configurație arată că un profil este importat și nimic despre dacă cineva se poate conecta cu el. O sesiune din lista de sesiuni arată că există un obiect de sesiune și nimic despre dacă autentificarea la distanță s-a terminat.

openvpn3 configs-list
openvpn3 sessions-list

Căile de obiect din acele ieșiri identifică obiecte administrate de pe magistrală, nu fișiere, deci nu pot fi editate, iar o cale notată mai devreme devine învechită în momentul în care acea sesiune se deconectează. Reutilizarea uneia din notițele tale produce erori "no such object" care nu au nimic de-a face cu VPN-ul. Tabelul de etape de mai jos separă ce stabilește fiecare pas al unei conexiuni de ce lasă deschis, iar aceasta este exact distincția de care depinde o decizie de revenire. Citește rândul care corespunde dovezii tale, apoi citește din nou textul erorii.

Apelul de conectare se întoarce înainte ca tunelul să existe

Apelul de conectare îți dă o sesiune de urmărit și se întoarce, motiv pentru care un apel aparent reușit urmat de tăcere este o stare intermediară normală, nu o contradicție. Interfața trebuie în continuare să urmărească schimbările de stare și să răspundă oricărei cereri de interacțiune. Un profil care are nevoie de o acreditare și nu primește niciun răspuns așteaptă într-o stare care arată exact ca un backend blocat. Acea stare de așteptare merită recunoscută, pentru că trimite oamenii la componenta greșită.

Cât timp o încercare rulează, urmărește lista de sesiuni și jurnalul propriu al interfeței pentru acel profil. O sesiune care nu părăsește niciodată starea inițială numește componenta care s-a oprit, iar jurnalul o numește de obicei în primele rânduri. Ține numele profilului la îndemână, fiindcă comanda de jurnal ia un profil, nu o cale de sesiune, ceea ce este încă un motiv să recitești lista în loc să reutilizezi o cale.

openvpn3 sessions-list
openvpn3 log --config <profile> --level 6

Citirea jurnalului unei singure componente fără a deschide o sesiune

Când interfața nu raportează nimic util, mergi la componenta care a înregistrat defecțiunea în loc să pornești o altă conexiune. Cu un logger systemd-journald configurat, vederea de jurnal delimitată a administratorului citește evenimentele unei componente fără a atinge politica magistralei sau a deschide o sesiune, ceea ce contează pentru că un diagnostic care schimbă sistemul pe care îl măsoară dovedește foarte puțin. Filtrează după unitate, nu după etichetă syslog: unitățile de serviciu individuale nu garantează un identificator comun, deci o interogare după etichetă poate returna o pagină goală în timp ce unitatea însăși a înregistrat defecțiunea.

Notează patru câmpuri înainte de a cere ajutor cuiva: numele complet al erorii, serviciul și obiectul implicate, marca temporală și versiunile pachetelor instalate. Acestea sunt ce are nevoie un maintainer, și niciuna dintre ele nu cere să lipești un profil sau o acreditare într-un tichet. Lărgirea politicii de acces la magistrală pentru a reduce eroarea la tăcere nu este un diagnostic, șterge granița care numea componenta pentru tine. Conținutul privat al profilurilor rămâne în afara rapoartelor partajate din același motiv ca acreditările.

journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>

Corectarea graniței care a refuzat

Fiecare rând al hărții are propria corecție, iar rândurile nu se substituie unul altuia. O operațiune refuzată pe un profil este o întrebare despre politică și proprietate, în timp ce un backend care nu se activează este o întrebare despre servicii și împachetare. Un server care respinge autentificarea nu este niciuna dintre ele, deci schimbările repetate de parolă nu pot repara o problemă locală de activare. Alegerea corecției greșite este felul în care o problemă de politică devine o reinstalare.

După o schimbare de pachete, verifică o instalare coerentă și suportată în loc să copiezi un binar vechi la locul lui. O revenire controlată este un răspuns legitim la o regresie confirmată, cu condiția ca pachetele să rămână compatibile și să existe o cale de întoarcere la întreținerea suportată. Stabilește acea cale înainte ca serviciul să nu mai pornească, nu după.

O altă platformă poate împărți aceeași bibliotecă VPN de bază fără a împărți serviciile de magistrală ale Linux, deci o defecțiune asemănătoare pe Windows nu spune nimic despre aceasta. Prezentarea generală D-Bus documentează căile de obiect expuse pentru configurații și sesiuni, iar aceasta este partea de arhitectură de care depinde acest diagnostic. Citește-o o dată, și următoarea eroare va sosi cu o componentă deja atașată.