Nga Access Server te OpenVPN Community: çfarë duhet rindërtuar

Access Server dhe OpenVPN Community flasin të njëjtin protokoll dhe pothuajse asgjë tjetër në të njëjtën mënyrë. Handshake-u, negocimi i shifrave dhe plani i të dhënave të tunelit janë të përputhshëm, prandaj një klient shpesh mund të lidhet me njërin ose me tjetrin pa ndryshuar profilin. Ajo që ndryshon është kush e zotëron konfigurimin: njëri produkt sjell një shtresë administrimi që shkruan dhe zbaton politikën, ndërsa tjetri ju jep një skedar konfigurimi dhe një grup pikash lidhjeje dhe pret që ju të vendosni.

Ky dallim është plani i migrimit. Çdo gjë që produkti i vjetër vendoste në emrin tuaj duhet të bëhet një vendim i shprehur diku në vendosjen e re.

Ku dy vendosjet nuk janë më të këmbyeshme

Në Access Server, ndërfaqja e administrimit në web zotëron përdoruesit, grupet, lejet për përdorues, lëshimin e certifikatave dhe paketën e profilit që një person shkarkon. Daemoni nën të konfigurohet nga ajo shtresë, kështu që shërbimi që punon është produkt i një gjendjeje të ruajtur që rrallë e redaktoni me dorë. Në OpenVPN Community, skedari i konfigurimit është gjendja: ai emërton dëgjuesin, autoritetin certifikues, pikën e lidhjes së autentikimit dhe çdo opsion të shtyrë, dhe asgjë nuk e rishkruan për ju. E njëjta mekanikë TLS ndodhet pra nën dy modele pronësie shumë të ndryshme.

Një hartë e shkurtër e bën hendekun konkret. Përdoruesit dhe grupet ekzistojnë vetëm në bazën e vjetër të të dhënave derisa t’i rikrijoni. Paketat e profilit bëhen një skedar konfigurimi plus certifikata që i shpërndani vetë. Lejet për përdorues bëhen direktiva në client-config-dir. Ndërfaqja e administrimit bëhet procesi që zgjidhni për të lëshuar certifikata dhe për të redaktuar skedarë.

Shkruajeni atë hartë përpara se të prekni një server. Çdo rresht që nuk mund ta plotësoni është një veçori që jeni gati ta hiqni, dhe heqja e saj në heshtje është mënyra se si një migrim bëhet ndërprerje dy javë më vonë.

Identiteti nuk transferohet me skedarët e certifikatave

Certifikatat nga autoriteti i vjetër mund të analizohen saktë në shërbimin e ri dhe gjithsesi të jenë identiteti i gabuar, sepse produkti i vjetër i lidhte me gjendje llogarie që i riu nuk e sheh. Vendosni fillimisht nëse vendosja e re autentikon vetëm me certifikatë, me një shtojcë që arrin PAM ose RADIUS, apo me një kombinim, pastaj kontrolloni që çdo opsion ruan vetitë që ju nevojiten. Një certifikatë e përbashkët pa identitet për përdorues është një kredencial i vetëm për të gjithë ata që e mbajnë. Revokimi duhet të funksionojë që nga dita e parë gjithashtu, që në OpenVPN Community do të thotë një skedar CRL i referuar nga crl-verify plus një proces që e rigjeneron.

Planifikoni regjistrimin përpara kalimit, jo pas tij. Certifikata të reja, një rrugë revokimi e provuar dhe një mënyrë e dokumentuar për të çaktivizuar një person janë parakushte, jo punë pasuese. Nëse autentikimi shumëfaktorësh vinte nga integrimi i produktit të vjetër, emërtoni shprehimisht zëvendësimin, sepse një shtojcë që nuk është instaluar dështon e mbyllur në momentin më të keq të mundshëm.

Rrugëtimi dhe zgjidhja e emrave ndjekin atë që shkruan konfigurimin

Rrugët, cilësimet DNS dhe sjellja e tunelit të plotë janë opsione të shtyra në të dy produktet, por vetëm njëri prej tyre i llogarit për ju. Në OpenVPN Community ju i shkruani vetë direktivat e shtytjes, vendosni nëse redirect-gateway i takon serverit apo klientit, dhe konfirmoni që përcjellja dhe NAT ekzistojnë në host. Një handshake i përfunduar nuk ju thotë asgjë për përcjelljen, përkthimin e adresave apo rrugët që një klient ka marrë në të vërtetë.

Sjellja për klient kërkon client-config-dir plus një skedar të emërtuar sipas emrit të përbashkët të certifikatës së klientit, dhe një partner nga sajt në sajt kërkon zëra iroute për prefikset që ndodhen pas tij. Nëse emërtimi është i gabuar, opsionet injorohen pa asnjë gabim. Provoni me një klient jo-produksion në grupin e vet të adresave, pastaj lexoni adresën që iu caktua, rrugët që iu dhanë dhe cilësimet e zgjidhësit me të cilat përfundoi.

Renditni kalimin që shërbimi i vjetër të mund të kthehet

Ekzekutoni dëgjuesin e ri në një port ose adresë tjetër, dhe mbani të vjetrin duke shërbyer trafikun ndërsa provoni zëvendësimin. Dy daemonë në një soket të vetme nuk janë plan kthimi.

Zhvendosni një grup në një kohë, me certifikatat e vet, grupin e vet dhe rrugët e veta, dhe provoni rrugën e kthimit në vend që ta zbuloni gjatë një incidenti. Një kthim që funksionon vetëm nëse shërbimi i ri ndalet së pari është gjithsesi kthim, por duhet të provohet kur asgjë nuk është në zjarr.

Së fundi, listoni veçoritë pa ekuivalent të drejtpërdrejtë dhe vendosni fatin e secilës me shkrim: shkarkimi i profilit vetë-shërbim, flamujt e lejeve për përdorues, vetë ndërfaqja e administrimit, raportimi i lidhjeve në kohë reale. Zëvendësimi i tyre me një proces manual të dokumentuar është përgjigje e ligjshme. Lënia e rreshtit bosh nuk është.

Puna përfundon kur një përdorues që nuk e ka parë kurrë portalin e vjetër mund të regjistrohet, të lidhet, të arrijë adresën e brendshme të synuar dhe të revokohet pastër. Çdo gjë para kësaj pike është përgatitje.