Conectarea unui controler mic la un VPN din NetworkManager

Un program mic care conectează un VPN existent are nevoie de un controler, nu de o implementare nouă de VPN. Motorul acceptat ar trebui să gestioneze negocierea și traficul tunelului; programul dumneavoastră ar trebui să exprime cererea utilizatorului și să explice rezultatul cu onestitate. În Linux, interfața D-Bus a NetworkManager oferă acelui controler un model concret de urmat.

Patru verificări împiedică controlerul să confunde un profil salvat, o cerere de activare și o sesiune funcțională.

Prima verificare: ce identitate este selectată

Păstrați UUID-ul profilului ca identitate persistentă și rezolvați-l prin manager când aveți nevoie de calea obiectului. Un nume afișat poate fi partajat de două profiluri, iar o cale de magistrală în timpul execuției nu este o preferință rezonabilă a utilizatorului de stocat. Scrieți selecția în propria configurație, nu într-un comentariu despre care intrare era a doua în listă.

Verificați ce returnează managerul înainte de a numi asta o potrivire. Un UUID care nu mai există produce o eroare de căutare, iar aceasta este o cale de cod diferită de un profil care există și refuză activarea.

A doua verificare: ce returnează apelul de activare

Apelul de activare documentat preia calea obiectului unei conexiuni existente, o cale de dispozitiv și un obiect specific. Returnează calea unei conexiuni active, iar acel răspuns este un mâner, nu un rezultat de pregătire. Nu setați indicatorul de pregătire al aplicației din valoarea returnată; abonați-vă în schimb la starea și motivul conexiunii active.

Pentru un VPN, obiectul specific selectează conexiunea de bază activă. Trecerea căii rădăcină lasă alegerea dispozitivului în seama NetworkManager, care îl alege pe cel care este implicit în acel moment. Este o decizie de context de rutare, nu un câmp de parolă, și schimbă pe ce dispozitiv este stratificat tunelul.

Nu luați un exemplu generic de adăugare și activare și nu vă așteptați să creeze un profil VPN. Ajutorul documentat exclude conexiunile VPN, așa că pregătirea sau importul profilului este un pas separat, revizuit. Asta contează pentru că pregătirea necesită autorizare și revizuire, pe care un buton de conectare nu le oferă. Tratați importul ca o acțiune administrativă cu propria linie de jurnal și propriul aprobator.

A treia verificare: cum este reprezentată starea

O conexiune activă trece prin activare, activă, dezactivare și dezactivată, iar câmpul de motiv spune de ce. Reducerea tuturor acestora la o valoare booleană numită loggedIn pierde informațiile de care are nevoie utilizatorul și pe care le va cere suportul. Afișați cel puțin dacă conexiunea este în așteptare, stabilită sau dispărută, și păstrați șirul de motiv pentru cazul de eșec.

Asociați răspunsurile asincrone cu cererea care le-a produs. O finalizare târzie a unei încercări mai vechi nu trebuie să suprascrie o acțiune mai nouă a utilizatorului, iar o apăsare dublă pe Connect ar trebui ignorată sau tratată ca anulare și reîncercare cu o politică vizibilă.

A patra verificare: ce se întâmplă după o repornire

Când managerul repornește sau controlerul dumneavoastră se reconectează la magistrală, reconstruiți starea observată de la proprietar. Nu continuați să afișați o sesiune din cache ca activă pentru că o cale veche de obiect este încă în memorie. Semnalele de schimbare a stării există exact pentru ca un controler să se resincronizeze în loc să ghicească.

Alegeți ce înseamnă închiderea controlerului. Lăsarea unei conexiuni existente deținute de mașină deschisă poate fi corectă, iar demolarea unei sesiuni intenționat de scurtă durată poate fi și ea corectă. Lăsarea unei conexiuni existente deținute de mașină deschisă poate fi corectă; demolarea unei sesiuni intenționat de scurtă durată poate fi și ea corectă. Scrieți acel contract de proprietate în interfață în loc să presupuneți că ieșirea procesului efectuează acțiunea de rețea. Utilizatorii nu ar trebui să ghicească dacă închiderea ferestrei le va întrerupe tunelul. Puneți răspunsul în textul interfeței, nu doar într-un comentariu de cod.

Păstrați autoritatea și secretele la proprietarii lor

Permisiunile se întorc ca da, auth sau nu, iar interfața ar trebui să reflecte diferența dintre permis, permis după autentificare și refuzat. Rularea controlerului ca root nu implementează o politică de permisiuni; elimină întrebarea.

Acreditările aparțin agentului de secrete acceptat sau integrării clientului pentru metoda de autentificare configurată. O parolă în codul sursă, într-un argument sau într-un jurnal este o constatare, iar autorizarea administrativă locală nu este același eveniment ca autentificarea la poartă.

În final, raportați starea conexiunii separat de sarcina pe care utilizatorul vrea să o îndeplinească. Un tunel poate fi activ în timp ce un nume privat sau o aplicație rămân indisponibile, iar acel al doilea eșec merită propriul mesaj și propriul status. Un controler care spune exact ce strat a eșuat este mai util decât unul care spune că VPN-ul este căzut.