Ce roluri software are nevoie o poartă OpenVPN fără ecran

O mașină dedicată unei porți OpenVPN are nevoie de o instalare de server acceptată și de software pentru sarcinile pe care le execută efectiv. Un meniu de instalare care oferă SSH, găzduire web și alte roluri de server nu este o listă de cerințe prealabile pentru OpenVPN. O implementare fără ecran este complet rezonabilă. Important este să separați trei sarcini: transportul tunelului, administrarea gazdei și emiterea de acreditări.

Aceasta este ordinea de inventariere pe care o folosesc, cu verificarea care închide fiecare pas.

1. Dați serviciului de tunel propriul pachet și profil

Ghidul serverului OpenVPN pentru Ubuntu folosește pachetul openvpn al distribuției cu o linie de comandă și o configurație de serviciu. Același pachet servește ca client Linux, iar configurația alege rolul.

Asta înseamnă că instalarea unui GUI de client nu este ceea ce transformă gazda în server, iar eliminarea lui nu este ceea ce o face fără ecran. Notați ce profil citește instanța care rulează, pentru că un al doilea fișier de configurare din același director poate fi încărcat fără ca nimeni să observe, iar daemonul raportează succes în ambele cazuri. Când există două profiluri, managerul de servicii decide care câștigă, iar acea decizie aparține notițelor dumneavoastră, nu unei presupuneri.

2. Decideți calea de administrare înainte de tunel

OpenSSH provine dintr-un pachet openssh-server separat și rulează ca serviciu propriu. Este util când un administrator trebuie să ajungă la mașină prin SSH, dar OpenVPN nu are nevoie de un server SSH pentru a schimba pachete VPN. O consolă locală sau un canal de administrare a platformei aprobat este o altă cale validă. Decideți pe care vă bazați înainte de a schimba rutarea sau filtrarea, pentru că un tunel nou nu ar trebui să fie niciodată singura modalitate netestată de a se repara singur.

3. Emiteți acreditări de la proprietarul aprobat

Exemplul Ubuntu instalează easy-rsa lângă OpenVPN pentru a construi o PKI mică, ceea ce este un rol de emitere de acreditări, nu un serviciu de tunel în funcțiune. Dacă organizația are deja un proces de emitere aprobat, folosiți-l în loc să creați o CA nelegată doar pentru că un tutorial include una. Țineți cheia privată și certificatul porții separate de cheia de semnare a CA, și alegeți în mod deliberat locația de semnare și de backup. Copierea fiecărui fișier PKI pe fiecare gazdă nu este o cerință de software.

4. Lăsați pluginurile de desktop desktopurilor

Un editor NetworkManager sau un plugin de import are un scop pe o mașină care folosește acel flux de lucru. Nu este o funcție suplimentară de server necesară pentru că poarta vorbește OpenVPN.

Alegeți un singur proprietar pentru conexiune și nu porniți o a doua copie a aceluiași profil administrată de pe desktop.

5. Acceptați poarta cu un client real

Mai puține pachete nu înseamnă o poartă terminată. Serverul are în continuare nevoie de un ascultător aprobat, identități, rute, redirecționare unde este necesar, o politică îngustă de firewall și calea de întoarcere prevăzută. Notați unde apar jurnalele sale și cum se aplică actualizările, pentru că aceste două răspunsuri decid cum va fi diagnosticată o defecțiune mai târziu.

Un proiect cu ieșire pe internet și un proiect cu acces la o rețea privată au cerințe diferite de redirecționare, așa că decideți pe care îl construiți înainte de a deschide ceva. Porniți un client aprobat și verificați resursa dorită în locul indicatorului tunelului. Apoi reporniți serviciul într-un mod controlat și confirmați calea de pornire nesupravegheată, pentru că o poartă care pornește doar când cineva se uită nu este încă implementată.