AWS Client VPN vagy VPN az EC2-n: üzemeltetési kézikönyv

Mindkét lehetőség távoli hozzáférést biztosító VPN-t ad a csapatnak, tehát az érdekes kérdés nem az, melyik létezik, hanem hogy melyiket tudjátok üzemeltetni. A különbség az, hogy ki birtokolja a végpontot hajnali 3-kor, és milyen vezérlőkhöz fértek hozzá, amikor valami elromlik. Járjátok végig az alábbi öt lépést sorrendben, mert mindegyik korán lezárhatja az összehasonlítást. Az leltár lépés kihagyása vezet oda, hogy a csapatok kétszer migrálnak.

1. lépés: írjátok meg a követelményt a számla előtt

Öt tényre van szükségetek egy oldalon: ki és mi ellen hitelesít, mely kliensplatformoknak kell működniük, mely privát célpontok érhetők el, milyen rendelkezésre állást ígértetek, és hogyan néz ki valójában a forgalom. Ezek nélkül minden későbbi összehasonlítás funkciólista-vitába torkollik.

Legyetek konkrétak a célpontokkal. Az „VPC-hozzáférés” általában három különböző dolgot jelent: a VPC CIDR-jét, egy összekapcsolt hálózatot és egy helyszíni tartományt egy Transit Gateway mögött. Egy felügyelt végpont mindhármat eléri, de mindegyikhez útvonal és engedélyezési szabály kell, és mindegyik külön sor a követelményetekben.

2. lépés: vegyétek számba, ami már fut

Mielőtt bármit terveznétek, listázzátok a meglévő végpontokat és minden EC2-n üzemeltetett szervert a biztonsági csoportjaival együtt. Ezek a hívások csak olvasnak, és biztonságosan futtathatók describe-jogosultsággal rendelkező fiókból.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

Olvassátok a kimenetet annak térképeként, amit a kliensek már elérnek. Egy hiányzó engedélyezési szabály megmagyaráz egy útválasztási problémának látszó hibát, és egyetlen alhálózathoz társított végpont megmagyarázza, miért döntötte el egy zónahiba az egész szolgáltatást.

Jegyezzétek fel a saját üzemeltetésű példányokhoz kapcsolt biztonsági csoportokat is. Ezek a szabályok a hozzáférési modell részét képezik, és ők az elsők, amelyek csendben eltörnek, amikor valaki sablonból újraépít egy példányt.

3. lépés: osszátok fel a felelősségeket

A felügyelt szolgáltatás birtokolja a végpontflottát, annak javítását és a régión belüli rendelkezésre állását. Ti birtokoljátok az identitásregisztrációt, az engedélyezési szabályokat, a végpont mögötti hálózati útvonalakat, a naplózási konfigurációt és a döntést arról, hány alhálózatot társítsatok.

A saját üzemeltetés ezt megfordítja. Ti birtokoljátok a vendég operációs rendszert, a VPN-démont és annak konfigurációját, a tanúsítványokat és kulcsokat, a biztonsági mentéseket, a megfigyelést és a helyreállítást. Az EC2 biztonsági modellje a vendég és az alkalmazás biztonságát az ügyfélre bízza, a VPN-kiszolgáló pedig vendég, mint bármely más.

Írjátok le a felosztást táblázatként, nevekkel a jobb oszlopban. Ha a tanúsítvány-megújítás mellett senki neve nem szerepel, ez a lényegi megállapítás, és többet számít az óránkénti különbségnél.

4. lépés: hasonlítsátok össze egy leírható munkaterheléssel

A költség a formát követi, nem a méretet. A felügyelt opciónál számoljátok a végponttársítási órákat, a klienscsatlakozási órákat, a forgalmat, valamint az általatok engedélyezett identitás- és naplózási szolgáltatásokat. A saját üzemeltetésnél számoljátok a számítást, a tárolást, a hálózatot, a licenceket és azt a mérnöki időt, amely a kiszolgálót javított állapotban tartja. Tegyétek mindkét számkészletet egy lapra, azonos időhorizonttal. Egy hároméves összehasonlítás, amely figyelmen kívül hagyja a javítási órákat, mindig a már meglévő kiszolgálót fogja előnyben részesíteni.

A teljesítmény-összehasonlítások ugyanezt a fegyelmet igénylik. Egy interaktív asztali munkamenet, egy nagy átvitel és ötven egyidejű kis kérés az útvonal különböző részeit terheli: a processzort a titkosításhoz, a példány hálózati képességét, a kliens saját vermét és a célpontot. Reprezentatív kliensekkel és ugyanazzal a feladattal teszteljetek mindkét kialakításban.

A nagyobb példány nem bizonyítja, hogy az átvitel gyorsabb lesz, és egy sikeres munkamenet nem kapacitásterv. A példánycsaládokról örökölt bármilyen híresztelést tesztelendő hipotézisként kezeljetek, ne vásárlási szabályként.

5. lépés: álljatok át egy már kipróbált visszaállással

Futtassátok mindkét végpontot párhuzamosan egy meghatározott ideig, osszátok ki az új kliensprofilt először egy kis csoportnak, és hagyjátok a régi végpont engedélyezési szabályait érintetlenül, amíg a csoport valódi munkában nem használta az újat. A visszaállás profilcsere, nem újraépítés, ezért most döntsétek el, hol lakik a régi profil.

Ebben a sorrendben ellenőrizzétek: a hitelesítés sikerül, a kliens megkapja a várt útvonalakat, egy engedélyezett célpont válaszol, egy nem engedélyezett célpont meghiúsul, és a naplók mindkét eseményt mutatják. Ha bármelyik lépés meghiúsul, álljatok meg és javítsátok azt a lépést, ahelyett hogy a következő klienscsoportra lépnétek. Írjátok fel minden ellenőrzés eredményét, mert egy „működött” emlékként megőrzött átállást egy hónappal később nem lehet hibakeresni.

Az átállás után ütemezzétek az unalmas ellenőrzéseket: a tanúsítványok lejárata, a társítások száma, a már egyetlen csoporthoz sem illő engedélyezési szabályok és a kapcsolatok száma a várakozásotokhoz képest. A Client VPN adminisztrációs útmutató a referencia a beállított végpont-, hitelesítési és útválasztási részekhez.