Mula Access Server tungo sa Community OpenVPN: ano ang kailangang itayong muli

Ang Access Server at Community OpenVPN ay nagsasalita ng parehong protocol at halos wala nang iba sa parehong paraan. Ang handshake, ang negosasyon ng cipher at ang data plane ng tunnel ay magkatugma, kaya ang isang kliyente ay madalas na kumokonekta sa alinman nang hindi binabago ang profile nito. Ang pagkakaiba ay kung sino ang may-ari ng konfigurasyon: ang isang produkto ay may kasamang layer ng pamamahala na nagsusulat at nagpapatupad ng patakaran, ang isa ay nagbibigay sa iyo ng file ng konfigurasyon at isang hanay ng hook at inaasahan na ikaw ang magpasya.

Ang pagkakaibang iyon ang plano ng paglipat. Anuman ang pinagpasyahan ng lumang produkto sa ngalan mo ay dapat maging malinaw na desisyon sa isang lugar sa bagong deployment.

Saan hindi na mapagpapalit ang dalawang deployment

Sa Access Server, ang web administration interface ang may-ari ng mga user, group, pahintulot ng bawat user, pag-isyu ng sertipiko at ang profile bundle na dinodownload ng isang tao. Ang daemon sa ilalim ay kinokonfigura ng layer na iyon, kaya ang serbisyong tumatakbo ay produkto ng naka-imbak na estado na bihirang i-edit mo nang manwal. Sa Community OpenVPN, ang file ng konfigurasyon ang estado: pinangalanan nito ang listener, ang certificate authority, ang authentication hook at bawat pushed option, at walang nagsusulat muli nito para sa iyo. Ang parehong TLS machinery ay nasa ilalim ng dalawang magkaibang modelo ng pagmamay-ari.

Ang maikling mapping ay ginagawang konkreto ang agwat. Ang mga user at group ay umiiral lamang sa lumang database hanggang muling likhain mo sila. Ang mga profile bundle ay nagiging file ng konfigurasyon at mga sertipikong ikaw mismo ang namamahagi. Ang pahintulot ng bawat user ay nagiging direktiba sa client-config-dir. Ang administration interface ay nagiging anumang prosesong pipiliin mo para sa pag-isyu ng sertipiko at pag-edit ng file.

Isulat ang mapping na iyon bago hawakan ang isang server. Bawat hilera na hindi mo mapunan ay isang tampok na malapit mo nang mawala, at ang tahimik na pagkawala ang paraan kung paano nagiging outage ang paglipat pagkalipas ng dalawang linggo.

Hindi lumilipat ang pagkakakilanlan kasama ng mga file ng sertipiko

Ang mga sertipiko mula sa lumang authority ay maaaring ma-parse nang tama sa bagong serbisyo at mali pa rin ang pagkakakilanlan, dahil ipinares ng lumang produkto ang mga ito sa estado ng account na hindi nakikita ng bago. Magpasya muna kung ang bagong deployment ay nagpapatotoo gamit lamang ang sertipiko, gamit ang plugin na nakakaabot sa PAM o RADIUS, o gamit ang kombinasyon, pagkatapos ay tiyakin na pinapanatili ng bawat opsyon ang mga katangiang kailangan mo. Ang ibinahaging sertipiko na walang pagkakakilanlan ng bawat user ay isang kredensyal para sa lahat ng may hawak nito. Kailangan ding gumana ang pagpapawalang-bisa mula sa unang araw, na sa Community OpenVPN ay nangangahulugan ng CRL file na tinutukoy ng crl-verify at isang prosesong muling bumubuo nito.

Planuhin ang enrollment bago ang cutover, hindi pagkatapos. Ang mga bagong sertipiko, nasubok na landas ng pagpapawalang-bisa at dokumentadong paraan ng pag-disable ng isang tao ay mga paunang kondisyon, hindi follow-up na gawain. Kung ang multifactor authentication ay nagmula sa integrasyon ng lumang produkto, pangalanan ang kapalit nang malinaw, dahil ang plugin na hindi naka-install ay nabibigo nang sarado sa pinakamasamang sandali.

Ang routing at paglutas ng pangalan ay sumusunod sa sumusulat ng konfigurasyon

Ang mga ruta, setting ng DNS at pag-uugali ng buong tunnel ay pushed option sa parehong produkto, ngunit isa lamang ang nagkukuwenta ng mga ito para sa iyo. Sa Community OpenVPN ikaw mismo ang nagsusulat ng push directive, nagpapasya kung ang redirect-gateway ay para sa server o sa kliyente, at nagtitiyak na may forwarding at NAT sa host. Ang natapos na handshake ay walang sinasabi tungkol sa forwarding, pagsasalin ng address o mga rutang aktwal na natanggap ng kliyente.

Ang pag-uugali ng bawat kliyente ay nangangailangan ng client-config-dir at file na pinangalanan ayon sa common name ng sertipiko ng kliyente, at ang site-to-site pair ay nangangailangan ng iroute entries para sa mga prefix sa likod nito. Kung mali ang pangalan, ang mga opsyon ay binabalewala nang walang error. Subukan sa isang kliyenteng hindi production sa sarili nitong address pool, pagkatapos ay basahin ang itinalagang address, ang mga rutang natanggap at ang resolver setting na hinarap nito.

Isaayos ang cutover para makabalik ang lumang serbisyo

Patakbuhin ang bagong listener sa ibang port o address, at hayaang maghatid ng traffic ang luma habang pinapatunayan mo ang kapalit. Ang dalawang daemon sa isang socket ay hindi planong pag-rollback.

Ilipat ang isang grupo sa isang pagkakataon, kasama ang mga sertipiko, pool at ruta nito, at sanayin ang daan pabalik sa halip na tuklasin ito sa gitna ng insidente. Ang rollback na gumagana lamang kung ihihinto muna ang bagong serbisyo ay rollback pa rin, ngunit kailangang subukan habang walang nasusunog.

Sa huli, ilista ang mga tampok na walang direktang katumbas at pagpasyahan ang kapalaran ng bawat isa sa sulat: self-service na pag-download ng profile, pahintulot na bandila ng bawat user, ang administration interface mismo, live na pag-uulat ng koneksyon. Ang palitan ang mga ito ng dokumentadong manu-manong proseso ay lehitimong sagot. Ang iwanang blangko ang hilera ay hindi.

Tapos na ang gawain kapag ang taong hindi pa nakakita ng lumang portal ay makakapag-enroll, makakakonekta, maaabot ang nilalayong panloob na address at malinis na mawawalang-bisa. Lahat ng bago iyon ay paghahanda.