OpenVPN Access Server kontraŭ Community: kio vere migras

Profiloj migras; listoj de uzantoj restas malantaŭe. Teamo, kiu transiras inter Access Server kaj Community Edition, renkontas tiun mankon unu horon post la transiro, kiam ĝia unua kliento aŭtentikiĝas kaj poste havas neniun grupan politikon, neniun itineron por uzanto kaj neniun memservan pasvortan restarigon. Ambaŭ produktoj parolas la saman protokolon kaj akceptas la saman klienton, kaj ĝuste tial la manko restas nevidebla dum planado. Kion vi efektive elektas, estas la administra tavolo kaj la homoj, kiuj posedas ĝin.

Traktu la decidon kiel inventaran demandon anstataŭ funkcia tabelo. Demandu, kiu kreas uzantojn, kiu revokas atestilojn, kaj kiu respondas la vokon je 02:00.

Kial la dosiero .ovpn ne portas la agordon

Profilo .ovpn priskribas la rilaton de unu kliento kun unu servilo: la malproksima gastiganto, la protokolo, la CA, klienta atestilo kaj ŝlosilo, kaj ajna enkorpigita tls-crypt-materialo. Ĵetu tiun dosieron en freŝan konstruaĵon kaj la kliento tamen kompletigas manpremon, do la migrado aspektas finita. Nenio en ĝi listigas la uzantojn, iliajn grupojn, iliajn statikajn itinerojn, aŭ la politikon, kiu decidis, kiu rajtis konekti entute. Tiuj rikordoj loĝas en la propra stokejo de la servilo, kaj la du produktoj konservas ilin en malsamaj formoj.

En Community Edition la ekvivalentoj estas dosieroj, kiujn vi mem tenas: enskriboj client-config-dir kun opcioj por kliento kiel ifconfig-push kaj iroute, CRL por revokoj, kaj la ŝlosilo tls-crypt. Access Server tenas la samajn konceptojn en sia propra datumbazo kaj elmontras ilin per retkonsolo kaj la komandlinia ilo sacli. La konceptoj mapiĝas unu al unu; la artefaktoj tute ne translokiĝas.

Profiloj ankaŭ kontrabandas konduton, kiun neniu rimarkas ĝis ĝi ŝanĝiĝas. Kliento kun redirect-gateway def1 sendas la tutan retumadon tra la servilo; movu ĝin al konstruaĵo sen tiu linio kaj la plendo estos, ke la interreto rompiĝis. CA-malkongruo aŭ malĝusta agordo remote-cert-tls fiaskas laŭte, kio estas la bona rezulto. Mankanta ŝlosilo tls-crypt fiaskas kiel silenta tempolimo, kio ne estas.

Kion posedas la administra tavolo

Kalkulu tion, kio ne estas protokolo: kontokreado, pasvorta restarigo, grup-asigno, MFA-aliĝo, konektrajtoj, kaj la revizia spuro, kiu respondas, kiu konektis kiam. Community Edition donas neniun el tiuj rekte. Vi elektas aŭtentikigan backend-on, enkonektas PAM, LDAP aŭ RADIUS per kromaĵo aŭ auth-user-pass-verify, kaj bontenas la restaĵon mem. Access Server liveras uzantportalojn, administran konsolon kaj integriĝojn kun kutimaj identecprovizantoj. Neniu el la du aranĝoj estas pli sekura defaŭlte, ĉar la politikon ankoraŭ devas skribi iu, kiu konas la reton.

Rajtoj estas la plej akra operacia diferenco. Access Server estas licencata laŭ nombro de samtempaj konektoj kaj devigas tiun nombron per programaro. En Community Edition tutmonda limo estas unu sola linio max-clients, dum io ajn por uzanto aŭ grupo signifas pli da laboro pri client-config-dir kaj vian propran devigadon. Teamo sen apetito por tiu bontenado aĉetas ĝuste tion, kiam ĝi pagas por la komerca produkto.

Licencado kaj subteno: la ero, kiun neniu buĝetigas

Community Edition estas senpaga kaj malfermfonta. Access Server estas komerca, kaj ĝia senpaga nivelo historie kovris malgrandan nombron de samtempaj konektoj kun pagita licenco super tio. Ajna nombro citita en malnova forumrespondo jam estas malaktuala, do kontrolu la nunajn kondiĉojn de la vendanto antaŭ ol kalkuli la projekton. La honesta komparo aldonas la horojn pasigitajn por konstrui uzantadministradon, MFA kaj monitoradon ĉe la komunuma flanko al la licenca ero ĉe la komerca flanko.

Subtena posedo sekvas la saman dividon. Kun Community Edition vi estas la eskalada vojo por ĉiu stranga kliento kaj ĉiu kerno-ĝisdatigo. Kun Access Server vi havas vendanton por voki, kaj vi heredas ĝian eldonritmon ĉu ĝi taŭgas por via ŝanĝa fenestro ĉu ne.

Kontroloj antaŭ la transiro

Inventaru, kion la funkcianta servilo efektive tenas antaŭ la transiro en ambaŭ direktoj. Ĉe la Access Server-flanko, eksportu la uzantliston kaj grupajn asignojn kaj notu, kiuj kontoj dependas de MFA. Ĉe la Community Edition-flanko, listigu la eldonitajn atestilojn, la CRL kaj ĉiun dosieron sub client-config-dir. Komparu la du listojn linio post linio, ĉar la diferenco inter ili estas la migra laboro.

Testu reprezentajn klientojn dum la malnova servo ankoraŭ funkcias. openvpn --config client.ovpn --verb 4 en la antaŭplano presas la manpremon, la puŝitajn itinerojn kaj la DNS-opciojn, kaj openssl x509 -in client.crt -noout -subject -enddate montras, kiun atestilon la kliento efektive prezentas. Kliento, kiu konektiĝas sed ne atingas internan gastiganton, havas mankon en itinero aŭ iroute, ne aŭtentikigan fiaskon.

Tenu la malnovan riparvojon viva ĝis la anstataŭanto trapasos teston de rifuzita aliro same kiel sukcesan. Skribu la finan mapon sur unu paĝo: ĉiu postulo, la artefakto, kiu kontentigas ĝin hodiaŭ, kaj la artefakto, kiu kontentigos ĝin poste.