De la Access Server la Community OpenVPN: ce trebuie reconstruit

Access Server și Community OpenVPN vorbesc același protocol și aproape nimic altceva la fel. Handshake-ul, negocierea cifrurilor și planul de date al tunelului sunt compatibile, așa că un client se poate conecta adesea la oricare dintre ele fără să își editeze profilul. Diferența este cine deține configurația: un produs livrează un strat de administrare care scrie și aplică politica, celălalt vă dă un fișier de configurare și un set de hook-uri și așteaptă să decideți dumneavoastră.

Această distincție este planul de migrare. Tot ce vechiul produs decidea în locul dumneavoastră trebuie să devină o decizie explicită undeva în noua implementare.

Unde cele două implementări încetează să mai fie interschimbabile

În Access Server, interfața web de administrare deține utilizatorii, grupurile, permisiunile pe utilizator, emiterea certificatelor și pachetul de profil pe care cineva îl descarcă. Daemonul de dedesubt este configurat de acel strat, așa că serviciul care rulează este produsul unei stări stocate pe care o editați rar manual. În Community OpenVPN, fișierul de configurare este starea: numește listener-ul, autoritatea de certificare, hook-ul de autentificare și fiecare opțiune trimisă, și nimic nu îl rescrie pentru dumneavoastră. Aceeași mașinărie TLS stă deci sub două modele de proprietate foarte diferite.

O cartografiere scurtă face decalajul concret. Utilizatorii și grupurile există doar în baza de date veche până le recreați. Pachetele de profil devin un fișier de configurare plus certificatele pe care le distribuiți singur. Permisiunile pe utilizator devin directive în client-config-dir. Interfața de administrare devine procesul pe care îl alegeți pentru a emite certificate și a edita fișiere.

Scrieți această cartografiere înainte de a atinge un server. Fiecare rând pe care nu îl puteți completa este o funcție pe care sunteți pe cale să o pierdeți, iar pierderea în tăcere este felul în care o migrare devine o pană două săptămâni mai târziu.

Identitatea nu se transferă cu fișierele de certificat

Certificatele de la vechea autoritate se pot parsa corect în noul serviciu și totuși pot fi identitatea greșită, pentru că vechiul produs le împerechea cu o stare de cont pe care noul nu o vede. Decideți mai întâi dacă noua implementare autentifică doar cu certificat, cu un plugin care ajunge la PAM sau RADIUS, sau cu o combinație, apoi verificați că fiecare opțiune păstrează proprietățile de care aveți nevoie. Un certificat partajat fără identitate pe utilizator este o singură acreditare pentru toți cei care îl au. Revocarea trebuie să funcționeze și din prima zi, ceea ce în Community OpenVPN înseamnă un fișier CRL la care face referire crl-verify plus un proces care îl regenerează.

Planificați înscrierea înainte de comutare, nu după. Certificate noi, o cale de revocare testată și o modalitate documentată de a dezactiva o persoană sunt condiții prealabile, nu muncă ulterioară. Dacă autentificarea multifactor a venit din integrarea vechiului produs, numiți explicit înlocuitorul, pentru că un plugin neinstalat eșuează închis în cel mai rău moment.

Rutarea și rezolvarea numelor urmează autorul configurației

Rutele, setările DNS și comportamentul tunelului complet sunt opțiuni trimise în ambele produse, dar doar unul le calculează pentru dumneavoastră. În Community OpenVPN scrieți singur directivele push, decideți dacă redirect-gateway aparține serverului sau clientului și confirmați că pe gazdă există forwarding și NAT. Un handshake încheiat nu vă spune nimic despre forwarding, traducerea adreselor sau rutele pe care clientul le-a primit efectiv.

Comportamentul pe client necesită client-config-dir plus un fișier numit după common name-ul certificatului clientului, iar o pereche site-la-site necesită intrări iroute pentru prefixele din spate. Dacă numele este greșit, opțiunile sunt ignorate fără eroare. Testați cu un client care nu este de producție în propriul pool de adrese, apoi citiți adresa atribuită, rutele primite și setările resolverului cu care a încheiat.

Ordonați comutarea astfel încât serviciul vechi să poată reveni

Rulați noul listener pe alt port sau altă adresă și lăsați-l pe cel vechi să servească trafic cât timp dovediți înlocuitorul. Două daemon-uri pe același socket nu sunt un plan de revenire.

Mutați un singur grup o dată, cu certificatele, pool-ul și rutele lui, și repetați calea de întoarcere în loc să o descoperiți în timpul unui incident. O revenire care funcționează doar dacă noul serviciu este oprit mai întâi rămâne o revenire, dar trebuie testată când nimic nu arde.

În final, enumerați funcțiile fără echivalent direct și decideți în scris soarta fiecăreia: descărcarea de profil în autoservire, indicatoarele de permisiune pe utilizator, interfața de administrare în sine, raportarea conexiunilor în timp real. Înlocuirea lor cu un proces manual documentat este un răspuns legitim. Lăsarea rândului gol nu este.

Lucrul este terminat când o persoană care nu a văzut niciodată portalul vechi se poate înscrie, conecta, ajunge la adresa internă dorită și fi revocată curat. Tot ce este înainte este pregătire.