AWS Client VPN eller en VPN på EC2: en drift­handbok

Båda alternativen ger teamet en VPN för fjärråtkomst, så den intressanta frågan är inte vilken som finns, utan vilken du kan drifta. Skillnaden är vem som äger slutpunkten klockan 3 på natten och vilka kontroller du når när något går sönder. Gå igenom de fem stegen nedan i ordning, eftersom varje steg kan avsluta jämförelsen tidigt. Att hoppa över inventeringssteget är precis hur team till slut migrerar två gånger.

Steg 1: skriv kravet före fakturan

Du behöver fem fakta på en sida: vem som autentiserar och mot vad, vilka klientplattformar som måste fungera, vilka privata mål som är nåbara, vilken tillgänglighet du lovade och hur trafiken faktiskt ser ut. Utan dem blir varje senare jämförelse en diskussion om en funktionslista.

Var konkret om mål. ”Åtkomst till VPC:n” betyder oftast tre olika saker: VPC:ns CIDR, ett peer-kopplat nätverk och ett lokalt intervall bakom en Transit Gateway. En hanterad slutpunkt når alla tre, men varje mål kräver en rutt och en auktoriseringsregel, och varje mål är en egen rad i ditt krav.

Steg 2: lista det som redan körs

Innan du designar något, lista de befintliga slutpunkterna och varje server som hostas på EC2 tillsammans med dess säkerhetsgrupper. Dessa anrop är enbart läsande och säkra att köra från ett konto med describe-behörigheter.

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 utdata som en karta över vad klienterna redan når. En saknad auktoriseringsregel förklarar ett fel som ser ut som ett ruttproblem, och en slutpunkt kopplad till ett enda subnät förklarar varför ett zonfel tog ner hela tjänsten.

Notera också säkerhetsgrupperna som sitter på varje självhostad instans. Dessa regler är en del av åtkomstmodellen, och de är det första som tyst går sönder när någon bygger om en instans från en mall.

Steg 3: dela upp ansvaret

Den hanterade tjänsten äger slutpunktsflottan, dess patchning och dess tillgänglighet inom regionen. Du äger identitetsregistrering, auktoriseringsregler, nätverksvägarna bakom slutpunkten, loggkonfigurationen och beslutet om hur många subnät som ska kopplas.

Egen hosting vänder på detta. Du äger gästoperativsystemet, VPN-demonen och dess konfiguration, certifikat och nycklar, säkerhetskopior, övervakning och återställning. EC2:s säkerhetsmodell lägger gäst- och applikationssäkerhet på kunden, och en VPN-server är en gäst som vilken annan som helst.

Skriv uppdelningen som en tabell med namn i högerkolumnen. Om inget namn står bredvid certifikatsförnyelsen är det fyndet, och det väger tyngre än timskillnaden.

Steg 4: jämför mot en arbetsbelastning du kan beskriva

Kostnaden följer formen, inte storleken. För det hanterade alternativet räknar du timmar för slutpunktskoppling, timmar för klientanslutningar, överföring samt de identitets- och loggtjänster du aktiverar. För egen hosting räknar du beräkningskraft, lagring, nätverk, licenser och den ingenjörstid som håller servern patchad. Lägg båda sifferserierna i ett ark med samma tidshorisont. En treårsjämförelse som bortser från patchningstimmar kommer alltid att gynna servern du redan har.

Prestandajämförelser kräver samma disciplin. En interaktiv skrivbordssession, en stor överföring och femtio samtidiga små förfrågningar belastar olika delar av vägen: processorn för kryptering, instansens nätverkskapacitet, klientens egen stack och målet. Testa med representativa klienter och samma uppgift i båda designerna.

En större instans är inte bevis för att en överföring blir snabbare, och en lyckad session är ingen kapacitetsplan. Behandla all ärvd historia om instansfamiljer som en hypotes att testa, inte som en inköpsregel.

Steg 5: byt över med en återställning du har kört

Kör båda slutpunkterna parallellt under en bestämd period, dela ut den nya klientprofilen till en liten grupp först och låt den gamla slutpunktens auktoriseringsregler vara orörda tills gruppen har använt den nya i riktigt arbete. Återställning är ett profilbyte, inte en ombyggnad, så bestäm nu var den gamla profilen bor.

Kontrollera i denna ordning: autentiseringen lyckas, klienten får de förväntade rutterna, ett auktoriserat mål svarar och ett icke auktoriserat mål misslyckas, och loggarna visar båda händelserna. Om något steg misslyckas, stanna och åtgärda just det steget i stället för att gå vidare till nästa klientgrupp. Skriv ner resultatet av varje kontroll, för en övergång som bara minns som ”det funkade” går inte att felsöka en månad senare.

Efter övergången, schemalägg de tråkiga kontrollerna: certifikatens utgång, antalet kopplingar, auktoriseringsregler som inte längre matchar en grupp och antalet anslutningar mot din förväntan. Administrationsguiden för Client VPN är referensen för de slutpunkts-, autentiserings- och ruttningsdelar du konfigurerade.