Access Servertől a Community OpenVPN-ig: mit kell újraépíteni

Az Access Server és a Community OpenVPN ugyanazt a protokollt beszéli, és szinte semmi mást nem ugyanúgy. A kézfogás, a titkosítás egyeztetése és az alagút adatsíkja kompatibilis, ezért egy kliens gyakran mindkettőhöz csatlakozhat a profilja szerkesztése nélkül. A különbség az, hogy kié a konfiguráció: az egyik termék olyan kezelési réteget ad, amely szabályzatot ír és kényszerít ki, a másik egy konfigurációs fájlt és néhány horgot ad, és azt várja, hogy ön döntsön.

Ez a különbség a migrációs terv. Mindent, amit a régi termék ön helyett eldöntött, kifejezett döntéssé kell tenni valahol az új telepítésben.

Ahol a két telepítés megszűnik felcserélhetőnek lenni

Az Access Serverben a webes felügyeleti felület birtokolja a felhasználókat, a csoportokat, a felhasználónkénti engedélyeket, a tanúsítványok kiállítását és azt a profilcsomagot, amelyet valaki letölt. Az alatta futó daemont ez a réteg konfigurálja, így a futó szolgáltatás olyan tárolt állapot eredménye, amelyet ritkán szerkeszt kézzel. A Community OpenVPN-ben a konfigurációs fájl maga az állapot: megnevezi a figyelőt, a tanúsítványhatóságot, a hitelesítési horgot és minden kiküldött opciót, és semmi nem írja át ön helyett. Ugyanaz a TLS gépezet tehát két nagyon különböző tulajdonosi modell alatt áll.

Egy rövid leképezés konkréttá teszi a rést. A felhasználók és a csoportok csak a régi adatbázisban léteznek, amíg újra nem hozza létre őket. A profilcsomagok konfigurációs fájllá és ön által szétosztott tanúsítványokká válnak. A felhasználónkénti engedélyek client-config-dir alatti direktívákká válnak. A felügyeleti felületből az a folyamat lesz, amelyet a tanúsítványok kiállítására és a fájlok szerkesztésére választ.

Írja le ezt a leképezést, mielőtt szerverhez nyúl. Minden sor, amelyet nem tud kitölteni, egy szolgáltatás, amelyet éppen elveszíteni készül, és a csendes elvesztés az, ahogy egy migráció két héttel később kieséssé válik.

Az identitás nem kerül át a tanúsítványfájlokkal

A régi hatóság tanúsítványai helyesen értelmezhetők az új szolgáltatásban, és mégis rossz identitás lehetnek, mert a régi termék olyan fiókállapothoz párosította őket, amelyet az új nem lát. Először döntse el, hogy az új telepítés csak tanúsítvánnyal, PAM vagy RADIUS elérésére képes bővítménnyel, vagy ezek kombinációjával hitelesít, majd ellenőrizze, hogy minden opció megőrzi-e a szükséges tulajdonságokat. A felhasználónkénti identitás nélküli megosztott tanúsítvány egyetlen hitelesítő adat mindenkinek, aki birtokolja. A visszavonásnak is az első naptól működnie kell, ami a Community OpenVPN-ben egy crl-verify által hivatkozott CRL fájlt és egy azt újrageneráló folyamatot jelent.

Tervezze meg a belépést az átállás előtt, ne utána. Az új tanúsítványok, a kipróbált visszavonási útvonal és egy ember letiltásának dokumentált módja előfeltételek, nem utómunka. Ha a többtényezős hitelesítés a régi termék integrációjából jött, nevezze meg a helyettesítőt egyértelműen, mert a nem telepített bővítmény zártan hibázik a legrosszabb pillanatban.

Az útválasztás és a névfeloldás a konfiguráció íróját követi

Az útvonalak, a DNS-beállítások és a teljes alagút viselkedése mindkét termékben kiküldött opciók, de csak az egyik számolja ki őket ön helyett. A Community OpenVPN-ben ön írja a push direktívákat, eldönti, hogy a redirect-gateway a szerverhez vagy a klienshez tartozik, és megerősíti, hogy a hoszton van továbbítás és NAT. Egy befejezett kézfogás semmit nem mond a továbbításról, a címfordításról vagy azokról az útvonalakról, amelyeket a kliens valóban megkapott.

A kliensenkénti viselkedéshez client-config-dir és a kliens tanúsítványának common neve szerint elnevezett fájl kell, a telephelyek közötti párhoz pedig iroute bejegyzések a mögötte lévő előtagokhoz. Ha a név rossz, az opciók hiba nélkül figyelmen kívül maradnak. Teszteljen egy nem termelési klienssel a saját címkészletében, majd olvassa ki a neki kiosztott címet, a kapott útvonalakat és a névfeloldó beállításokat, amelyekkel végzett.

Ütemezze az átállást úgy, hogy a régi szolgáltatás visszatérhessen

Futtassa az új figyelőt más porton vagy címen, és tartsa a régit forgalmat kiszolgálva, amíg bizonyítja a helyettesítést. Két daemon egy socketen nem visszaállítási terv.

Egyszerre egy csoportot mozgasson, saját tanúsítványokkal, saját készlettel és saját útvonalakkal, és gyakorolja a visszatérés útját, ne az incidens közben fedezze fel. Az a visszaállítás, amely csak akkor működik, ha előbb leállítja az új szolgáltatást, még mindig visszaállítás, de akkor kell tesztelni, amikor semmi nem ég.

Végül sorolja fel a közvetlen megfelelő nélküli szolgáltatásokat, és írásban döntse el mindegyik sorsát: önkiszolgáló profil letöltés, felhasználónkénti engedélyjelzők, maga a felügyeleti felület, élő kapcsolatjelentés. Dokumentált kézi folyamattal helyettesíteni őket jogos válasz. A sor üresen hagyása nem az.

A munka akkor kész, amikor egy felhasználó, aki soha nem látta a régi portált, tud regisztrálni, csatlakozni, elérni a szánt belső címet és tisztán visszavonható. Minden ezelőtt felkészülés.