AWS Client VPN eller ein VPN på EC2: ei driftshandbok
Fem steg for å velje mellom AWS Client VPN og ein sjølvhosta VPN på EC2, med CLI-kontrollane, ansvarsfordelinga, overgangen og tilbakerullinga.
Båe alternativa gjev teamet ditt ein VPN for fjernaksess, så det interessante spørsmålet er ikkje kva som finst, men kva du kan drifte. Skilnaden er kven som eig endepunktet klokka 3 om natta, og kva kontrollar du når når noko ryker. Gå gjennom dei fem stega nedanfor i rekkjefølgje, fordi kvart av dei kan avslutte samanlikninga tidleg. Å hoppe over inventarsteget er nettopp korleis team endar med å migrere to gonger.
Steg 1: skriv kravet før rekninga
Du treng fem fakta på éi side: kven som autentiserer og mot kva, kva klientplattformer som må verke, kva private destinasjonar som er tilgjengelege, kva tilgjenge du lova, og korleis trafikken faktisk ser ut. Utan dei blir kvar seinare samanlikning ein diskusjon om ei funksjonsliste.
Ver konkret om destinasjonar. «Tilgang til VPC-en» tyder vanlegvis tre ulike ting: VPC-CIDR-en, eit peer-a nettverk og eit lokalt område bak ein Transit Gateway. Eit administrert endepunkt når alle tre, men kvart av dei treng ei rute og ei autorisasjonsregel, og kvart av dei er ei eiga line i kravet ditt.
Steg 2: list opp det som alt køyrer
Før du designar noko, list opp dei eksisterande endepunkta og kvar tenar som blir hosta på EC2, saman med sikkerheitsgruppene. Desse kalla er berre lesing og trygge å køyre frå ein konto med describe-løyve.
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=vpnLes utdata som eit kart over kva klientane alt når. Ei manglande autorisasjonsregel forklarar ein feil som ser ut som eit ruteproblem, og eit endepunkt knytt til eitt enkelt subnett forklarar kvifor ein sonefeil tok ned heile tenesta.
Noter òg sikkerheitsgruppene som er knytte til kvar sjølvhosta instans. Desse reglane er ein del av tilgangsmodellen, og dei er det første som stille ryker når nokon byggjer ein instans på nytt frå ein mal.
Steg 3: del opp ansvaret
Den administrerte tenesta eig endepunktflåten, patchinga og tilgjengeet i regionen. Du eig identitetsinnmelding, autorisasjonsreglar, nettverksvegane bak endepunktet, loggoppsettet og avgjerda om kor mange subnett som skal knytast til.
Sjølvhosting snur dette. Du eig gjesteoperativsystemet, VPN-demonen og oppsettet, sertifikat og nøklar, tryggleikskopiar, overvaking og gjenoppretting. Tryggingsmodellen til EC2 legg gjeste- og applikasjonstryggleik på kunden, og ein VPN-tenar er ein gjest som kvar annan.
Skriv oppdelinga som ein tabell med namn i høgre kolonne. Står det ikkje eit namn ved sida av sertifikatfornying, er det funnet, og det veg tyngre enn timeforskjellen.
Steg 4: samanlikn med ei arbeidsmengd du kan skildre
Kostnaden følgjer form, ikkje storleik. For det administrerte alternativet tel du endepunktstilknytingstimar, klienttilkoplingstimar, overføring og identitets- og loggtenestene du slår på. For sjølvhosting tel du datakraft, lagring, nettverk, lisensar og ingeniørtida som held tenaren patcha. Legg båe talsetta i eitt ark med same tidshorisont. Ei treårssamanlikning som ignorerer patchetimar vil alltid favorisere tenaren du alt eig.
Ytingssamanlikningar krev same disiplin. Éi interaktiv skrivebordsøkt, éin stor overføring og femti samtidige små førespurnader belastar ulike delar av banen: CPU for kryptering, nettverkskapasiteten til instansen, eigen stack hjå klienten og destinasjonen. Test med representative klientar og same oppgåve i båe designa.
Ein større instans er ikkje bevis for at ei overføring blir snøggare, og éi vellukka økt er ikkje ein kapasitetsplan. Handsame kvar nedarva historie om instansfamiliar som ein hypotese som skal testast, ikkje som ein innkjøpsregel.
Steg 5: skift over med ei tilbakerulling du har køyrt
Køyr båe endepunkta parallelt i ein definert periode, del den nye klientprofilen ut til ei lita gruppe først, og lat autorisasjonsreglane til det gamle endepunktet vere urørte til gruppa har brukt den nye til reelt arbeid. Tilbakerulling er eit profilbyte, ikkje ein gjenoppbygging, så avgjer no kvar den gamle profilen bur.
Stadfest i denne rekkjefølgja: autentiseringa lykkast, klienten får dei forventa rutene, ein autorisert destinasjon svarar og ein uautorisert destinasjon feilar, og loggane viser båe hendingane. Viss eit steg feilar, stopp og rett det steget i staden for å gå vidare til neste klientgruppe. Skriv ned resultatet av kvar kontroll, for ein overgang som berre blir hugsa som «det virka» kan ikkje feilsøkjast ein månad seinare.
Etter overgangen, planlegg dei keisame kontrollane: sertifikatutløp, tal på tilknytingar, autorisasjonsreglar som ikkje lenger passar ei gruppe, og talet på tilkoplingar mot forventninga di. Administrasjonsrettleiinga for Client VPN er referansen for endepunkt-, autentiserings- og rutingsdelane du sette opp.