AWS Client VPN eller en VPN på EC2: en driftshåndbog

Begge muligheder giver dit team en VPN til fjernadgang, så det interessante spørgsmål er ikke, hvilken der findes, men hvilken du kan drive. Forskellen er, hvem der ejer endpointet klokken 3 om natten, og hvilke kontroller du kan nå, når noget brækker. Gå de fem trin nedenfor igennem i rækkefølge, fordi hvert af dem kan afslutte sammenligningen tidligt. At springe inventartrinnet over er netop, hvordan teams ender med at migrere to gange.

Trin 1: skriv kravet ned, før regningen

Du skal bruge fem fakta på én side: hvem der autentificerer, og mod hvad, hvilke klientplatforme der skal virke, hvilke private destinationer der er tilgængelige, hvilken tilgængelighed du har lovet, og hvordan trafikken faktisk ser ud. Uden dem bliver enhver senere sammenligning en diskussion om en funktionsliste.

Vær konkret om destinationer. «Adgang til VPC'en» betyder normalt tre forskellige ting: VPC-CIDR'en, et peered netværk og et lokalt område bag en Transit Gateway. Et administreret endpoint kan nå alle tre, men hver af dem kræver en rute og en autorisationsregel, og hver af dem er en separat linje i dit krav.

Trin 2: opgør, hvad der allerede kører

Før du designer noget, skal du liste de eksisterende endpoints og enhver server, der hostes på EC2, sammen med dens sikkerhedsgrupper. Disse kald er kun læsning og sikre at køre fra en konto med describe-tilladelser.

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

Læs outputtet som et kort over, hvad klienterne allerede kan nå. En manglende autorisationsregel forklarer en fejl, der ligner et ruteproblem, og et endpoint knyttet til et enkelt subnet forklarer, hvorfor en zonefejl tog hele tjenesten ned.

Notér også de sikkerhedsgrupper, der er knyttet til enhver selvhostet instans. De regler er en del af adgangsmodellen, og de er det første, der stille går i stykker, når nogen genopbygger en instans ud fra en skabelon.

Trin 3: del ansvaret op

Den administrerede tjeneste ejer endpointflåden, dens patchning og dens tilgængelighed i regionen. Du ejer identitetsindrulning, autorisationsregler, netværksvejene bag endpointet, logkonfiguration og beslutningen om, hvor mange subnets der skal tilknyttes.

Selvhosting vender det om. Du ejer gæsteoperativsystemet, VPN-dæmonen og dens konfiguration, certifikater og nøgler, backup, overvågning og gendannelse. EC2's sikkerhedsmodel lægger gæste- og applikationssikkerhed på kunden, og en VPN-server er en gæst som enhver anden.

Skriv opdelingen ned som en tabel med navne i højre kolonne. Hvis der ikke står et navn ved siden af certifikatfornyelse, er det fundet, og det betyder mere end timeforskellen.

Trin 4: sammenlign med en arbejdsbyrde, du kan beskrive

Prisen følger form, ikke størrelse. For den administrerede løsning tæller du endpoint-tilknytnings-timer, klientforbindelses-timer, transfer og de identitets- og logtjenester, du aktiverer. For selvhosting tæller du compute, lager, netværk, licenser og den ingeniørtid, der holder serveren patchet. Sæt begge sæt tal i ét ark med samme tidshorisont. En treårig sammenligning, der ignorerer patchningstimer, vil altid favorisere den server, du allerede ejer.

Ydelsessammenligninger kræver samme disciplin. Én interaktiv skrivebordssession, én stor overførsel og halvtreds samtidige små forespørgsler belaster forskellige dele af vejen: CPU til kryptering, instansens netværkskapacitet, klientens egen stak og destinationen. Test med repræsentative klienter og samme opgave på begge designs.

En større instans er ikke bevis på, at en overførsel bliver hurtigere, og én vellykket session er ikke en kapacitetsplan. Behandl enhver nedarvet historie om instansfamilier som en hypotese, der skal testes, ikke som en indkøbsregel.

Trin 5: skift over med en tilbagerulning, du har kørt

Kør begge endpoints parallelt i en defineret periode, uddel den nye klientprofil til en lille gruppe først, og lad den gamle endpoints autorisationsregler være urørte, indtil gruppen har brugt den nye til rigtigt arbejde. Tilbagerulning er et profilskift, ikke en genopbygning, så beslut nu, hvor den gamle profil bor.

Bekræft i denne rækkefølge: autentificering lykkes, klienten modtager de forventede ruter, en autoriseret destination svarer, en uautoriseret destination fejler, og logfilerne viser begge hændelser. Hvis et trin fejler, så stop og ret det trin i stedet for at gå videre til den næste klientgruppe. Skriv resultatet af hvert tjek ned, for en overgang, der kun huskes som «det virkede», kan ikke fejlfindes en måned senere.

Efter overgangen skal du planlægge de kedelige tjek: certifikatudløb, antal tilknytninger, autorisationsregler der ikke længere passer på en gruppe, og antallet af forbindelser mod din forventning. Administrationsvejledningen til Client VPN er referencen for de endpoint-, autentificerings- og routingdele, du konfigurerede.