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

Begge alternativene gir teamet ditt en VPN for fjernaksess, så det interessante spørsmålet er ikke hvilket som finnes, men hvilket du kan drifte. Forskjellen er hvem som eier endepunktet klokken 3 om natten, og hvilke kontroller du når når noe ryker. Gå gjennom de fem trinnene nedenfor i rekkefølge, fordi hvert av dem kan avslutte sammenligningen tidlig. Å hoppe over inventartrinnet er nettopp hvordan team ender med å migrere to ganger.

Trinn 1: skriv kravet før regningen

Du trenger fem fakta på én side: hvem som autentiserer og mot hva, hvilke klientplattformer som må virke, hvilke private destinasjoner som er tilgjengelige, hvilken tilgjengelighet du lovet, og hvordan trafikken faktisk ser ut. Uten dem blir hver senere sammenligning en diskusjon om en funksjonsliste.

Vær konkret om destinasjoner. «Tilgang til VPC-en» betyr vanligvis tre forskjellige ting: VPC-CIDR-en, et peeret nettverk og et lokalt område bak en Transit Gateway. Et administrert endepunkt når alle tre, men hver av dem trenger en rute og en autorisasjonsregel, og hver av dem er en egen linje i kravet ditt.

Trinn 2: list opp det som allerede kjører

Før du designer noe, list opp de eksisterende endepunktene og enhver server som hostes på EC2, sammen med sikkerhetsgruppene. Disse kallene er kun lesing og trygge å kjøre fra en konto med describe-tillatelser.

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 utdata som et kart over hva klientene allerede når. En manglende autorisasjonsregel forklarer en feil som ser ut som et ruteproblem, og et endepunkt knyttet til ett enkelt subnett forklarer hvorfor en sonefeil tok ned hele tjenesten.

Noter også sikkerhetsgruppene som er knyttet til enhver selvhostet instans. Disse reglene er en del av tilgangsmodellen, og de er det første som stille ryker når noen bygger en instans på nytt fra en mal.

Trinn 3: del opp ansvaret

Den administrerte tjenesten eier endepunktflåten, patchingen og tilgjengeligheten i regionen. Du eier identitetsinnmelding, autorisasjonsregler, nettverksveiene bak endepunktet, loggkonfigurasjonen og beslutningen om hvor mange subnett som skal tilknyttes.

Selvhosting snur dette. Du eier gjesteoperativsystemet, VPN-demonen og konfigurasjonen, sertifikater og nøkler, sikkerhetskopier, overvåking og gjenoppretting. EC2s sikkerhetsmodell legger gjeste- og applikasjonssikkerhet på kunden, og en VPN-server er en gjest som enhver annen.

Skriv oppdelingen som en tabell med navn i høyre kolonne. Hvis det ikke står et navn ved siden av sertifikatfornyelse, er det funnet, og det veier tyngre enn timeforskjellen.

Trinn 4: sammenlign med en arbeidsmengde du kan beskrive

Kostnaden følger form, ikke størrelse. For det administrerte alternativet teller du endepunktstilknytningstimer, klienttilkoblingstimer, overføring og identitets- og loggtjenestene du aktiverer. For selvhosting teller du datakraft, lagring, nettverk, lisenser og ingeniørtiden som holder serveren patchet. Legg begge tallsettene i ett ark med samme tidshorisont. En treårssammenligning som ignorerer patchetimer vil alltid favorisere serveren du allerede eier.

Ytelsessammenligninger krever samme disiplin. Én interaktiv skrivebordsøkt, én stor overføring og femti samtidige små forespørsler belaster ulike deler av banen: CPU for kryptering, instansens nettverkskapasitet, klientens egen stack og destinasjonen. Test med representative klienter og samme oppgave på begge designene.

En større instans er ikke bevis for at en overføring blir raskere, og én vellykket økt er ikke en kapasitetsplan. Behandle enhver nedarvet historie om instansfamilier som en hypotese som skal testes, ikke som en innkjøpsregel.

Trinn 5: skift over med en tilbakerulling du har kjørt

Kjør begge endepunktene parallelt i en definert periode, del den nye klientprofilen ut til en liten gruppe først, og la autorisasjonsreglene til det gamle endepunktet være urørt til gruppen har brukt den nye til reelt arbeid. Tilbakerulling er et profilbytte, ikke en gjenoppbygging, så bestem nå hvor den gamle profilen bor.

Bekreft i denne rekkefølgen: autentiseringen lykkes, klienten mottar de forventede rutene, en autorisert destinasjon svarer og en uautorisert destinasjon feiler, og loggene viser begge hendelsene. Hvis et trinn feiler, stopp og fiks det trinnet i stedet for å gå videre til neste klientgruppe. Skriv ned resultatet av hver kontroll, for en overgang som bare huskes som «det virket» kan ikke feilsøkes en måned senere.

Etter overgangen, planlegg de kjedelige kontrollene: sertifikatutløp, antall tilknytninger, autorisasjonsregler som ikke lenger passer en gruppe, og antall tilkoblinger mot forventningen din. Administrasjonsveiledningen for Client VPN er referansen for endepunkt-, autentiserings- og rutingsdelene du konfigurerte.