Access Server na Community OpenVPN: wat herbou moet word

Access Server en Community OpenVPN praat dieselfde protokol en byna niks anders op dieselfde manier nie. Die handdruk, syferonderhandeling en tonneldatavlak is versoenbaar, so n kliënt kan dikwels aan albei koppel sonder om sy profiel te wysig. Wat verskil, is wie die konfigurasie besit: een produk lewer n bestuurslaag wat beleid skryf en afdwing, terwyl die ander een jou n konfigurasielêer en n stel hake gee en verwag dat jy besluit.

Daardie onderskeid is die migrasieplan. Enigiets wat die ou produk namens jou besluit het, moet iewers in die nuwe ontplooiing n eksplisiete besluit word.

Waar die twee ontplooiings ophou uitruilbaar wees

In Access Server besit die webadministrasiekoppelvlak gebruikers, groepe, regte per gebruiker, sertifikaatuitreiking en die profielbundel wat iemand aflaai. Die daemon daaronder word deur daardie laag gekonfigureer, so die lopende diens is die produk van gestoorde toestand wat jy selde met die hand wysig. In Community OpenVPN is die konfigurasielêer die toestand: dit noem die luisteraar, die sertifikaatowerheid, die verifikasi haak en elke gestuurde opsie, en niks herskryf dit vir jou nie. Dieselfde TLS-masjinerie sit dus onder twee baie verskillende eienaarskapmodelle.

n Kort kartering maak die gaping konkreet. Gebruikers en groepe bestaan slegs in die ou databasis totdat jy hulle herskep. Profielbundels word n konfigurasielêer plus sertifikate wat jy self versprei. Regte per gebruiker word richtlyne in client-config-dir. Die administrasiekoppelvlak word watter proses jy ook al kies om sertifikate uit te reik en lêers te wysig.

Skryf daardie kartering neer voordat jy aan n bediener raak. Elke ry wat jy nie kan invul nie, is n funksie wat jy op die punt is om te laat vaar, en om een stilweg te laat vaar, is hoe n migrasie twee weke later n onderbreking word.

Identiteit dra nie saam met die sertifikaatlêers oor nie

Sertifikate van die ou owerheid kan in die nuwe diens korrek ontleed word en steeds die verkeerde identiteit wees, want die ou produk het hulle met rekeningtoestand gepaar wat die nuwe een nie kan sien nie. Besluit eers of die nuwe ontplooiing slegs deur sertifikaat verifieer, deur n inprop wat PAM of RADIUS bereik, of deur een of ander kombinasie, en kyk dan dat elke opsie die eienskappe behou wat jy nodig het. n Gedeelde sertifikaat sonder identiteit per gebruiker is een geloofsbrief vir almal wat dit het. Herroeping moet ook van dag een af werk, wat in Community OpenVPN n CRL-lêer beteken waarna crl-verify verwys, plus n proses wat dit hergenereer.

Beplan inskrywing voor die oorskakeling, nie daarna nie. Nuwe sertifikate, n getoetste herroepingsroete en n gedokumenteerde manier om een persoon te deaktiveer is voorvereistes, nie opvolgwerk nie. As multifaktor-verifikasie uit die ou produk se integrasie gekom het, noem die vervanging eksplisiet, want n inprop wat nie geïnstalleer is nie, sluit op die slegste moontlike oomblik.

Roetes en naamresolusie volg die konfigurasieskrywer

Roetes, DNS-instellings en voltonnel-gedrag is gestuurde opsies in albei produkte, maar net een van hulle bereken dit vir jou. In Community OpenVPN skryf jy die stuuragenda self, besluit of redirect-gateway op die bediener of die kliënt hoort, en bevestig dat aanstuur en NAT op die gasheer bestaan. n Voltooide handdruk sê niks vir jou oor aanstuur, adresvertaling of die roetes wat n kliënt werklik ontvang het nie.

Gedrag per kliënt benodig client-config-dir plus n lêer wat na die kliënt se sertifikaat-gewone naam vernoem is, en n werf-tot-werf eweknie benodig iroute-inskrywings vir die voorvoegsels daarby. Kry die naamgewing verkeerd en die opsies word geïgnoreer sonder n fout. Toets met een nie-produksie-kliënt in sy eie adrespoel, en lees dan die adres wat hy toegewys het, die roetes wat hy gekry het en die resolveerder-instellings waarmee hy geëindig het.

Rangskik die oorskakeling so dat die ou diens kan terugkeer

Laat die nuwe luisteraar op n ander poort of adres loop, en hou die oue verkeer bedien terwyl jy die vervanging bewys. Twee daemons op een sok is nie n terugrolplan nie.

Skuif een groep op n tyd, met sy eie sertifikate, sy eie poel en sy eie roetes, en oefen die terugkeerpad eerder as om dit tydens n voorval te ontdek. n Terugrol wat net werk as die nuwe diens eerste gestop word, is steeds n terugrol, maar dit moet getoets word terwyl niks aan die brand is nie.

Laat laaste, lys die funksies met geen direkte ekwivalent nie en besluit elkeen se lot skriftelik: selfdiens-profielaflaai, regtevlaggies per gebruiker, die administratiewe koppelvlak self, lewendige verbindingsrapportering. Om hulle met n gedokumenteerde handmatige proses te vervang, is n wettige antwoord. Om die ry leeg te laat, is nie.

Die werk is klaar wanneer n gebruiker wat nooit die ou portaal gesien het nie, kan inskryf, koppel, die beoogde interne adres bereik en skoon herroep word. Alles voor daardie punt is voorbereiding.