OpenVPN Access Server versus Community: ce migrează de fapt

Profilurile migrează; listele de utilizatori rămân în urmă. O echipă care trece între Access Server și Community Edition întâlnește acel gol o oră după trecere, când primul ei client se autentifică și apoi nu are politică de grup, nicio rută per utilizator și nici resetare autonomă a parolei. Ambele produse vorbesc același protocol și acceptă același client, și tocmai de aceea golul rămâne invizibil în timpul planificării. Ceea ce alegeți de fapt este stratul de administrare și oamenii care îl dețin.

Tratați decizia ca pe o întrebare de inventar, nu ca pe o grilă de funcții. Întrebați cine creează utilizatori, cine revocă certificate și cine răspunde la apel la 02:00.

De ce fișierul .ovpn nu aduce configurația

Un profil .ovpn descrie relația unui client cu un server: gazda remotă, protocolul, CA, un certificat și o cheie de client, și orice material tls-crypt încorporat. Aruncați acel fișier într-o instalare nouă și clientul finalizează totuși un handshake, așa că migrarea pare terminată. Nimic din el nu listează utilizatorii, grupurile lor, rutele lor statice sau politica ce decidea cui i se permitea deloc să se conecteze. Acele înregistrări trăiesc în stocarea proprie a serverului, iar cele două produse le păstrează în forme diferite.

În Community Edition echivalentele sunt fișiere pe care le păstrați voi: intrări client-config-dir cu opțiuni per client, cum ar fi ifconfig-push și iroute, o CRL pentru revocări și cheia tls-crypt. Access Server păstrează aceleași concepte în propria bază de date și le expune printr-o consolă web și instrumentul de linie de comandă sacli. Conceptele se corespund unu la unu; artefactele nu se mută deloc.

Profilurile strecoară și comportamente pe care nimeni nu le observă până când nu se schimbă. Un client cu redirect-gateway def1 trimite toată navigarea prin server; mutați-l într-o instalare fără acea linie și reclamația va fi că internetul s-a stricat. O nepotrivire de CA sau o setare greșită remote-cert-tls eșuează zgomotos, ceea ce este rezultatul bun. O cheie tls-crypt lipsă eșuează ca un timeout silențios, ceea ce nu este.

Ce deține stratul de administrare

Numărați ceea ce nu este protocol: crearea conturilor, resetarea parolelor, alocarea pe grupuri, înscrierea la MFA, drepturile de conectare și urma de audit care răspunde cine s-a conectat când. Community Edition nu oferă nimic din acestea direct. Alegeți un backend de autentificare, conectați PAM, LDAP sau RADIUS printr-un plugin sau auth-user-pass-verify, și întrețineți restul singuri. Access Server livrează un portal de utilizator, o consolă de administrare și integrări cu furnizori de identitate obișnuiți. Niciuna dintre aranjamente nu este mai sigură implicit, pentru că politica tot trebuie scrisă de cineva care cunoaște rețeaua.

Drepturile sunt cea mai ascuțită diferență operațională. Access Server este licențiat după numărul de conexiuni simultane și aplică acel număr în software. În Community Edition, un plafon global este o singură linie max-clients, în timp ce orice per utilizator sau per grup înseamnă mai multă muncă cu client-config-dir și aplicarea voastră. O echipă fără poftă pentru acea întreținere cumpără exact asta când plătește pentru produsul comercial.

Licențiere și suport: linia pe care nimeni nu o bugetează

Community Edition este gratuit și open source. Access Server este comercial, iar nivelul său gratuit a acoperit istoric un număr mic de conexiuni simultane, cu o licență plătită deasupra. Orice cifră citată într-un răspuns vechi de forum este deja depășită, așa că verificați termenii actuali ai furnizorului înainte de a calcula proiectul. Comparația onestă adaugă orele petrecute construind administrarea utilizatorilor, MFA și monitorizare pe partea comunității la linia de licență din partea comercială.

Proprietatea suportului urmează aceeași împărțire. Cu Community Edition sunteți calea de escaladare pentru fiecare client ciudat și fiecare actualizare de kernel. Cu Access Server aveți un furnizor la care să sunați și moșteniți ritmul lui de lansări, fie că se potrivește ferestrei voastre de schimbări, fie că nu.

Verificări înainte de trecere

Inventariați ce deține de fapt serverul aflat în funcțiune înainte de trecere în orice direcție. Pe partea Access Server, exportați lista de utilizatori și alocările pe grupuri și notați ce conturi se bazează pe MFA. Pe partea Community Edition, listați certificatele emise, CRL și fiecare fișier de sub client-config-dir. Comparați cele două liste linie cu linie, pentru că diferența dintre ele este munca de migrare.

Testați clienți reprezentativi cât timp serviciul vechi încă rulează. openvpn --config client.ovpn --verb 4 în prim-plan tipărește handshake-ul, rutele trimise și opțiunile DNS, iar openssl x509 -in client.crt -noout -subject -enddate arată ce certificat prezintă de fapt clientul. Un client care se conectează dar nu ajunge la o gazdă internă are un gol de rută sau de iroute, nu o eroare de autentificare.

Țineți vie vechea cale de recuperare până când înlocuitorul trece atât un test cu acces refuzat, cât și unul reușit. Scrieți harta finală pe o singură pagină: fiecare cerință, artefactul care o satisface astăzi și artefactul care o va satisface după aceea.