Portabilitatea profilului OpenVPN: chei portabile versus opțiuni de platformă

Același fișier .ovpn deschide un tunel într-un client și nu pornește în altul, iar certificatul este de obicei primul suspect. Mai des fișierul conține o directivă pe care o implementează un singur motor. Un profil este un contract cu un anumit client, nu un script portabil.

Separați ce călătorește cu identitatea de ce aparține unei platforme. Atunci defecțiunea se numește de obicei singură.

Un fișier, două contracte

Un profil grupează trei tipuri de conținut: material de identitate precum certificatele CA și de client și cheia privată, fapte de transport precum punctul final îndepărtat și protocolul, și directive de comportament precum tratarea DNS sau opțiunile de dispozitiv. Primele două sunt larg portabile între motoarele care acceptă același protocol. Al treilea este locul unde implementările se despart. Tratarea întregului fișier ca o singură unitate portabilă este ceea ce produce defecțiunile confuze.

Un fișier care funcționează într-o GUI pe o platformă nu este automat valabil pentru clientul din linia de comandă de pe alta. Chiar și când ambele sunt OpenVPN, analizatoarele și seturile de opțiuni diferă. De aceea o importare reușită nu este dovada unui profil portabil.

Material portabil versus directive de platformă

Secțiunile de identitate și transport sunt partea de păstrat. ca, cert, key și remote descriu cine se conectează și încotro, și înseamnă același lucru pentru orice client conform.

Directivele de comportament sunt partea de comparat. block-outside-dns, de exemplu, există pentru a schimba comportamentul DNS în Windows. Este posibil ca un client Unix să nu o recunoască deloc.

Citiți lista de opțiuni a clientului receptor, nu a celui emitent. Manualul de referință OpenVPN 2.6 documentează opțiunile motorului, iar dialogul de import al unei GUI nu este acea listă.

Citiți eroarea analizatorului înaintea certificatului

O eroare care numește o opțiune nerecunoscută este o defecțiune a analizatorului, nu una a autentificării. Conexiunea nu a ajuns niciodată la TLS, așa că schimbarea certificatelor nu poate ajuta. Citiți prima eroare din clientul și versiunea reale, apoi eliminați sau înlocuiți doar directiva pe care acel client nu o poate implementa. Ștergerea secțiunilor de certificat sau de rute pentru ca fișierul să se încarce este felul în care un profil funcțional devine nesigur.

Dacă eroarea menționează strângerea de mână, un certificat sau un cifru, profilul a fost analizat și problema este în altă parte.

Păstrați fișierul original lângă cel adaptat. Când fișierul adaptat eșuează mai târziu, originalul este controlul care spune dacă s-a mișcat modificarea sau mediul.

Privilegiile sunt o a doua frontieră

Privilegiile sunt cealaltă frontieră: crearea unui dispozitiv de tunel, instalarea rutelor și citirea unei chei private depind toate de permisiuni locale. Un fișier de cheie care poate fi citit doar de root este o implementare normală, nu un defect al profilului. Corectarea ține de proprietate sau de capabilități, nu de fișier.

Rularea clientului cu sudo poate rezolva o refuzare locală a permisiunii și nu poate adăuga o directivă pe care binarul nu o implementează. De asemenea, schimbă ce inel de chei, căi de configurare și context de manager de rețea se aplică, așa că rezultatul nu este același test.

Adaptați cu intenție

Când un furnizor publică profiluri separate, luați-l pe cel destinat clientului receptor. Adaptarea fișierului altei platforme este ultima soluție. Necesită o evidență a fiecărei opțiuni modificate și o copie a originalului.

Testați identitatea, rutarea și DNS ca trei rezultate separate. Un profil care se autentifică și rutează, dar rupe rezolvarea numelor, este un profil parțial adaptat, nu unul funcțional.