AWS Client VPN eller VPN på EC2: håndbok for drift

Begge alternativer gir teamet ditt en VPN for fjernaksess. Det interessante spørsmålet er derfor ikke hvilket som finnes, men hvilket du er i stand til å drifte. Forskjellen ligger i hvem som eier endepunktet klokken 3 om natten, og hvilke kontroller du kommer til når noe først svikter. Følg de fem stegene nedenfor i rekkefølge, siden hvert enkelt kan avslutte sammenligningen på et tidlig tidspunkt. Det er når inventarsteget hoppes over at team ender opp med å migrere to ganger.

Steg 1: skriv ned kravet før regningen

Du trenger fem opplysninger på én side: hvem som autentiserer og mot hva, hvilke klientplattformer som må fungere, hvilke private mål som er tilgjengelige, hvilken tilgjengelighet du har lovet, og hvordan trafikken faktisk ser ut. Uten disse blir enhver senere sammenligning en krangel om en funksjonsliste.

Vær konkret når det gjelder mål. «Tilgang til VPC-en» betyr som regel tre forskjellige ting: VPC-ens CIDR, et sammenkoblet nettverk og et lokalt område bak en Transit Gateway. Et administrert endepunkt kan nå alle tre, men hvert av dem krever en rute og en autorisasjonsregel, og hvert av dem er en egen linje i kravet ditt.

Steg 2: kartlegg det som allerede kjører

Før du begynner å designe, lister du opp de eksisterende endepunktene og alle servere som kjøres på EC2, sammen med sikkerhetsgruppene deres. Disse kallene er rent lesende og trygge å kjøre fra en konto som har describe-rettigheter.

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

Les resultatet som et kart over hva klientene allerede når frem til. En manglende autorisasjonsregel forklarer en feil som ser ut som et ruteproblem, og et endepunkt som er knyttet til ett enkelt subnett forklarer hvorfor en sonefeil fikk hele tjenesten til å falle.

Skriv også ned sikkerhetsgruppene som henger på en selvhostet instans. Disse reglene er en del av tilgangsmodellen, og de er det første som stille og rolig ryker når noen gjenoppretter en instans fra en mal.

Steg 3: fordel ansvaret

Den administrerte tjenesten eier endepunktflåten, oppdateringen av den og tilgjengeligheten innenfor regionen. Du eier identitetsregistrering, autorisasjonsregler, nettverksveiene bak endepunktet, loggoppsettet og beslutningen om hvor mange subnett som skal knyttes til.

Egen hosting snur dette på hodet. Du eier gjesteoperativsystemet, VPN-daemonen og konfigurasjonen av den, sertifikater og nøkler, sikkerhetskopier, overvåking og gjenoppretting. Sikkerhetsmodellen i EC2 legger sikkerheten til gjest og applikasjon på kunden, og en VPN-server er en gjest på lik linje med alle andre.

Skriv fordelingen som en tabell med navn i høyre kolonne. Dersom det ikke står noe navn ved siden av sertifikatfornyelsen, er det selve funnet, og det veier tyngre enn timeforskjellen.

Steg 4: sammenlign mot en arbeidsmengde du kan beskrive

Kostnadene følger formen, ikke størrelsen. For det administrerte alternativet teller du timer med endepunktstilknytning, timer med klienttilkoblinger, overføring og de identitets- og loggtjenestene du aktiverer. For egen hosting teller du datakraft, lagring, nettverk, lisenser og den ingeniørtiden som holder serveren oppdatert. Sett begge tallsett inn i ett regneark med samme tidshorisont. En sammenligning over tre år som ser bort fra oppdateringstimene, vil alltid favorisere serveren du allerede har.

Ytelsessammenligninger krever den samme disiplinen. Én interaktiv skrivebordsøkt, én stor overføring og femti samtidige små forespørsler belaster forskjellige deler av banen: prosessoren til kryptering, nettverkskapasiteten til instansen, klientens egen stabel og målet. Test med representative klienter og den samme oppgaven i begge designene.

En større instans er ikke bevis for at en overføring går raskere, og én vellykket økt er ikke en kapasitetsplan. Alt du har hørt om instansfamilier, bør behandles som en hypotese som skal testes, ikke som en innkjøpsregel.

Steg 5: skift over med en tilbakerulling du har gjennomført

Kjør begge endepunktene parallelt i en fastsatt periode, del den nye klientprofilen ut til en liten gruppe først, og la autorisasjonsreglene til det gamle endepunktet stå urørt helt til gruppen har brukt det nye til virkelig arbeid. Tilbakerulling er et bytte av profil, ikke en gjenoppbygging, så bestem allerede nå hvor den gamle profilen skal ligge.

Kontroller i denne rekkefølgen: autentiseringen lykkes, klienten mottar de rutene som er forventet, et autorisert mål svarer, og et uautorisert mål feiler, og loggene viser begge hendelsene. Hvis et steg feiler, stopper du og retter opp i nettopp det steget i stedet for å gå videre til neste klientgruppe. Skriv ned resultatet av hver kontroll, for en overgang som bare huskes som «det fungerte», lar seg ikke feilsøke en måned senere.

Etter overgangen bør du planlegge de kjedelige kontrollene: utløp av sertifikater, antall tilknytninger, autorisasjonsregler som ikke lenger passer med en gruppe, og antall tilkoblinger sett opp mot forventningen din. Administrasjonsveiledningen for Client VPN er referansen for endepunkt-, autentiserings- og rutingsdelene du satte opp.