OpenVPN Access Server vai Community: mikä oikeastaan siirtyy
Community Edition ja Access Server jakavat OpenVPN-protokollan mutta eivät hallintakerrosta. Vertaa, mikä siirtyy, mikä on rakennettava uudelleen ja kuka sitä tukee.
Profiilit siirtyvät; käyttäjäluettelot jäävät taakse. Tiimi, joka vaihtaa Access Serverin ja Community Editionin välillä, kohtaa tämän aukon tunti siirtymän jälkeen, kun sen ensimmäinen asiakas todentuu eikä sen jälkeen ole ryhmäkäytäntöä, käyttäjäkohtaista reittiä eikä itsepalvelullista salasanan palautusta. Molemmat tuotteet puhuvat samaa protokollaa ja hyväksyvät saman asiakkaan, ja juuri siksi aukko pysyy näkymättömänä suunnittelun aikana. Mitä itse asiassa valitset, on hallintakerros ja ihmiset, jotka sen omistavat.
Käsittele päätöstä inventaariokysymyksenä, älä ominaisuustaulukkona. Kysy, kuka luo käyttäjiä, kuka peruuttaa varmenteita ja kuka vastaa puhelimeen kello 02:00.
Miksi .ovpn-tiedosto ei kanna asetuksia
.ovpn-profiili kuvaa yhden asiakkaan suhdetta yhteen palvelimeen: etäpalvelin, protokolla, CA, asiakasvarmenne ja -avain sekä mahdollinen inline tls-crypt -materiaali. Pudota tiedosto uuteen asennukseen, ja asiakas suorittaa silti kättelyn, joten migraatio näyttää valmiilta. Mikään siinä ei luettele käyttäjiä, heidän ryhmiään, staattisia reittejään tai käytäntöä, joka päätti, kenen ylipäätään sallittiin yhdistää. Ne tiedot elävät palvelimen omassa tallennuksessa, ja tuotteet säilyttävät ne eri muodoissa.
Community Editionissa vastineet ovat tiedostoja, joita pidät itse: client-config-dir-merkinnät, joissa on asiakaskohtaisia valintoja kuten ifconfig-push ja iroute, CRL peruutuksille ja tls-crypt-avain. Access Server pitää samat käsitteet omassa tietokannassaan ja tarjoaa ne verkkokonsolin ja sacli-komentorivityökalun kautta. Käsitteet vastaavat yksi yhteen; artefaktit eivät siirry lainkaan.
Profiilit salakuljettavat myös käyttäytymistä, jota kukaan ei huomaa ennen kuin se muuttuu. Asiakas, jolla on redirect-gateway def1, lähettää kaiken selailun palvelimen kautta; siirrä se asennukseen ilman kyseistä riviä, ja valitus on, että internet meni rikki. CA-epäsopivuus tai väärä remote-cert-tls-asetus epäonnistuu äänekkäästi, mikä on hyvä lopputulos. Puuttuva tls-crypt-avain epäonnistuu hiljaisena aikakatkaisuna, mikä ei ole hyvä.
Mitä hallintakerros omistaa
Laske se, mikä ei ole protokollaa: tilien luonti, salasanan palautus, ryhmiin sijoittaminen, MFA-rekisteröinti, yhteysvaltuudet ja valvontajälki, joka vastaa kuka yhdisti milloin. Community Edition ei tarjoa mitään näistä suoraan. Valitset todennuksen taustajärjestelmän, kytket PAMin, LDAPin tai RADIUSin liitännäisen tai auth-user-pass-verify kautta ja ylläpidät loput itse. Access Server toimittaa käyttäjäportaalin, hallintakonsolin ja integraatiot yleisiin identiteetintarjoajiin. Kumpikaan järjestely ei ole oletuksena turvallisempi, koska käytännön joutuu silti kirjoittamaan joku, joka tuntee verkon.
Valtuudet ovat terävin operatiivinen ero. Access Server lisensoidaan samanaikaisten yhteyksien määrällä ja se määrä valvotaan ohjelmistossa. Community Editionissa maailmanlaajuinen yläraja on yksi max-clients-rivi, kun taas mikä tahansa käyttäjä- tai ryhmäkohtainen tarkoittaa enemmän client-config-dir-työtä ja omaa valvontaa. Tiimi, jolla ei ole halua siihen ylläpitoon, ostaa juuri sitä maksaessaan kaupallisesta tuotteesta.
Lisensointi ja tuki: rivi, jota kukaan ei budjetoi
Community Edition on ilmainen ja avoimen lähdekoodin. Access Server on kaupallinen, ja sen ilmainen taso on historiallisesti kattanut pienen määrän samanaikaisia yhteyksiä, ja sen yläpuolella on maksullinen lisenssi. Mikä tahansa vanhassa foorumivastauksessa mainittu luku on nyt vanhentunut, joten tarkista toimittajan nykyiset ehdot ennen projektin kustannuslaskelmaa. Rehellinen vertailu lisää käyttäjähallinnan, MFA:n ja valvonnan rakentamiseen yhteisön puolella käytetyt tunnit kaupallisen puolen lisenssiriville.
Tuen omistajuus noudattaa samaa jakoa. Community Editionin kanssa olet eskaloinnin polku jokaiselle oudolle asiakkaalle ja jokaiselle ydinpäivitykselle. Access Serverin kanssa sinulla on toimittaja, jolle soittaa, ja perit sen julkaisurytmin, sopiiko se muutostilaasi vai ei.
Tarkistukset ennen siirtymää
Inventoi, mitä käynnissä oleva palvelin todella pitää sisällään ennen siirtymää kumpaan tahansa suuntaan. Access Serverin puolella vie käyttäjäluettelo ja ryhmämääritykset ja merkitse, mitkä tilit nojaavat MFA:han. Community Editionin puolella luettele myönnetyt varmenteet, CRL ja jokainen tiedosto client-config-dir-hakemistossa. Vertaa kahta luetteloa rivi riviltä, sillä niiden välinen ero on migraatiotyö.
Testaa edustavia asiakkaita, kun vanha palvelu on vielä käynnissä. openvpn --config client.ovpn --verb 4 etualalla tulostaa kättelyn, työnnetyt reitit ja DNS-asetukset, ja openssl x509 -in client.crt -noout -subject -enddate näyttää, minkä varmenteen asiakas todella esittää. Asiakkaalla, joka yhdistää mutta ei tavoita sisäistä palvelinta, on aukko reitissä tai iroute-määrityksessä, ei todennusvirhe.
Pidä vanha palautumispolku elossa, kunnes korvaaja läpäisee sekä evätyn pääsyn testin että onnistuneen testin. Kirjoita lopullinen kartta yhdelle sivulle: jokainen vaatimus, artefakti joka täyttää sen nyt, ja artefakti joka täyttää sen myöhemmin.