AWS Client VPN o una VPN su EC2: un manuale operativo

Entrambe le opzioni danno al team una VPN per l’accesso remoto, quindi la domanda interessante non è quale esista, ma quale siate in grado di gestire. La differenza è chi possiede l’endpoint alle 3 del mattino e a quali controlli arrivate quando qualcosa si rompe. Seguite i cinque passaggi qui sotto in ordine, perché ognuno può chiudere il confronto in anticipo. Saltare il passaggio dell’inventario è proprio come i team finiscono per migrare due volte.

Passaggio 1: scrivere il requisito prima della fattura

Servono cinque fatti su una pagina: chi si autentica e contro cosa, quali piattaforme client devono funzionare, quali destinazioni private sono raggiungibili, quale disponibilità avete promesso e come appare davvero il traffico. Senza questi, ogni confronto successivo diventa una discussione su un elenco di funzionalità.

Siate concreti sulle destinazioni. «Accesso alla VPC» di solito significa tre cose diverse: il CIDR della VPC, una rete in peering e un intervallo on-premises dietro un Transit Gateway. Un endpoint gestito raggiunge tutti e tre, ma ognuno richiede una rotta e una regola di autorizzazione, e ognuno è una riga separata nel vostro requisito.

Passaggio 2: elencare ciò che già gira

Prima di progettare qualcosa, elencate gli endpoint esistenti e ogni server ospitato su EC2 con i suoi gruppi di sicurezza. Queste chiamate sono di sola lettura e sicure da eseguire da un account con permessi describe.

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

Leggete l’output come una mappa di ciò che i client raggiungono già. Una regola di autorizzazione mancante spiega un guasto che sembra un problema di routing, e un endpoint associato a una sola subnet spiega perché un guasto di zona ha abbattuto l’intero servizio.

Annotate anche i gruppi di sicurezza collegati a qualsiasi istanza auto-ospitata. Quelle regole fanno parte del modello di accesso, e sono la prima cosa che si rompe in silenzio quando qualcuno ricostruisce un’istanza da un modello.

Passaggio 3: dividere le responsabilità

Il servizio gestito possiede la flotta di endpoint, la sua manutenzione e la sua disponibilità nella regione. Voi possedete l’enrollment delle identità, le regole di autorizzazione, i percorsi di rete dietro l’endpoint, la configurazione dei log e la decisione su quante subnet associare.

L’auto-ospitazione inverte tutto questo. Voi possedete il sistema operativo guest, il demone VPN e la sua configurazione, i certificati e le chiavi, i backup, il monitoraggio e il ripristino. Il modello di sicurezza di EC2 mette la sicurezza di guest e applicazione sul cliente, e un server VPN è un guest come qualsiasi altro.

Scrivete la ripartizione come una tabella con i nomi nella colonna di destra. Se accanto al rinnovo dei certificati non compare nessun nome, quello è il risultato, e conta più della differenza oraria.

Passaggio 4: confrontare con un carico di lavoro che sapete descrivere

Il costo segue la forma, non la dimensione. Per l’opzione gestita, contate le ore di associazione degli endpoint, le ore di connessione dei client, il trasferimento e i servizi di identità e logging che attivate. Per l’auto-ospitazione, contate calcolo, archiviazione, rete, licenze e il tempo di ingegneria che tiene il server aggiornato. Mettete entrambi i set di numeri in un unico foglio con lo stesso orizzonte temporale. Un confronto su tre anni che ignora le ore di manutenzione favorirà sempre il server che possedete già.

I confronti di prestazioni richiedono la stessa disciplina. Una sessione desktop interattiva, un trasferimento grande e cinquanta richieste piccole in parallelo sollecitano parti diverse del percorso: la CPU per la cifratura, la capacità di rete dell’istanza, lo stack del client stesso e la destinazione. Testate con client rappresentativi e lo stesso compito su entrambi i progetti.

Un’istanza più grande non è prova che un trasferimento sarà più veloce, e una sessione riuscita non è un piano di capacità. Trattate qualsiasi folklore ereditato sulle famiglie di istanze come un’ipotesi da testare, non come una regola di acquisto.

Passaggio 5: passare con un rollback che avete già eseguito

Tenete in funzione entrambi gli endpoint in parallelo per un periodo definito, distribuite prima il nuovo profilo client a un piccolo gruppo e lasciate intatte le regole di autorizzazione del vecchio endpoint finché il gruppo non avrà usato il nuovo per lavoro reale. Il rollback è un cambio di profilo, non una ricostruzione, quindi decidete ora dove vive il vecchio profilo.

Verificate in questo ordine: l’autenticazione riesce, il client riceve le rotte attese, una destinazione autorizzata risponde e una destinazione non autorizzata fallisce, e i log mostrano entrambi gli eventi. Se un passaggio fallisce, fermatevi e correggete quel passaggio invece di passare al gruppo di client successivo. Annotate il risultato di ogni controllo, perché un passaggio ricordato solo come «ha funzionato» non si può debuggare un mese dopo.

Dopo il passaggio, pianificate i controlli noiosi: scadenza dei certificati, numero di associazioni, regole di autorizzazione che non corrispondono più a un gruppo e numero di connessioni rispetto alle vostre aspettative. La guida all’amministrazione di Client VPN è il riferimento per le parti di endpoint, autenticazione e routing che avete configurato.