OpenVPN Access Server és Community: mi költözik valójában

A profilok költöznek; a felhasználói listák hátramaradnak. Az Access Server és a Community Edition között váltó csapat egy órával az átállás után találkozik ezzel a réssel, amikor első kliense hitelesít, és utána nincs csoportházirendje, nincs felhasználónkénti útvonala és nincs önkiszolgáló jelszó-visszaállítása. Mindkét termék ugyanazt a protokollt beszéli és ugyanazt a klienst fogadja el, és éppen ezért marad a rés láthatatlan a tervezés során. Amit valójában választ, az a kezelési réteg és az azt birtokló emberek.

Kezelje a döntést leltárkérdésként, nem funkciótáblázatként. Kérdezze meg, ki hozza létre a felhasználókat, ki vonja vissza a tanúsítványokat, és ki veszi fel a telefont 02:00-kor.

Miért nem hordozza a .ovpn fájl a beállítást

Egy .ovpn profil egy kliens és egy szerver viszonyát írja le: a távoli gazdagépet, a protokollt, a CA-t, egy kliens tanúsítványt és kulcsot, valamint bármilyen beágyazott tls-crypt anyagot. Dobja ezt a fájlt egy friss buildbe, és a kliens így is végigcsinál egy kézfogást, tehát a migráció késznek látszik. Semmi nem sorolja fel benne a felhasználókat, csoportjaikat, statikus útvonalaikat vagy azt a házirendet, amely eldöntötte, kinek volt egyáltalán szabad csatlakoznia. Ezek a rekordok a szerver saját tárhelyén élnek, és a két termék különböző formákban tárolja őket.

A Community Editionben az megfelelők azok a fájlok, amelyeket Ön tart: client-config-dir bejegyzések kliensenkénti beállításokkal, például ifconfig-push és iroute, egy CRL a visszavonásokhoz és a tls-crypt kulcs. Az Access Server ugyanezeket a fogalmakat tartja a saját adatbázisában, és webes konzolon meg a sacli parancssori eszközön keresztül teszi elérhetővé. A fogalmak egy az egyben megfelelnek; az artefaktumok egyáltalán nem mozdulnak.

A profilok olyan viselkedést is csempésznek be, amelyet senki nem vesz észre, amíg meg nem változik. A redirect-gateway def1 beállítású kliens minden böngészést a szerveren keresztül küld; helyezze át egy olyan buildbe, ahol nincs ez a sor, és a panasz az lesz, hogy elromlott az internet. A CA eltérése vagy a hibás remote-cert-tls beállítás hangosan elbukik, ami a jó eredmény. A hiányzó tls-crypt kulcs néma időtúllépésként bukik el, ami nem az.

Mit birtokol a kezelési réteg

Számolja össze, ami nem protokoll: fióklétrehozás, jelszó-visszaállítás, csoport-hozzárendelés, MFA-regisztráció, kapcsolati jogosultságok, és a napló, amely megválaszolja, ki mikor kapcsolódott. A Community Edition ezek közül semmit nem nyújt közvetlenül. Ön választ egy hitelesítési hátteret, PAM-ot, LDAP-ot vagy RADIUS-t köt be bővítményen vagy auth-user-pass-verify-on keresztül, a többit pedig maga tartja karban. Az Access Server felhasználói portált, adminisztrációs konzolt és integrációkat szállít a gyakori identitásszolgáltatókhoz. Egyik elrendezés sem biztonságosabb alapból, mert a házirendet még mindig annak kell megírnia, aki ismeri a hálózatot.

A jogosultságok a legélesebb operatív különbség. Az Access Servert az egyidejű kapcsolatok száma alapján licencelik, és ezt a számot szoftveresen kényszeríti ki. A Community Editionben a globális felső korlát egyetlen max-clients sor, míg a felhasználónkénti vagy csoportonkénti bármi több client-config-dir munkát és saját kikényszerítést jelent. Az a csapat, amelynek nincs kedve ehhez a karbantartáshoz, pontosan ezt vásárolja meg, amikor a kereskedelmi termékért fizet.

Licencelés és támogatás: a sor, amelyet senki nem tervez be

A Community Edition ingyenes és nyílt forráskódú. Az Access Server kereskedelmi termék, ingyenes szintje történelmileg kevés egyidejű kapcsolatot fedett le, efölött fizetős licenc van. Bármely régi fórumválaszban idézett szám mára elavult, ezért a projekt költségvetése előtt ellenőrizze a szállító jelenlegi feltételeit. Az őszinte összehasonlítás a közösségi oldalon a felhasználókezelés, az MFA és a monitorozás kiépítésére fordított órákat hozzáadja a kereskedelmi oldal licencsorához.

A támogatás tulajdonjoga ugyanezt a felosztást követi. A Community Editionnel Ön az eszkalációs útvonal minden furcsa klienshez és minden kernelfrissítéshez. Az Access Serverrel van egy szállító, akit hívhat, és örökli annak kiadási ritmusát, akár illik a változási ablakához, akár nem.

Ellenőrzések az átállás előtt

A váltás előtt bármelyik irányban vegye leltárba, mit tart valójában a futó szerver. Az Access Server oldalán exportálja a felhasználói listát és a csoport-hozzárendeléseket, és jegyezze meg, mely fiókok támaszkodnak MFA-ra. A Community Edition oldalán sorolja fel a kiadott tanúsítványokat, a CRL-t és minden fájlt a client-config-dir alatt. Hasonlítsa össze a két listát soronként, mert a köztük lévő különbség a migrációs munka.

Teszteljen reprezentatív klienseket, amíg a régi szolgáltatás még fut. A openvpn --config client.ovpn --verb 4 előtérben kiírja a kézfogást, a küldött útvonalakat és a DNS-beállításokat, a openssl x509 -in client.crt -noout -subject -enddate pedig megmutatja, melyik tanúsítványt mutatja be valójában a kliens. Az a kliens, amely csatlakozik, de nem ér el egy belső gazdagépet, útvonal- vagy iroute hiányossággal küzd, nem hitelesítési hibával.

Tartsa életben a régi helyreállítási útvonalat, amíg a csere át nem megy egy elutasított hozzáférésű teszten és egy sikeresen is. Írja le a végső térképet egy oldalra: minden követelmény, a mai napon kielégítő artefaktum és a később kielégítő artefaktum.