Cum să asamblați un profil de client OpenVPN din fișierele emise
Un fișier ovpn este configurație, nu un certificat. Asamblați un profil de client din CA, certificatul și cheia emise, apoi fixați identitatea și directorul.
Operatorul dumneavoastră vă înmânează un pachet CA, un certificat de client și cheia acestuia, iar clientul nu pornește până când acestea nu sunt conectate într-un singur profil. Profilul este configurație: indică acele fișiere, nu le conține, iar editarea nu îl poate transforma într-un certificat. Ghidul începe de la un laptop deja aprobat și se termină cu un profil pe care îl puteți porni dintr-un director cunoscut. Nu creează o CA, nu înregistrează un certificat nou și nu atinge serverul.
Ținta aici este un client de linie de comandă OpenVPN 2.6 pentru Linux, rutat prin TUN peste UDP, cu autentificare prin certificat.
Adunați doar fișierele din partea clientului
Lucrați într-un director protejat și adunați materialul de încredere CA aprobat, certificatul de client emis și cheia privată care îi corespunde. În acest exemplu numele sunt ca.crt, laptop-a.crt și laptop-a.key. Numele fișierelor sunt doar etichete; nu spun nimic despre ce conține fiecare fișier.
Dacă ați generat cheia în timpul înregistrării, aceasta nu a părăsit niciodată mașina; de la emitent trebuie să revină doar certificatul semnat și lanțul public. Verificați că certificatul poartă rolul de client așteptat de serviciu. Verificați și că cheia aparține acelui certificat, nu unuia mai vechi dintr-o încercare anterioară. O pereche nepotrivită produce o eroare TLS mult mai târziu, care arată ca o problemă a serverului.
Lăsați cheia privată de semnare a CA, cheia privată a serverului și parametrii DH în afara acestui pachet.
Conectați fișierele într-un profil mic
Profilul de mai jos este intenționat scurt. Fiecare linie fie alege punctul final, fie restricționează identitatea pe care clientul o va accepta, fie indică unul dintre cele trei fișiere.
client
dev tun
proto udp
remote vpn.example.net 1194
nobind
remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key
Linia remote alege punctul final de rețea. remote-cert-tls server cere ca cealaltă parte să prezinte un certificat cu rol de server. verify-x509-name fixează numele așteptat, aici vpn-gateway ca Common Name al certificatului serverului cu câmpul de nume implicit al OpenVPN. Acea valoare nu este dedusă din numele de gazdă DNS, așa că folosiți schema de identitate furnizată de operator.
Nu renunțați la aceste verificări doar pentru că un punct final de test arată un certificat diferit.
Acest profil de bază presupune că nu există o provocare separată de cont și nicio cheie de canal de control. Dacă serviciul are nevoie de auth-user-pass, tls-auth sau tls-crypt, păstrați configurația și materialul primit, pentru că un secret de canal de control generat de dumneavoastră nu se va potrivi cu cel pe care îl deține serverul. Păstrați și politica de criptare a serviciului în loc să importați linii de compresie sau de cifrare dintr-un exemplu vechi.
Faceți explicit directorul de lucru
Căile relative urmează directorul de lucru al procesului, nu locația fișierului .ovpn.
Asta îi surprinde pe cei care mută profilul într-un folder nou și se așteaptă ca cheia să îl urmeze. Pentru un director ales de administrator, comanda de mai jos trece la o cale absolută înainte de a citi profilul și referințele sale.
sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn
Un asistent de import pentru desktop sau un serviciu de sistem poate împacheta dependențele pentru dumneavoastră și poate aplica propriile reguli. Poate folosi și un alt director de lucru decât cel în care ați testat. Confirmați cum metoda dumneavoastră de lansare rezolvă căile către cheie, certificat și CA. Mutarea doar a fișierului .ovpn nu mută cheia privată separată.
Păstrați cheia lizibilă doar pentru utilizatorul sau identitatea de serviciu vizate.
Verificați predarea, nu numele fișierelor
Înainte de prima conexiune autorizată, verificați punctul final, identitatea certificatului, emitentul și fereastra de valabilitate. Apoi confirmați că referințele fișierelor se rezolvă din directorul de lucru pe care îl veți folosi efectiv. După conectare, testați comportamentul aplicației și al DNS-ului pe care politica de rutare ar trebui să îl asigure. Trei fișiere lizibile nu dovedesc nimic despre autorizarea serverului sau despre o cale de resursă utilizabilă.
Dacă apare o solicitare de frază de acces, aceasta aparține cheii private, nu unui cont VPN.
În final, inventariați pachetul ca material de acreditare. Predarea aceluiași certificat și a aceleiași chei către un al doilea laptop copiază identitatea, iar redenumirea fișierului nu vă oferă o a doua înregistrare. Aceasta este diferența dintre a asambla un profil și a-l emite.